MCP 伺服器把驗證變成可呼叫工具
沒有 MCP 時，需要檢查地址的代理不是自行編造答案，就是要求你執行其他操作。連接電子郵件驗證 MCP 伺服器後，模型會看到工具、呼叫工具，並讀取結構化結果。
價值就在這裡：我們的電子郵件驗證 MCP 伺服器以即時 SMTP 結果取代看似合理的猜測，而且無需教模型如何發出 HTTP 請求。
電子郵件驗證 MCP
電子郵件驗證 MCP 伺服器
託管式電子郵件驗證 MCP 伺服器，讓 Claude、Cursor 及任何 MCP 用戶端都能呼叫真實 SMTP 信箱驗證工具。採用 OAuth，無需本機程序。
無需安裝任何程式。這是託管式 MCP 伺服器：將 URL 加入用戶端的 MCP 設定，透過 OAuth 授權後，工具就會出現。無需本機程序、容器，也不用維護任何相依套件。
加入遠端端點
claude mcp add --transport http billionverify https://mcp.billionverify.com/mcphttps://mcp.billionverify.com/mcp
連接 MCP 伺服器
約兩分鐘即可連接 MCP 伺服器，無需在本機安裝任何程式。
建立帳戶
將 MCP 伺服器 URL 加入用戶端的 MCP 設定。電子郵件驗證 MCP 伺服器採託管方式，無需安裝任何程式。
加入遠端端點
透過 OAuth 授權。MCP 連線會綁定至你的帳戶，而不是綁定至貼在設定檔中的金鑰。
完成驗證
驗證工具會顯示在模型的工具清單中。之後只要詢問某個地址是否有效，就會透過 MCP 伺服器執行真實檢查。
電子郵件驗證 MCP 伺服器提供哪些工具
模型可直接呼叫這個 MCP 伺服器提供的工具。
即時驗證
透過 SMTP 即時檢查單一地址。這是代理最常使用的工具，而電子郵件驗證 MCP 伺服器會以結構化欄位回傳結果，而不是一段文字。
批次處理
一次 MCP 呼叫最多可檢查 50 個地址，並使用相同的 schema。超過此數量時，MCP 伺服器會引導代理改用非同步檔案端點。
SMTP 驗證
真正探測信箱，而不是猜測語法。這正是連接電子郵件驗證 MCP 伺服器的原因，不必讓模型自行推斷地址是否有效。
可使用同一個電子郵件驗證 MCP 伺服器的用戶端
電子郵件驗證 MCP 伺服器適用於所有 MCP 用戶端；MCP 會處理工具探索，因此無需為每個用戶端安裝外掛程式。
AI 聊天用戶端
Claude Desktop、ChatGPT Desktop、DeepSeek、Kimi、MiniMax、豆包
AI 程式開發工具
Claude Code、OpenCode、Cursor、Windsurf、Cline、Continue、Zed
自訂整合
REST API、HTTP Streamable Transport、JSON-RPC 2.0
電子郵件驗證 MCP 伺服器為何需要 SMTP
為何執行真實 SMTP 的 MCP 伺服器勝過只檢查語法的伺服器。
如果要求沒有工具的模型判斷地址，它會給出自信且格式完整的猜測。只檢查語法的 MCP 伺服器也一樣，只是把猜測寫成 JSON。
能夠建立真實 SMTP 連線的電子郵件驗證 MCP 伺服器，回傳的是證據。這就是兩者的根本差異，也是這個電子郵件驗證 MCP 伺服器存在的原因。
它是什麼
電子郵件驗證 MCP 伺服器能為代理提供什麼
MCP 即 Model Context Protocol，是 AI 用戶端探索及呼叫外部工具的標準方式。電子郵件驗證 MCP 伺服器把真實信箱驗證作為其中一項工具，讓代理能檢查地址，而不是自行猜測。
MCP 協定負責工具探索與 schema
用戶端會詢問我們的 MCP 伺服器提供哪些工具，伺服器則以參數描述每項工具。用戶端無需硬式編碼，因此 MCP 伺服器不必為各用戶端撰寫程式碼，就能支援 Claude Desktop、Cursor 及任何其他 MCP 用戶端。
這就是 MCP 與單純 REST API 的差異。底層 API 仍然存在；MCP 則是讓模型能探索它的那一層。
輸入結構化 JSON，輸出結構化 JSON
MCP 伺服器回傳與 REST API 相同的欄位：狀態、品質評分、風險等級、原因碼，以及一次性電子郵件、角色帳號、Catch-All 與免費網頁郵箱等標誌。
模型讀取結構化輸出時，不會像摘要文字那樣把 unknown 擅自判定為 deliverable。使用 MCP 伺服器驗證電子郵件不只是為了方便，也是為了確保判斷正確。
採用託管方式，無需自行執行
電子郵件驗證 MCP 伺服器運行於 mcp.billionverify.com。無需本機程序、容器，也不用維護相依套件；用戶端透過 HTTP 連接，其餘工作由這個 MCP 伺服器處理。
驗證採用 OAuth，因此 MCP 連線會綁定至你的帳戶，而不是綁定至貼在設定檔中的金鑰。
回傳內容
解讀 MCP 伺服器的回傳結果
共有四種狀態，代理應像應用程式碼一樣精確地依狀態分支處理。
deliverable
這個電子郵件驗證 MCP 伺服器執行檢查時，信箱接受了 SMTP 探測。代理可以安全地繼續原本的操作。
MCP 伺服器會將此結果作為欄位回傳，而不是一句話，因此模型無需自行解讀。
undeliverable
永久失敗。代理應停止操作、回報原因代碼，而且不要把該地址寫入 CRM 或行銷活動。
在這種情況下，沒有工具輔助的模型最容易判斷錯誤：格式完整但已失效的地址對語言模型來說看似正常，卻無法通過我們 MCP 伺服器的檢查。
risky
信箱可以使用，但帶有一項標誌：一次性電子郵件服務商、角色帳號或 Catch-All 網域。MCP 伺服器會回傳具體類型，讓代理套用你的政策，而不是通用規則。
告訴代理你的政策；電子郵件驗證 MCP 伺服器會提供套用政策所需的事實。
unknown
接收端服務商延後處理探測，或限制了探測頻率，因此無法證明地址是否可用。
代理應安排重試，不要把 unknown 當成通過。MCP 伺服器會如實回報，不會擅自改判。
開始使用
將這個 MCP 伺服器連接至你的用戶端
只需兩分鐘，無需撰寫程式碼。MCP 伺服器採用託管方式，用戶端只需要 URL。
- 1
Claude Desktop 與 Cursor
將 MCP 伺服器 URL 加入用戶端的 MCP 設定，透過 OAuth 授權後，驗證工具就會顯示在模型的工具清單中。
之後只要詢問某個地址是否有效，就會執行真實檢查，而不是產生猜測。
- 2
代理框架
LangChain、CrewAI 及任何支援 MCP 的框架都以相同方式連接。電子郵件驗證 MCP 伺服器不會限制呼叫它的用戶端。
對於不支援 MCP 的框架，仍可使用底層 REST API；請直接使用 電子郵件驗證 API ，完全略過 MCP 層。
- 3
該告訴代理什麼
提供政策，而不是單一門檻：要接受哪些狀態、如何處理 risky 標誌，以及何時重試 unknown。MCP 伺服器負責提供證據，政策則由你決定。
如果只要求代理「檢查電子郵件」，它會呼叫電子郵件驗證 MCP 伺服器，然後自行判定 risky 結果該如何處理。
- 4
批量工作
單一地址 MCP 呼叫適合對話與代理工作流程。若要處理檔案，應使用非同步端點。
處理檔案時，請使用 批量電子郵件驗證 ；若有一萬個地址，逐列呼叫 MCP 伺服器並不合適。
限制
我們的 MCP 伺服器不會做什麼
它只作出範圍明確的判定，因此代理可以信任並採用。
它不代表收件人已同意
deliverable 結果不代表你有權向某人傳送電子郵件。代理即使依據 MCP 伺服器輸出採取行動，仍須在系統中設定同意規則。
MCP 伺服器只回報信箱事實，不提供任何收件人是否同意的資訊。
它不會識別個人身分
信箱接受郵件，不代表能證明由誰控制。共用別名和轉寄地址都很常見。
代理不應根據這個 MCP 伺服器回傳的 deliverable 狀態推斷身分。
它不保證郵件進入收件匣
SMTP 接受結果只描述收件端路徑。之後的行銷活動能否進入收件匣，取決於 MCP 伺服器無法取得的寄件者端信譽。
若要檢查另一半問題，請使用送達率測試。
它不能取代政策
MCP 伺服器回傳證據。代理該如何處理 Catch-All 網域或一次性電子郵件供應商，是由你的產品決定，而不是由協定決定。
只需設定一次，再與 MCP 連線一起提供給代理。
參考資料
協定與其他相關介面
MCP 是開放協定，同一個驗證引擎也透過其他幾種方式提供。
Model Context Protocol
MCP 是連接模型與工具的開放標準，因此一個電子郵件驗證 MCP 伺服器就能支援所有符合規範的用戶端，無需為每項產品安裝不同的外掛程式。
協定負責工具探索、schema 與傳輸；我們的電子郵件驗證 MCP 伺服器則負責驗證。
以一鍵安裝 skills 取代 MCP
如果你的平台使用 Skills 而不是 MCP，請使用 Agent Skills 套件一鍵安裝相同的驗證功能。
使用相同引擎與欄位；MCP 和 skills 只是提供同一項工具的兩種方式。
底層 REST API
電子郵件驗證 API 是我們 MCP 伺服器所呼叫的介面。所有可透過 MCP 使用的功能，也能直接透過 HTTP 使用。
呼叫端是模型時選擇 MCP；由自己的程式碼呼叫時，選擇 REST API。
常見問題
1. 如何安裝這個電子郵件驗證 MCP 伺服器？
無需安裝任何程式。這是託管式 MCP 伺服器：將 URL 加入用戶端的 MCP 設定，透過 OAuth 授權後，工具就會出現。無需本機程序、容器，也不用維護任何相依套件。
2. 如何在 Claude Code 中使用？
將 MCP 伺服器 URL 加入 Claude Code 的 MCP 設定，並透過 OAuth 授權。使用電子郵件驗證 MCP 伺服器後，代理會呼叫工具，而不是自行推斷地址看起來是否可信。
3. 如何在 Cursor 或 Windsurf 中設定？
做法與其他用戶端相同：加入 URL、完成授權，工具就會出現。電子郵件驗證 MCP 伺服器本來就不受特定用戶端限制，這正是此協定的用途。
4. 可以搭配 ChatGPT、DeepSeek 或 Kimi 使用嗎？
任何符合 MCP 規範的用戶端都能使用，因為 MCP 是開放協定，而非個別供應商的外掛格式。只需連接一次電子郵件驗證 MCP 伺服器，不必分別整合每項 AI 產品，這正是它的價值。
5. 使用 MCP 伺服器需要 SDK 嗎？
不需要。MCP 會處理工具探索與 schema，因此任何符合規範的用戶端都能呼叫電子郵件驗證 MCP 伺服器，無需為各用戶端撰寫程式碼。如果偏好從自己的程式碼直接呼叫 HTTP，也可以使用 REST API；電子郵件驗證 MCP 伺服器與 API 會回傳相同欄位。