Inbox Check 用のMCPサーバー — AIエージェント向けに9つのプロバイダー（Gmail、Outlook、Yahoo、iCloud、AOL、GMX、T-Online、Mail.ru、Yandex）を横断したプログラム可能なメール到達率テストを提供します。
📦 npm · 🌐 check.live-direct-marketing.online · ✨ awesome-mcp-servers · 🔍 Glama
Claude Desktop、Cursor、Windsurf、Cline、またはその他のMCP互換AIクライアントに、実際の受信トレイ配置テスト機能を組み込みます。このサーバーはInbox Check REST APIをラップし、エージェントが直接呼び出せる5つのツールを提供します。テストの作成、返されたシードアドレスへのメール送信、プロバイダーごとの配置（受信トレイ/迷惑メール/プロモーション/更新）、認証結果（SPF、DKIM、DMARC）、ヘッダー、スクリーンショットの読み取りが可能です。
9つの実際のプロバイダーメールボックス — Gmail、Outlook、Yahoo、iCloud、AOL、GMX、T-Online、Mail.ru、Yandex。シミュレーションではなく、実際のIMAPベースのシードアカウントと実際のフィルタ判定を使用します。
認証検証 — Authentication-Results ヘッダーから解析された、配信ごとのSPF、DKIM、DMARCのアライメント結果を報告します。
フォルダー検出 — 受信トレイ、迷惑メール、プロモーション、更新、ソーシャル、フォーラム、およびプロバイダーが提供するカテゴリ別タブを検出します。
スクリーンショット — Gmail、Outlookなどの受信トレイ/迷惑メールリストビューをレンダリングし、受信者が何を見ているかをエージェントがユーザーに提示できるようにします。
不安定なスクレイピングは不要 — サービスが独自のシードメールボックスを運用しているため、エージェントは安定したREST APIと通信するだけです。
AIエージェント向けに構築 — Zodによる厳格なJSONスキーマ、決定論的なツール名、カーソルページネーション、べき等キーを採用しています。
Related MCP server: voidmail
Inbox Check REST APIをラップする5つのツールを提供します：
ツール | 説明 |
| 配置テストを作成し、メール送信先のシードアドレスを返します。 |
| プロバイダーごとの配置、SPF/DKIM/DMARC、スクリーンショットを取得します。 |
| カーソルページネーションを使用して最近のテストを一覧表示します。 |
| テストとそのスクリーンショットを削除します。 |
| APIキーのメタデータ、機能、クォータ使用状況を確認します。 |
npx ldm-inbox-check-mcpグローバルインストールは不要です。Claude Desktop / Cursor / Windsurf / Clineがオンデマンドで npx を実行します。
キーについては運営者に連絡してください（セルフサービス発行は今後対応予定）。
icp_live_... で始まる文字列をコピーしてください（一度しか表示されません）。
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) または %APPDATA%\Claude\claude_desktop_config.json (Windows) を編集します：
{
"mcpServers": {
"inbox-check": {
"command": "npx",
"args": ["-y", "ldm-inbox-check-mcp"],
"env": {
"INBOX_CHECK_API_KEY": "icp_live_xxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}~/.cursor/mcp.json：
{
"mcpServers": {
"inbox-check": {
"command": "npx",
"args": ["-y", "ldm-inbox-check-mcp"],
"env": { "INBOX_CHECK_API_KEY": "icp_live_..." }
}
}
}~/.codeium/windsurf/mcp_config.json：
{
"mcpServers": {
"inbox-check": {
"command": "npx",
"args": ["-y", "ldm-inbox-check-mcp"],
"env": { "INBOX_CHECK_API_KEY": "icp_live_..." }
}
}
}~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json (macOS) または各プラットフォームの同等のパス：
{
"mcpServers": {
"inbox-check": {
"command": "npx",
"args": ["-y", "ldm-inbox-check-mcp"],
"env": { "INBOX_CHECK_API_KEY": "icp_live_..." }
}
}
}変数 | 必須 | デフォルト |
| はい | — |
| いいえ |
|
ベースURLのオーバーライドは、セルフホスト環境やテスト時のみ行ってください。
"inbox-checkを使ってGmail、Outlook、Yahooに対するテストを作成し、90秒待ってからメールがどこに届いたか教えてください。"
"最近のinbox-checkテストを10件リストアップし、プロバイダーごとの迷惑メール率を要約してください。"
"テストを作成するのでメールを送信します。その後、SPF/DKIM/DMARCの結果を表示し、どのレコードが不一致か教えてください。"
コールドメールのウォームアップQA — キャンペーン前に、シードアドレスにドラフトを送信し、エージェントにGmailとOutlookでの受信トレイ配置を確認させます。
認証のデバッグ — ドメインが迷惑メールに分類され始めたら、エージェントにテストを実行させ、失敗しているSPF/DKIM/DMARCチェックを特定させます。
テンプレート変更のレビュー — 新旧のメールテンプレートの配置を、9つのプロバイダーを横断して1回のエージェント実行で比較します。
共有IPレピュテーション監視 — 定期的なテストをスケジュールし、迷惑メール率がしきい値を超えた場合にエージェントにアラートを出させます。
トランザクションメールの監査 — パスワードリセットや領収書メールが、すべての主要プロバイダーで（プロモーションではなく）確実に受信トレイに届くかを確認します。
check.live-direct-marketing.online — このMCPサーバーの背後にあるホスト型Inbox Checkサービス。
live-direct-marketing/ldm-sdk-js — LDM.delivery（AIエージェント向けメール配信API）の公式TypeScript SDKおよびMCPサーバー。
live-direct-marketing/awesome-email-deliverability — メール到達率に関するツール、リソース、ベストプラクティスのキュレーションリスト。
MIT © Live Direct Marketing
Create an inbox-placement test. Returns a token and the seed addresses you must send your test email to. The API key has a daily/monthly quota; each successful create consumes one unit.
| Name | Required | Description | Default |
|---|---|---|---|
| providers | No | Providers to test against. Must be a subset of the key's allowed_providers (see inbox_check_me). Omit to use the full allowlist. | |
| recipient_email | No | Optional — for your own audit trail. Not used for routing. | |
| meta | No | Opaque metadata (e.g. campaign_id) — returned unchanged in GET. |
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 key traits: it's a creation operation (implies mutation), discloses quota consumption ('each successful create consumes one unit'), and specifies output behavior ('Returns a token and the seed addresses'). It could improve by mentioning error handling or permissions, but covers essential aspects well.
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 highly concise and front-loaded, with three sentences that each add value: the core action, output details, and quota information. There is no wasted text, and it efficiently communicates necessary information without 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 (creation operation with quota constraints) and lack of annotations or output schema, the description is mostly complete. It covers purpose, output, and behavioral traits like quota usage. However, it could be more complete by detailing error cases or response formats, but it adequately supports agent usage in context.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as clarifying usage or constraints. This meets the baseline for high schema coverage, but does not enhance parameter understanding.
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 specific action ('Create an inbox-placement test') and resource ('inbox-placement test'), distinguishing it from sibling tools like delete, list, me, and status operations. It provides concrete output details ('Returns a token and the seed addresses you must send your test email to'), making the purpose unambiguous.
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 provides clear context for usage by mentioning API key quotas ('daily/monthly quota; each successful create consumes one unit'), which helps determine when to use this tool. However, it lacks explicit guidance on when to use this versus alternatives like inbox_check_list or inbox_check_status, and does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a test and all its results / screenshots. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
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 communicates that the operation is destructive ('Delete') and irreversible, which is critical for a mutation tool. However, it lacks details on permissions, error handling, or response format, leaving gaps in behavioral understanding.
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 extremely concise and front-loaded, consisting of only two sentences that directly state the action and a critical warning ('Irreversible'). Every word earns its place, with no wasted information, making it efficient for quick comprehension.
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 destructive nature, no annotations, no output schema, and low schema coverage, the description is incomplete. It covers the irreversible aspect but misses key details like parameter meaning, error scenarios, and what happens upon success, making it inadequate for safe and effective use by an agent.
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?
The schema has 1 parameter with 0% description coverage, so the description must compensate. It does not mention the 'token' parameter at all, failing to explain its purpose (e.g., authentication or test identifier). This leaves the parameter undocumented, reducing the tool's usability.
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 action ('Delete') and the resource ('a test and all its results / screenshots'), which is specific and unambiguous. However, it does not explicitly differentiate this tool from its siblings (e.g., 'inbox_check_create', 'inbox_check_list'), which would require mentioning it's for deletion versus creation or listing, so it falls short of a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'inbox_check_create' or 'inbox_check_list'. It mentions the action is 'irreversible', which hints at caution but does not specify prerequisites, conditions, or explicit alternatives, leaving the agent with minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent tests owned by this API key, most recent first. Supports cursor pagination via created_at.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items per page (default 20). | |
| cursor | No | ISO-8601 created_at from previous page. | |
| status | No | Filter by status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses pagination behavior ('Supports cursor pagination via created_at') and ownership scope ('owned by this API key'), which are useful. However, it doesn't mention rate limits, authentication needs, or what happens on errors, which are gaps for a tool with no annotation coverage.
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 two sentences, front-loaded with the core purpose and followed by a key behavioral detail (pagination). Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse.
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 no annotations and no output schema, the description provides basic purpose and pagination but lacks details on return values, error handling, or full behavioral context. For a list tool with 3 parameters, it's adequate but has clear gaps in completeness, especially without structured output information.
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?
Schema description coverage is 100%, so the schema already documents all parameters (limit, cursor, status) with descriptions and constraints. The description adds no additional parameter semantics beyond what's in the schema, such as explaining how 'cursor' works with 'created_at' or default values, meeting the baseline for high coverage.
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 verb ('List') and resource ('recent tests owned by this API key'), specifies ordering ('most recent first'), and distinguishes from siblings by focusing on listing owned tests rather than creating, deleting, checking status, or other operations. It's specific and unambiguous.
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 for listing owned tests with pagination, but doesn't explicitly state when to use this tool versus alternatives like inbox_check_status or inbox_check_me. No exclusions or prerequisites are mentioned, leaving some ambiguity about the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return this API key’s metadata: tier, enabled features, allowed providers, current daily/monthly usage vs. limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly indicates this is a read-only operation ('Return') that retrieves metadata, but does not mention potential limitations like rate limits, authentication requirements, or error conditions. The description adds basic behavioral context but lacks depth for a tool with no annotation coverage.
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 a single, well-structured sentence that efficiently communicates the tool's purpose and scope. Every element ('Return', 'API key's metadata', specific metadata items) earns its place with zero wasted words, making it front-loaded and immediately understandable.
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 simplicity (0 parameters, no output schema, no annotations), the description is reasonably complete for a metadata retrieval operation. However, without annotations or output schema, it could benefit from mentioning the return format or any authentication requirements. It covers the core purpose adequately but has room for more contextual detail.
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?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose without unnecessary parameter information.
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 specific action ('Return') and resource ('this API key's metadata') with detailed scope ('tier, enabled features, allowed providers, current daily/monthly usage vs. limits'). It distinguishes itself from siblings like 'create', 'delete', 'list', and 'status' by focusing on metadata retrieval rather than management operations.
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 for checking API key metadata, but does not explicitly state when to use this tool versus alternatives like 'inbox_check_status' or 'inbox_check_list'. It provides clear context about what information is returned, but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current state of a test: per-provider placement (inbox / spam / promotions / not_received), SPF/DKIM/DMARC, summary stats, and screenshot URLs if the key has screenshots enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Test token returned by inbox_check_create. |
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 describes what information is returned (placement status, SPF/DKIM/DMARC results, stats, screenshot URLs) which is helpful context beyond just being a read operation. However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions.
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 efficiently structured as a single sentence that clearly communicates what the tool returns. Every element (placement status, authentication checks, stats, screenshot URLs) earns its place by specifying the scope of information retrieved.
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?
For a single-parameter read operation with no annotations and no output schema, the description provides adequate information about what data is returned. However, it could be more complete by mentioning the format of returned data or any prerequisites beyond having a valid token.
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?
Schema description coverage is 100%, so the schema already fully documents the single 'token' parameter. The description adds that this token comes from 'inbox_check_create', which provides useful context about parameter origin, but doesn't add significant semantic meaning beyond what the schema provides.
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: 'Get the current state of a test' with specific details about what information is retrieved (placement status, authentication results, stats, screenshot URLs). It uses a specific verb ('Get') and identifies the resource ('test'), but doesn't explicitly differentiate from siblings like 'inbox_check_list' or 'inbox_check_me'.
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 provides no guidance on when to use this tool versus alternatives. It mentions the token parameter comes from 'inbox_check_create', which implies a workflow sequence, but doesn't state when to choose this over other sibling tools like 'inbox_check_list' or 'inbox_check_me' for checking test status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2inbox_check_createinbox_check_deleteinbox_check_listinbox_check_meinbox_check_statusScored across 5 tools
Each tool has a clearly distinct purpose: create, delete, list, get metadata, and get status. There is no overlap in functionality, and the descriptions make it easy to differentiate between them. For example, inbox_check_create initiates a test, while inbox_check_status retrieves results, preventing any confusion.
All tool names follow a consistent verb_noun pattern with the prefix 'inbox_check_' and a descriptive action suffix (e.g., create, delete, list, me, status). This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
With 5 tools, the server is well-scoped for email deliverability testing, covering the full lifecycle from creation to deletion and status monitoring. Each tool serves a necessary function without redundancy, making the count appropriate for the domain's needs.
The tool set provides complete coverage for inbox placement testing: create tests, list them, check status, view metadata, and delete tests. There are no obvious gaps, as it supports all essential operations from initiation to cleanup, ensuring agents can handle the entire workflow without dead ends.
Email for AI agents — send, receive as a webhook, manage domains, templates, routing.
Email for AI agents: send mail, manage contacts, automations & webhooks. Zero-DNS first send.
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
