MCP-Server für Inbox Check — programmatische E-Mail-Zustellbarkeitstests bei 9 Anbietern (Gmail, Outlook, Yahoo, iCloud, AOL, GMX, T-Online, Mail.ru, Yandex) für KI-Agenten.
📦 npm · 🌐 check.live-direct-marketing.online · ✨ awesome-mcp-servers · 🔍 Glama
Integrieren Sie echte Posteingangsplatzierungstests in Claude Desktop, Cursor, Windsurf, Cline oder jeden anderen MCP-kompatiblen KI-Client. Der Server kapselt die Inbox Check REST API und stellt 5 Tools bereit, die Ihr Agent direkt aufrufen kann — erstellen Sie einen Test, senden Sie Ihre E-Mail an die zurückgegebenen Seed-Adressen und lesen Sie die Platzierung pro Anbieter (Posteingang / Spam / Werbung / Updates), Authentifizierungsergebnisse (SPF, DKIM, DMARC), Header und Screenshots aus.
9 echte Anbieter-Postfächer — Gmail, Outlook, Yahoo, iCloud, AOL, GMX, T-Online, Mail.ru, Yandex. Keine Simulationen: echte IMAP-basierte Seed-Konten, echte Filter-Urteile.
Authentifizierungsprüfung — SPF-, DKIM- und DMARC-Alignment werden pro Zustellung
gemeldet und aus den Authentication-Results-Headern geparst.
Ordnererkennung — Posteingang, Spam, Werbung, Updates, Soziales, Foren, kategoriespezifische Tabs, sofern die Anbieter diese bereitstellen.
Screenshots — gerenderte Posteingangs-/Spam-Listenansicht für Gmail, Outlook und andere, damit der Agent dem Benutzer zeigen kann, was der Empfänger sieht.
Kein fehlerhaftes Scraping — der Dienst betreibt seine eigenen Seed-Postfächer; Ihr Agent kommuniziert nur mit einer stabilen REST-API.
Für KI-Agenten entwickelt — striktes JSON-Schema via Zod, deterministische Tool-Namen, Cursor-Pagination, idempotente Schlüssel.
Related MCP server: voidmail
Stellt 5 Tools bereit, die die Inbox Check REST API kapseln:
Tool | Beschreibung |
| Erstellt einen Platzierungstest; gibt Seed-Adressen zurück, an die Sie Ihre E-Mail senden können. |
| Ruft die Platzierung pro Anbieter, SPF/DKIM/DMARC und Screenshots ab. |
| Listet aktuelle Tests mit Cursor-Pagination auf. |
| Löscht einen Test und dessen Screenshots. |
| Überprüft API-Schlüssel-Metadaten, Funktionen und Kontingentnutzung. |
npx ldm-inbox-check-mcpKeine globale Installation erforderlich — Claude Desktop / Cursor / Windsurf / Cline
führen es bei Bedarf via npx aus.
Gehen Sie zu https://check.live-direct-marketing.online/docs.
Kontaktieren Sie den Betreiber für einen Schlüssel (Self-Service-Ausgabe folgt später).
Kopieren Sie die icp_live_...-Zeichenfolge — sie wird genau einmal angezeigt.
Bearbeiten Sie ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) oder %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) oder das Äquivalent auf Ihrer Plattform:
{
"mcpServers": {
"inbox-check": {
"command": "npx",
"args": ["-y", "ldm-inbox-check-mcp"],
"env": { "INBOX_CHECK_API_KEY": "icp_live_..." }
}
}
}Variable | Erforderlich | Standardwert |
| ja | — |
| nein |
|
Überschreiben Sie die Basis-URL nur für selbst gehostete Bereitstellungen oder Tests.
"Verwende inbox-check, um einen Test für Gmail, Outlook und Yahoo zu erstellen, warte dann 90 Sekunden und sag mir, wo die E-Mail gelandet ist."
"Liste meine letzten 10 inbox-check-Tests auf und fasse die Spam-Rate pro Anbieter zusammen."
"Erstelle einen Test, ich sende die E-Mail, zeige mir dann die SPF/DKIM/DMARC-Ergebnisse und sag mir, welcher Datensatz falsch konfiguriert ist."
Qualitätssicherung beim Cold-Email-Warm-up — senden Sie vor einer Kampagne einen Entwurf an die Seed-Adressen und lassen Sie den Agenten die Posteingangsplatzierung bei Gmail + Outlook überprüfen.
Authentifizierungs-Debugging — wenn eine Domain anfängt, im Spam zu landen, lassen Sie den Agenten einen Test durchführen und auf die fehlerhafte SPF/DKIM/DMARC-Prüfung hinweisen.
Überprüfung von Vorlagenänderungen — vergleichen Sie die Platzierung einer alten vs. neuen E-Mail-Vorlage bei 9 Anbietern in einem einzigen Agenten-Durchlauf.
Überwachung der Reputation von Shared-IPs — planen Sie regelmäßige Tests und lassen Sie sich vom Agenten benachrichtigen, wenn die Spam-Rate einen Schwellenwert überschreitet.
Audit für Transaktions-E-Mails — überprüfen Sie, ob E-Mails zum Zurücksetzen von Passwörtern / Empfangsbestätigungen bei jedem großen Anbieter tatsächlich den Posteingang (nicht Werbung) erreichen.
check.live-direct-marketing.online — der gehostete Inbox Check-Dienst hinter diesem MCP-Server.
live-direct-marketing/ldm-sdk-js — offizielles TypeScript SDK + MCP-Server für LDM.delivery (E-Mail-Zustellungs-API für KI-Agenten).
live-direct-marketing/awesome-email-deliverability — kuratierte Liste von Tools, Ressourcen und Best Practices für die E-Mail-Zustellbarkeit.
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.
