MCP-Email-Verify
MCP メール検証
LLMによるメールアドレス検証を可能にする軽量な**モデルコンテキストプロトコル(MCP)**サーバーです。このツールは、AbstractAPI Email Validation APIを用いて、メールの形式、ドメインの有効性、そして配信可能性をチェックします。Claude DesktopのようなAIアプリケーションにメール検証機能を統合するのに最適です。
モデルコンテキストプロトコル (MCP) とは何ですか?
MCPは、AIモデルと外部システム間の通信を効率化するために設計された標準化されたプロトコルです。異なるAIエージェント、ツール、サービスがシームレスに連携できるようにする普遍的な言語と考えてください。
特徴
電子メール検証: 電子メール アドレスをリアルタイムで検証します。
MCP 統合: MCP 互換の LLM とシームレスに接続します。
簡単なセットアップ: Python と MCP SDK を使用して構築されており、迅速に導入できます。
MCP はクライアント サーバー アーキテクチャに従います。
デモを見る
MCP Email Verify ツールの動作を示すビデオ デモを視聴するには、下の画像をクリックしてください。
Related MCP server: @bounceprotect/mcp
要件
Python : Python 3.11.0 以上。
UV :0.6.9以上。
設定
1. リポジトリのクローンを作成する
git clone https://github.com/Abhi5h3k/MCP-Email-Verify.git
cd MCP-Email-Verify2.UVをインストールする
UV がインストールされていない場合は、次のコマンドを使用してインストールできます。
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"インストールを確認します。
uv --version3. 仮想環境をセットアップする
UV を使用して仮想環境を作成します。
uv venv仮想環境をアクティブ化します。Windowsの場合:
.venv\Scripts\activate4. 依存関係のインストールUV を使用して pyproject.toml から必要な依存関係をインストールします。
uv installサーバーの実行
環境変数を設定する ルート ディレクトリに .env ファイルを作成し、 AbstractAPIキーを追加します。
ABSTRACT_API_KEY=your_api_key_hereサーバーを実行する MCP サーバーを起動します。
uv run server.py使用法
サーバーを Claude Desktop に登録します。 claude_desktop_config.json ファイルを更新して、MCP サーバーを追加します。
{
"mcpServers": {
"verify_mail": {
"command": "uv",
"args": [
"--directory",
"C:\\ABSOLUTE\\PATH\\TO\\MCP-Email-Verify",
"run",
"server.py"
]
}
}
}Claude Desktop を再起動します。新しいツールを検出するには、Claude Desktop を再起動します。
メールを確認するには、次のようなプロンプトを使用します。
「 thanos@snap.ioのサノスにメールを送って、お気に入りのテレビ番組を復活させてほしいとお願いしたのですが、有効なメールかどうかわかりません。本物か、それともただのスナップメールか確認してもらえますか?」
発達
フォーマットとリンティング このプロジェクトでは、コードのフォーマットとインポートのソートに black と isort を使用します。
開発依存関係をインストールします。
uv add black isort --devコードをフォーマットします:
black .インポートを並べ替える:
isort .事前コミットを設定する
pre-commit install
pre-commit run --all-filesSmithery.ai サーバーで利用可能: MCP メール検証
記事: モデルコンテキストプロトコル (MCP): AIコミュニケーションの未来に向けた初心者向けガイド
Available Tools
1 toolverify_emailA
Validates an email address using an external email validation API.
This function checks the validity, deliverability, and other attributes of an email address.
It returns a detailed dictionary containing information about the email's format, domain,
and SMTP server.
Args:
email (str): The email address to validate.
Returns:
dict[str, Any]: A dictionary containing detailed validation results. The dictionary
includes the following keys:
- "email" (str): The email address being validated.
- "autocorrect" (str): Suggested autocorrection if the email is invalid or malformed.
- "deliverability" (str): The deliverability status of the email (e.g., "DELIVERABLE").
- "quality_score" (str): A score representing the quality of the email address.
- "is_valid_format" (dict): Whether the email is in a valid format.
- "value" (bool): True if the format is valid, False otherwise.
- "text" (str): A textual representation of the format validity (e.g., "TRUE").
- "is_free_email" (dict): Whether the email is from a free email provider.
- "value" (bool): True if the email is from a free provider, False otherwise.
- "text" (str): A textual representation (e.g., "TRUE").
- "is_disposable_email" (dict): Whether the email is from a disposable email service.
- "value" (bool): True if the email is disposable, False otherwise.
- "text" (str): A textual representation (e.g., "FALSE").
- "is_role_email" (dict): Whether the email is a role-based email (e.g., "admin@domain.com").
- "value" (bool): True if the email is role-based, False otherwise.
- "text" (str): A textual representation (e.g., "FALSE").
- "is_catchall_email" (dict): Whether the domain uses a catch-all email address.
- "value" (bool): True if the domain is catch-all, False otherwise.
- "text" (str): A textual representation (e.g., "FALSE").
- "is_mx_found" (dict): Whether MX records are found for the email domain.
- "value" (bool): True if MX records are found, False otherwise.
- "text" (str): A textual representation (e.g., "TRUE").
- "is_smtp_valid" (dict): Whether the SMTP server for the email domain is valid.
- "value" (bool): True if the SMTP server is valid, False otherwise.
- "text" (str): A textual representation (e.g., "TRUE").
Example:
>>> await verify_email("thanos@snap.io")
{
"email": "thanos@snap.io",
"autocorrect": "",
"deliverability": "UNDELIVERABLE",
"quality_score": "0.00",
"is_valid_format": {
"value": true,
"text": "TRUE"
},
"is_free_email": {
"value": false,
"text": "FALSE"
},
"is_disposable_email": {
"value": false,
"text": "FALSE"
},
"is_role_email": {
"value": false,
"text": "FALSE"
},
"is_catchall_email": {
"value": false,
"text": "FALSE"
},
"is_mx_found": {
"value": false,
"text": "FALSE"
},
"is_smtp_valid": {
"value": false,
"text": "FALSE"
}
}
Raises:
ValueError: If the API key is not found in the environment variables.
requests.exceptions.HTTPError: If the API request fails (e.g., 4xx or 5xx error).
Exception: For any other unexpected errors.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. It explains the external API dependency, detailed return structure, example output, and specific error conditions (ValueError for missing API key, HTTPError for API failures, Exception for other errors). This goes well beyond basic functionality description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns, Example, Raises) and front-loaded with the core functionality. While comprehensive, some sections like the detailed Returns explanation could be more concise, but overall it maintains good information density with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external API integration, detailed return structure) and absence of both annotations and output schema, the description provides exceptional completeness. It covers purpose, parameter, return value structure with detailed key explanations, concrete example, and error conditions - leaving no significant gaps for the agent to understand tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one parameter, the description fully compensates by clearly explaining the 'email' parameter as 'The email address to validate' in the Args section. However, it doesn't provide additional semantic context like format expectations or validation rules beyond what's implied by the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('validates', 'checks') and resources ('email address', 'external email validation API'). It distinguishes what the tool does by specifying it checks 'validity, deliverability, and other attributes' and returns 'detailed dictionary containing information about the email's format, domain, and SMTP server'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the detailed example and return value explanation, suggesting it's for email validation scenarios. However, there are no explicit guidelines on when to use this tool versus alternatives (though no sibling tools exist), prerequisites, or limitations beyond the error handling section.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of ambiguity or overlap between tools. The single verify_email tool has a clearly distinct purpose focused on email validation, making disambiguation trivial.
With only one tool, naming consistency is inherently perfect. The tool name follows a clear verb_noun pattern (verify_email) that would be appropriate if more tools were added, though there are no other tools to compare against.
A single tool is generally too few for most server purposes, creating a thin surface. While email verification could be a narrow domain, typical MCP servers benefit from 3-15 tools for richer functionality. This minimal tool count limits agent capabilities significantly.
For the narrow domain of email verification, the single tool provides comprehensive validation functionality. However, there are notable gaps for broader email-related operations like bulk verification, list management, or integration with email sending services that might be expected from an email-focused server.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Email validation for Claude and any MCP client — verdicts with evidence, bulk jobs, refunds.
Email safety MCP server. Detects phishing, prompt injection, CEO fraud for AI agents.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for e-mail testing: create disposable inboxes, wait for delivery, and extract e-mail content or links - all from your AI agent or test automation workflow. Get a free API key on https://app.zyntra.app/
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server built with the mcp-framework for developing and managing custom tools. It provides a structured foundation for building and integrating modular components like data processors and API clients into Claude Desktop.12

@bounceprotect/mcpofficial
AlicenseAqualityDmaintenanceEmail validation and SMTP verification for Claude Desktop, Cursor, and Claude Code6121MIT- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server that enables Claude Desktop to manage emails via SMTP and IMAP. Send emails, fetch unread messages, and create draft replies directly from conversations.45MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server that enables Claude Desktop to interact with Gmail through secure OAuth 2.0 authentication. Send emails, search messages, read emails, and manage multiple Gmail accounts directly from Claude Desktop.215MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Abhi5h3k/MCP-Email-Verify'
If you have feedback or need assistance with the MCP directory API, please join our Discord server