An MCP server is only as useful as the tools it exposes. Too few and the agent falls back to describing problems instead of fixing them. Too many and the model gets confused about which to call. The Inbox Check MCP server ships with a deliberately small set — five tools, each one doing a single job well. This is the reference for what they do and when the model picks them.
MCP (Model Context Protocol) lets an LLM client (Claude Desktop, Cursor, Claude Code) run tools exposed by a local server. Each tool has a name, a description and a JSON Schema for its arguments. The model decides when to call which tool based on the user's prompt. You install the server with one JSON block and never write orchestration code.
Tool 1: start_test
The workhorse. Kicks off a new inbox placement test across 20+ seed mailboxes (Gmail, Outlook, Yahoo, Mail.ru, Yandex, GMX, ProtonMail, iCloud and more). Returns a test ID immediately; results populate over the next 1-3 minutes.
Arguments
from— sender address, e.g.news@acme.io.subject— subject line as it will appear in the inbox.html— full HTML body of the message.text(optional) — plain-text alternative. If you skip it, one is generated from the HTML.
When the model calls it
Any prompt that includes "test", "run a placement", "check where this lands", or any template the user wants reviewed. The agent usually pairs this with a follow-up get_test to wait for the verdict.
Example prompt
Test the following campaign from news@acme.io:
Subject: "Your weekly digest"
Body: (HTML pasted below)
Wait for the result and summarise where it
landed.Tool 2: get_test
Fetches the current status and (once ready) full verdict for a given test. Agents usually call this in a short polling loop after start_test.
Arguments
id— the test ID returned bystart_test.
What comes back
Inbox / spam / missing counts, per-provider folder placement, authentication verdict (SPF/DKIM/DMARC with domain alignment), the SpamAssassin score and rule breakdown, and links to screenshots of the actual inbox entry at each provider.
Example prompt
Pull the result of test t_abc123 and tell me
which three providers had the worst placement.Tool 3: check_auth
Looks up SPF, DKIM and DMARC records for a domain and returns a structured verdict. This is the tool the model reaches for when you ask "is my authentication correct?" — no sending required.
Arguments
domain— the sending domain, e.g.acme.io.selector(optional) — DKIM selector to resolve, e.g.googleors1. If omitted, the server probes common selectors.
Why it's separate from start_test
You don't always want to send a real email. "Audit this domain before we migrate to SES" is a common use case where the model should check records without sending anything that could affect reputation.
Example prompt
Check SPF/DKIM/DMARC for newsletter.myco.com.
If anything is missing or misaligned, tell me
the exact DNS record I need to add.Tool 4: check_blacklist
Queries major DNSBLs (Spamhaus, SORBS, SURBL, Barracuda, and more) for a domain or IP and returns which lists — if any — are flagging it. Agents use this when you suspect reputation damage or when you inherit a sending IP with unclear history.
Arguments
target— either a domain or an IPv4 address.
Example prompt
Is my sending IP 203.0.113.45 on any DNSBL
right now? If it is, tell me the delisting URL
for the worst one.Tool 5: list_providers
Returns the current seed-mailbox roster. The model uses it when it needs to decide which providers to highlight in a report, or when the user asks things like "do you test Zoho" or "what Russian-language providers do you cover".
Arguments
None.
Example prompt
Which providers can Inbox Check test? I only
care about consumer mailboxes in Europe.JSON schemas
If you're building your own MCP client or just want to see the raw tool list, here are the schemas the server advertises on startup:
[
{
"name": "start_test",
"description": "Run an inbox placement test across 20+ seed mailboxes.",
"inputSchema": {
"type": "object",
"required": ["from", "subject", "html"],
"properties": {
"from": { "type": "string", "format": "email" },
"subject": { "type": "string" },
"html": { "type": "string" },
"text": { "type": "string" }
}
}
},
{
"name": "get_test",
"description": "Fetch status and verdict for a placement test.",
"inputSchema": {
"type": "object",
"required": ["id"],
"properties": { "id": { "type": "string" } }
}
},
{
"name": "check_auth",
"description": "Check SPF, DKIM and DMARC for a domain.",
"inputSchema": {
"type": "object",
"required": ["domain"],
"properties": {
"domain": { "type": "string" },
"selector": { "type": "string" }
}
}
},
{
"name": "check_blacklist",
"description": "Check DNSBL status for a domain or IP.",
"inputSchema": {
"type": "object",
"required": ["target"],
"properties": { "target": { "type": "string" } }
}
},
{
"name": "list_providers",
"description": "List the seed mailboxes Inbox Check tests against.",
"inputSchema": { "type": "object", "properties": {} }
}
]A multi-tool workflow: audit and fix loop
The five tools are deliberately composable. Here's a loop the model runs when you say "audit our cold-email setup and tell me what to fix first":
check_authon the sending domain — catches missing records before wasting a test.check_blackliston the domain and sending IP — if anything is listed, authentication fixes alone won't save you.start_testwith a representative template.get_testin a short polling loop until the verdict arrives.- Model writes a prioritised fix list: auth issues first, blacklist delisting second, content/template third.
We've resisted adding a dozen more tools. Every extra tool dilutes the model's ability to pick the right one. Five focused tools beat fifteen fuzzy ones. If you find yourself wanting check_spam_score or parse_headers, they're already in the get_test verdict.