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개 제공업체 전반에서 이전 이메일 템플릿과 새 템플릿의 배치 결과를 비교합니다.
공유 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.
