Skip to main content
Glama
Abhi5h3k

MCP-Email-Verify

by Abhi5h3k

MCP 이메일 확인

LLM이 이메일 주소의 유효성을 검사할 수 있도록 하는 경량 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 도구는 AbstractAPI 이메일 유효성 검사 API를 사용하여 이메일 형식, 도메인 유효성 및 전송 가능성을 검사합니다. Claude Desktop과 같은 AI 애플리케이션에 이메일 유효성 검사를 통합하는 데 적합합니다.


모델 컨텍스트 프로토콜(MCP)이란 무엇입니까?

MCP는 본질적으로 AI 모델과 외부 시스템 간의 통신을 간소화하도록 설계된 표준화된 프로토콜입니다. 다양한 AI 에이전트, 도구 및 서비스가 원활하게 상호 작용할 수 있도록 하는 범용 언어로 생각하면 됩니다.

MCP 그리기(1)


특징

  • 이메일 확인 : 실시간으로 이메일 주소를 확인하세요.

  • MCP 통합 : MCP 호환 LLM과 원활하게 연결합니다.

  • 간편한 설정 : Python과 MCP SDK로 구축되어 빠르게 배포할 수 있습니다.


MCP는 클라이언트-서버 아키텍처를 따릅니다.

클라이언트 서버 drawio


데모 보기

아래 이미지를 클릭하면 MCP 이메일 확인 도구가 실제로 작동하는 모습을 보여주는 비디오 데모를 볼 수 있습니다.

스크린샷 2025-03-23 115525


Related MCP server: @bounceprotect/mcp

요구 사항

  • Python : Python 3.11.0 이상.

  • UV : 0.6.9 이상.


설정

1. 저장소 복제

지엑스피1

2. UV 설치

UV가 설치되어 있지 않으면 다음 명령을 사용하여 설치할 수 있습니다.

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

설치를 확인하세요:

uv --version

3. 가상 환경 설정

UV를 사용하여 가상 환경을 만듭니다.

uv venv

가상 환경 활성화: Windows의 경우:

.venv\Scripts\activate

4. 종속성 설치 UV를 사용하여 pyproject.toml에서 필요한 종속성을 설치합니다.

uv install

서버 실행

  1. 환경 변수 설정 루트 디렉토리에 .env 파일을 만들고 AbstractAPI 키를 추가합니다.

ABSTRACT_API_KEY=your_api_key_here
  1. 서버 실행 MCP 서버를 시작합니다.

uv run server.py

용법

  1. Claude Desktop에 서버 등록 claude_desktop_config.json 파일을 업데이트하여 MCP 서버를 포함합니다.

{
    "mcpServers": {
        "verify_mail": {
            "command": "uv",
            "args": [
                "--directory",
                "C:\\ABSOLUTE\\PATH\\TO\\MCP-Email-Verify",
                "run",
                "server.py"
            ]
        }
    }
}

영상

  1. Claude Desktop을 다시 시작합니다. Claude Desktop을 다시 시작하여 새로운 도구를 감지합니다.

  2. 이메일 확인 다음과 같은 메시지를 사용하세요.

"타노스에게 thanos@snap.io 로 이메일을 보내서 제가 제일 좋아하는 TV 프로그램을 다시 올려달라고 부탁하려고 했는데, 유효한 이메일인지 잘 모르겠어요. 진짜인지, 아니면 그냥 뜬금없이 보낸 건지 확인해 주시겠어요?"

개발

서식 및 린팅 이 프로젝트에서는 코드 서식 및 가져오기 정렬에 black과 isort를 사용합니다.

  1. 개발 종속성 설치:

     uv add black isort --dev
  2. 코드 형식 지정:

    black .
  3. 가져오기 정렬:

  isort .

사전 커밋 설정

pre-commit install
pre-commit run --all-files

Smithery.ai 서버에서 사용 가능: MCP 이메일 확인

기사: 모델 컨텍스트 프로토콜(MCP): AI 커뮤니케이션의 미래를 위한 초보자 가이드

Available Tools

1 tool
verify_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.
ParametersJSON Schema
NameRequiredDescriptionDefault
emailYes

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedverify_email

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness3/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    A 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 npm
    -
  • A
    license
    A
    quality
    D
    maintenance
    A 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.
    3
    26 npm
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A 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.
    184 npm
    MIT