Skip to main content
Glama
avivshafir

abstractapi-mcp-server

by avivshafir

抽象API MCPサーバー

抽象APIサービスを用いたメールと電話の検証ツールを提供する、モデルコンテキストプロトコル(MCP)サーバーです。このサーバーはFastMCPで構築されており、AIアプリケーションやワークフローに検証機能を簡単に統合できます。

概要

この MCP サーバーは、3 つの主要な検証ツールを公開します。

  • メール検証:包括的なメールアドレスの検証と確認

  • 電話認証:190か国以上の電話番号認証

  • メールレピュテーション:セキュリティに関する洞察を備えた高度なメールレピュテーション分析

Related MCP server: revenuebase-mcp-server

特徴

メール検証

  • フォーマット検証

  • 配信可能性の確認

  • ドメイン検証

  • SMTP検証

  • 使い捨て/ロール/キャッチオールメールの検出

  • 品質スコアリング

電話認証

  • 国際電話番号の検証

  • フォーマットの標準化(国際/ローカル)

  • 国とキャリアの識別

  • 電話の種類の検出(携帯電話、固定電話など)

  • 位置情報

メールレピュテーション

  • 包括的な配信可能性分析

  • 品質スコアリングとリスク評価

  • 送信者と組織の識別

  • ドメインセキュリティ分析(DMARC、SPF)

  • データ侵害履歴の追跡

  • 詐欺および不正行為の検出

前提条件

  • Python 3.11以上

  • uv (高速 Python パッケージ インストーラー)

  • 抽象 API キー ( abstractapi.comで取得)

インストール

オプション1: uvを使用する(推奨)

  1. リポジトリをクローンします。

git clone https://github.com/avivshafir/abstractapi-mcp-server
cd abstractapi-mcp-server
  1. 仮想環境を作成し、依存関係をインストールします。

uv venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
uv pip install .
  1. 環境変数を設定します。

cp .env.example .env
# Edit .env and add your Abstract API key

オプション2: 従来のpipを使用する

  1. リポジトリをクローンします。

git clone https://github.com/avivshafir/abstractapi-mcp-server
cd abstractapi-mcp-server
  1. 仮想環境を作成します。

python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
  1. 依存関係をインストールします:

pip install -r requirements.txt
  1. 環境変数を設定します。

cp .env.example .env
# Edit .env and add your Abstract API key

.envファイルには次の内容が含まれている必要があります。

ABSTRACT_API_KEY=your_abstract_api_key_here

使用法

MCPサーバーの実行

サーバーは、MCP クライアントとの統合のために stdio モードで実行できます。

# With uv (if virtual environment is activated)
python server.py

# Or run directly with uv
uv run server.py

FastMCPフレームワーク

このサーバーは、MCP サーバーの開発を簡素化する Python フレームワークであるFastMCPを使用して構築されています。FastMCP は以下を提供します。

  • 自動ツール登録: @mcp.tool()で装飾された関数は、MCP ツールとして自動的に公開されます。

  • 型安全性: 完全な型ヒントと検証

  • 簡単な非同期サポート:ネイティブのasync/awaitサポート

  • 簡素化されたサーバー設定:最小限の定型コード

FastMCPの主要コンセプト

from mcp.server.fastmcp import FastMCP

# Initialize the server
mcp = FastMCP("abstract_api")

# Register a tool
@mcp.tool()
async def my_tool(param: str) -> dict:
    """Tool description for AI clients"""
    return {"result": param}

# Run the server
mcp.run(transport="stdio")

利用可能なツール

1. メール検証( verify_email

電子メール アドレスを検証し、包括的な情報を返します。

パラメータ:

  • email (str): 検証するメールアドレス

応答例:

{
  "email": "user@example.com",
  "deliverability": "DELIVERABLE",
  "quality_score": "0.99",
  "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": true, "text": "TRUE"},
  "is_smtp_valid": {"value": true, "text": "TRUE"}
}

2. 電話番号の検証( validate_phone

190 か国以上の電話番号を検証します。

パラメータ:

  • phone (str): 検証する電話番号

  • country (str, オプション): コンテキストの ISO 国コード

応答例:

{
  "phone": "14152007986",
  "valid": true,
  "format": {
    "international": "+14152007986",
    "local": "(415) 200-7986"
  },
  "country": {
    "code": "US",
    "name": "United States",
    "prefix": "+1"
  },
  "location": "California",
  "type": "mobile",
  "carrier": "T-Mobile USA, Inc."
}

3. メールレピュテーション( check_email_reputation

セキュリティに関する洞察や侵害履歴を含む包括的な電子メールの評判分析を提供します。

パラメータ:

  • email (str): 分析するメールアドレス

応答例:

{
  "email_address": "benjamin.richard@abstractapi.com",
  "email_deliverability": {
    "status": "deliverable",
    "status_detail": "valid_email",
    "is_format_valid": true,
    "is_smtp_valid": true,
    "is_mx_valid": true,
    "mx_records": ["gmail-smtp-in.l.google.com", "..."]
  },
  "email_quality": {
    "score": 0.8,
    "is_free_email": false,
    "is_username_suspicious": false,
    "is_disposable": false,
    "is_catchall": true,
    "is_subaddress": false,
    "is_role": false,
    "is_dmarc_enforced": true,
    "is_spf_strict": true,
    "minimum_age": 1418
  },
  "email_sender": {
    "first_name": "Benjamin",
    "last_name": "Richard",
    "email_provider_name": "Google",
    "organization_name": "Abstract API",
    "organization_type": "company"
  },
  "email_domain": {
    "domain": "abstractapi.com",
    "domain_age": 1418,
    "is_live_site": true,
    "registrar": "NAMECHEAP INC",
    "date_registered": "2020-05-13",
    "date_expires": "2025-05-13",
    "is_risky_tld": false
  },
  "email_risk": {
    "address_risk_status": "low",
    "domain_risk_status": "low"
  },
  "email_breaches": {
    "total_breaches": 2,
    "date_first_breached": "2018-07-23T14:30:00Z",
    "date_last_breached": "2019-05-24T14:30:00Z",
    "breached_domains": [
      {"domain": "apollo.io", "date_breached": "2018-07-23T14:30:00Z"},
      {"domain": "canva.com", "date_breached": "2019-05-24T14:30:00Z"}
    ]
  }
}

MCPクライアントとの統合

このサーバーを mcp 構成に追加します。

{
  "mcpServers": {
    "abstract-api": {
      "command": "uv",
      "args": ["run", "/path/to/mcp-abstract-api/server.py"],
      "env": {
        "ABSTRACT_API_KEY": "your_api_key_here"
      }
    }
  }
}

あるいは、従来のアプローチを使用する場合は、次のようにします。

{
  "mcpServers": {
    "abstract-api": {
      "command": "python",
      "args": ["/path/to/mcp-abstract-api/server.py"],
      "env": {
        "ABSTRACT_API_KEY": "your_api_key_here"
      }
    }
  }
}

その他のMCPクライアント

このサーバーは標準のMCPプロトコルに準拠しており、MCP互換のクライアントと統合できます。サーバーはstdioトランスポートを介して通信します。

エラー処理

サーバーには包括的なエラー処理が含まれています。

  • APIキー検証: 不足しているAPIキーをチェックします

  • HTTPエラー処理: APIレスポンスエラーの適切な処理

  • 入力検証: 型チェックとパラメータ検証

  • Graceful Degradation : デバッグのための意味のあるエラーメッセージ

API レート制限

抽象 API には、プランに応じて異なるレート制限があります。

  • 無料プラン: 1秒あたり1リクエスト

  • 有料プラン:より高いレート制限が利用可能

検証が成功したか失敗したかに関係なく、各 API 呼び出しは 1 クレジットとしてカウントされます。

発達

プロジェクト構造

mcp-abstract-api/
├── server.py          # Main MCP server implementation
├── .env              # Environment variables (not in repo)
├── .env.example      # Environment template
├── requirements.txt  # Python dependencies (pip format)
├── uv.lock           # uv lock file for reproducible builds
├── pyproject.toml    # Project configuration
├── README.md         # This file
└── LICENSE          # MIT License

新しいツールの追加

新しい抽象 API ツールを追加するには:

  1. APIエンドポイントURLを定数として追加する

  2. @mcp.tool()で装飾された新しい関数を作成する

  3. パラメータと戻り値の説明を含む包括的なドキュメント文字列を追加する

  4. 既存のパターンに従ってエラー処理を実装する

例:

@mcp.tool()
async def new_validation_tool(param: str) -> dict[str, Any]:
    """
    Description of what this tool does.
    
    Args:
        param (str): Description of parameter
        
    Returns:
        dict[str, Any]: Description of return value
    """
    # Implementation here
    pass

貢献

  1. リポジトリをフォークする

  2. 機能ブランチを作成する

  3. 変更を加える

  4. 該当する場合はテストを追加する

  5. プルリクエストを送信する

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。

サポート

以下に関連する問題について:

謝辞

Available Tools

3 tools
check_email_reputationA
Analyzes email reputation using Abstract API's Email Reputation service.

This function provides comprehensive email reputation analysis including deliverability,
quality scoring, sender information, domain details, risk assessment, and breach history.
It's designed to help improve delivery rates, clean email lists, and block fraudulent users.

Args:
    email (str): The email address to analyze for reputation.

Returns:
    dict[str, Any]: A dictionary containing comprehensive reputation analysis. The dictionary
    includes the following main sections:
        - "email_address" (str): The email address that was analyzed.
        - "email_deliverability" (dict): Deliverability information.
            - "status" (str): "deliverable", "undeliverable", or "unknown".
            - "status_detail" (str): Additional detail (e.g., "valid_email", "invalid_format").
            - "is_format_valid" (bool): True if email follows correct format.
            - "is_smtp_valid" (bool): True if SMTP check was successful.
            - "is_mx_valid" (bool): True if domain has valid MX records.
            - "mx_records" (list): List of MX records for the domain.
        - "email_quality" (dict): Quality assessment information.
            - "score" (float): Confidence score between 0.01 and 0.99.
            - "is_free_email" (bool): True if from free provider (Gmail, Yahoo, etc.).
            - "is_username_suspicious" (bool): True if username appears auto-generated.
            - "is_disposable" (bool): True if from disposable email provider.
            - "is_catchall" (bool): True if domain accepts all emails.
            - "is_subaddress" (bool): True if uses subaddressing (user+label@domain.com).
            - "is_role" (bool): True if role-based address (info@, support@, etc.).
            - "is_dmarc_enforced" (bool): True if strict DMARC policy enforced.
            - "is_spf_strict" (bool): True if domain enforces strict SPF policy.
            - "minimum_age" (int|null): Estimated age of email address in days.
        - "email_sender" (dict): Sender information if available.
            - "first_name" (str|null): First name associated with email.
            - "last_name" (str|null): Last name associated with email.
            - "email_provider_name" (str|null): Email provider name (e.g., "Google").
            - "organization_name" (str|null): Organization linked to email/domain.
            - "organization_type" (str|null): Type of organization (e.g., "company").
        - "email_domain" (dict): Domain information.
            - "domain" (str): Domain part of the email.
            - "domain_age" (int|null): Age of domain in days.
            - "is_live_site" (bool|null): True if domain has active website.
            - "registrar" (str|null): Domain registrar name.
            - "registrar_url" (str|null): Registrar website URL.
            - "date_registered" (str|null): Domain registration date.
            - "date_last_renewed" (str|null): Last renewal date.
            - "date_expires" (str|null): Domain expiration date.
            - "is_risky_tld" (bool|null): True if top-level domain is considered risky.
        - "email_risk" (dict): Risk assessment.
            - "address_risk_status" (str): Risk level for the email address.
            - "domain_risk_status" (str): Risk level for the domain.
        - "email_breaches" (dict): Data breach information.
            - "total_breaches" (int|null): Number of known breaches.
            - "date_first_breached" (str|null): Date of first known breach.
            - "date_last_breached" (str|null): Date of most recent breach.
            - "breached_domains" (list): List of breached domains with dates.

Example:
    >>> await check_email_reputation("benjamin.richard@abstractapi.com")
    {
        "email_address": "benjamin.richard@abstractapi.com",
        "email_deliverability": {
            "status": "deliverable",
            "status_detail": "valid_email",
            "is_format_valid": true,
            "is_smtp_valid": true,
            "is_mx_valid": true,
            "mx_records": ["gmail-smtp-in.l.google.com", ...]
        },
        "email_quality": {
            "score": 0.8,
            "is_free_email": false,
            "is_username_suspicious": false,
            "is_disposable": false,
            "is_catchall": true,
            "is_subaddress": false,
            "is_role": false,
            "is_dmarc_enforced": true,
            "is_spf_strict": true,
            "minimum_age": 1418
        },
        "email_sender": {
            "first_name": "Benjamin",
            "last_name": "Richard",
            "email_provider_name": "Google",
            "organization_name": "Abstract API",
            "organization_type": "company"
        },
        "email_domain": {
            "domain": "abstractapi.com",
            "domain_age": 1418,
            "is_live_site": true,
            "registrar": "NAMECHEAP INC",
            "registrar_url": "http://www.namecheap.com",
            "date_registered": "2020-05-13",
            "date_last_renewed": "2024-04-13",
            "date_expires": "2025-05-13",
            "is_risky_tld": false
        },
        "email_risk": {
            "address_risk_status": "low",
            "domain_risk_status": "low"
        },
        "email_breaches": {
            "total_breaches": 2,
            "date_first_breached": "2018-07-23T14:30:00Z",
            "date_last_breached": "2019-05-24T14:30:00Z",
            "breached_domains": [
                {"domain": "apollo.io", "date_breached": "2018-07-23T14:30:00Z"},
                {"domain": "canva.com", "date_breached": "2019-05-24T14:30:00Z"}
            ]
        }
    }

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.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does well by disclosing behavioral traits: it explains the comprehensive analysis scope, mentions API dependencies (Abstract API), and includes error handling details in the 'Raises' section. However, it doesn't mention rate limits, authentication requirements beyond the API key error, or whether this is a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately front-loaded with purpose and usage, but becomes overly verbose with an extremely detailed example (60+ lines) that duplicates information already implied by the return structure description. The 'Raises' section is useful but could be more concise.

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 (comprehensive reputation analysis), no annotations, and no output schema, the description provides exceptional completeness: detailed purpose, parameter semantics, comprehensive return structure documentation, example output, and error handling. Nothing essential is missing for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 compensates fully by providing detailed semantics for the 'email' parameter in the Args section, explaining it's 'The email address to analyze for reputation' with clear type information and usage context.

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 'analyzes email reputation using Abstract API's Email Reputation service' with specific verbs ('analyzes', 'provides comprehensive analysis') and distinguishes it from sibling tools (validate_phone, verify_email) by focusing on reputation analysis rather than validation or verification.

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 ('designed to help improve delivery rates, clean email lists, and block fraudulent users') but doesn't explicitly state when to use this tool versus the sibling tools (validate_phone, verify_email). No explicit alternatives or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_phoneA
Validates a phone number using Abstract API's Phone Validation service.

This function checks the validity and other details of phone numbers from over 190 countries.
It returns detailed information about the phone number including format, country, location,
type, and carrier information.

Args:
    phone (str): The phone number to validate and verify.
    country (str, optional): The country's ISO code to indicate the phone number's country.
                            This helps the API append the corresponding country code to its analysis.
                            For example, use "US" for United States numbers.

Returns:
    dict[str, Any]: A dictionary containing detailed validation results. The dictionary
    includes the following keys:
        - "phone" (str): The phone number submitted for validation.
        - "valid" (bool): True if the phone number is valid, False otherwise.
        - "format" (dict): Object containing international and local formats.
            - "international" (str): International format with country code and "+" prefix.
            - "local" (str): Local/national format without international formatting.
        - "country" (dict): Object containing country details.
            - "code" (str): Two-letter ISO 3166-1 alpha-2 country code.
            - "name" (str): Name of the country where the phone number is registered.
            - "prefix" (str): Country's calling code prefix.
        - "location" (str): Location details (region, state/province, sometimes city).
        - "type" (str): Type of phone number. Possible values: "Landline", "Mobile",
                       "Satellite", "Premium", "Paging", "Special", "Toll_Free", "Unknown".
        - "carrier" (str): The carrier that the number is registered with.

Example:
    >>> await validate_phone("14152007986")
    {
        "phone": "14152007986",
        "valid": true,
        "format": {
            "international": "+14152007986",
            "local": "(415) 200-7986"
        },
        "country": {
            "code": "US",
            "name": "United States",
            "prefix": "+1"
        },
        "location": "California",
        "type": "mobile",
        "carrier": "T-Mobile USA, Inc."
    }

    >>> await validate_phone("2007986", "US")
    # Will validate with US country context

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
phoneYes
countryNo

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains what the tool returns (detailed validation results), includes error handling information (raises section), describes the external API dependency, and provides a complete example of the return format. This goes well beyond basic functional 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, parameters, returns, example, raises) but is somewhat lengthy. Every section adds value, though some information could be more concise. The front-loaded purpose statement is clear, and the structure helps with comprehension despite the length.

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?

For a tool with no annotations, no output schema, and 0% schema description coverage, the description provides exceptional completeness. It covers purpose, parameters, return values with detailed structure, examples, error handling, and external dependencies. The return value documentation effectively substitutes for a missing output schema, making this description highly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. It explains both parameters thoroughly: 'phone' is the number to validate, and 'country' is an optional ISO code that helps with analysis. The description includes examples showing how both parameters work, adding significant value beyond the bare schema.

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: 'Validates a phone number using Abstract API's Phone Validation service.' It specifies the exact action (validate), resource (phone number), and service provider, distinguishing it from sibling email tools. The description goes beyond the tool name by explaining it checks validity and returns detailed information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool: for validating phone numbers from over 190 countries. It doesn't explicitly mention when not to use it or compare with alternatives, but the context is sufficiently clear given the tool's specialized function. The examples show usage patterns with and without the optional country parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_emailA
Validates an email address using an external email validation API of abstractapi.

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.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it uses an external API, returns detailed validation results, and includes error handling (raises exceptions for missing API key, HTTP errors, or other issues). It covers key aspects like what the tool does and potential failures, though it could add more on rate limits or performance.

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 key information. However, it includes an extensive example and detailed return value breakdown that might be verbose; some of this could be streamlined without losing clarity, but overall it remains efficient and informative.

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 output) and no annotations or output schema, the description is highly complete. It covers purpose, parameters, return values with examples, and error handling, providing all necessary context for an AI agent to understand and use the tool effectively without relying on structured fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides detailed parameter semantics: 'email (str): The email address to validate.' This adds clear meaning beyond the bare schema, explaining the parameter's purpose and type, which is essential given the low schema coverage.

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: 'Validates an email address using an external email validation API of abstractapi.' It specifies the verb ('validates'), resource ('email address'), and method ('external email validation API'), distinguishing it from sibling tools like 'check_email_reputation' which likely focuses on reputation rather than validation, and 'validate_phone' which handles a different resource type.

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 for email validation but does not explicitly state when to use this tool versus alternatives like 'check_email_reputation'. It mentions checking 'validity, deliverability, and other attributes', which suggests use cases, but lacks explicit guidance on when to choose this over siblings or when not to use it (e.g., for simple format checks only).

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. Dates show when Glama detected each change.

  1. 3 tool updates
    • First observedcheck_email_reputation
    • First observedvalidate_phone
    • First observedverify_email

TDQS

A3.8/5.0
Disambiguation2/5

The tools have significant overlap and unclear boundaries. Both check_email_reputation and verify_email perform email validation with substantial functional overlap, making it difficult for an agent to choose between them. The phone validation tool is distinct, but the email tools appear to do similar things with different emphasis.

Naming Consistency3/5

The naming follows a mixed pattern. Two tools use verb_noun format (check_email_reputation, verify_email) while one uses verb_noun format but with different verb style (validate_phone). The naming is readable but lacks complete consistency in verb choice across the set.

Tool Count3/5

With only 3 tools, the server feels thin for an 'abstractapi-mcp-server' that presumably covers multiple Abstract API services. While the tools themselves are substantial, the count suggests limited coverage of what Abstract API likely offers, making the server feel under-scoped.

Completeness2/5

For an Abstract API server, there are significant gaps in coverage. The server only covers email and phone validation, missing other Abstract API services like IP geolocation, exchange rates, holidays, etc. Even within the covered domains, there's redundancy rather than comprehensive functionality.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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/avivshafir/abstractapi-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server