Test an email before it goes out: a disposable address, 41 checks with RFC citations, a fix plan.
Scored across 4 tools
Each tool has a fairly distinct role in the send-and-check workflow: get_test_address reserves an address, wait_for_report blocks for analysis, get_report reads the current report, and get_message_source retrieves the raw message. The only mild overlap is between wait_for_report and get_report, but their descriptions clearly differentiate blocking-summary versus immediate-read behavior.
Three of four tools follow a clean get_<noun> pattern (get_message_source, get_report, get_test_address), with wait_for_report the single deviation using a different verb. This is a minor, readable break rather than a chaotic mix.
Four tools cleanly map to one coherent lifecycle (reserve address, wait for analysis, read report, inspect raw source), so each earns its place. It is on the lean side but not thin enough to feel incomplete for the workflow.
The surface covers the full loop of reserving a test address, sending, awaiting analysis, reading the report, and inspecting the raw message source. Minor gaps exist (e.g. no listing/history of past reports or a way to re-trigger a check), but core workflows are covered.
The message exactly as it was received: headers, both bodies, source.
Useful when a finding points at a header and the agent needs to see what it
actually sent rather than what it believes it sent. The message is kept
for an hour after it arrives and then deleted; within that hour anyone
with the slug can read it. After that only the report remains.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug of a test whose message has already arrived. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds genuinely new lifecycle facts: one-hour retention, deletion afterward, and that anyone holding the slug can read it during that window. That is real context beyond the structured fields, though nothing is said about size limits or what the output looks like.
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?
Three tight sentences, front-loaded with what the tool returns, then the use case, then the retention constraint. No filler.
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?
Output schema exists so return shape need not be described; the description still covers the critical behavioral constraint (one-hour window) an agent needs before calling. Nothing material is missing.
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 coverage is 100% and the single slug parameter is documented as 'a test whose message has already arrived'; the description adds no format or syntax detail beyond that. Baseline 3 is appropriate when the schema carries the parameter meaning.
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?
Names the verb+resource precisely and enumerates what the payload contains (headers, both bodies, source). It implicitly separates itself from the report sibling ('after that only the report remains') but never names get_report explicitly, so sibling differentiation is only implied.
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?
Gives a concrete trigger: when a finding points at a header and the agent needs the actual sent bytes rather than its assumption. Strong context, but no explicit 'do not use for X' or named alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a report by its slug without waiting, with provider placement so far.
The report stays at its link for good and anyone with the link can read
it: the checks, the score, the fix plan, and the subject and sender of
the email.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug of a test, the last part of the report URL. |
| Name | Required | Description |
|---|---|---|
| view | Yes | Which card to draw. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds that the report stays at its link permanently and anyone with the link can read it, which is useful permission context, but it omits error behavior (e.g. unknown slug) and response format details already covered by the output schema.
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?
Two short sentences, with the core action front-loaded and the content list following. The 'provider placement so far' phrase is slightly awkward and the preamble is a bit longer than necessary, but there is no real waste.
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?
The tool is simple, has a rich set of annotations, and an output schema, so the description needn't explain return values. It covers purpose, permanence, and access. A small missing piece is what happens when the slug is unknown, but overall it is sufficient for correct invocation.
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 coverage is 100% and the slug parameter is fully documented in the schema as 'the last part of the report URL'. The description only restates 'by its slug', adding no syntax or format details beyond what the schema provides, so baseline 3 applies.
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?
States a specific verb (read) and resource (report by slug), and the 'without waiting' phrase differentiates it from the sibling wait_for_report. The enumerated content (checks, score, fix plan, subject/sender) makes the return value concrete.
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 phrase 'without waiting' implies this is the right call when the report already exists, positioning it against wait_for_report. However, no explicit when-not-to-use or naming of the alternative is given, so the contrast is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reserve a single-use address to send a draft email to, for a full check.
Returns the address and the URL its report will appear at. The address
accepts exactly one message and expires after an hour. The email has to be
sent by the person, from the platform or mailbox they really send from:
half the checks read what that platform adds. The report covers 42 checks
(SPF, DKIM, DMARC, reverse DNS, TLS, blocklists, content, links, the
Gmail and Yahoo bulk-sender rules) and a plan of what to fix.
lang is decided now because the message arrives minutes later over SMTP,
which carries no hint of who is waiting for it. What wait_for_report
returns quotes check lines in English whatever it is set to; the person
following report_url sees their own language.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ISO code of the language the report and the fix plan are written in for the person who opens the report page, for example "en", "de" or "pt-BR". Defaults to the language of the conversation. Unknown codes fall back to English. | |
| include_placement | No | Also check which folder (inbox, spam, promotions) the email lands in at different mailbox providers, from the same send. The email then goes to a list of recipients instead of one address and needs a marker in the subject; both come back. Some provider inboxes are public test inboxes: the subject, the sender name and the folder are shown on a public web page, so it suits messages that are not confidential. |
| Name | Required | Description |
|---|---|---|
| view | Yes | Which card to draw. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), and the description adds substantial behavioral detail beyond them: single-use, one-hour expiry, must be sent from the real sending platform, why lang must be chosen at reservation time (SMTP carries no locale hint), and the split between English check lines in wait_for_report versus the localized report page. No contradiction with the annotations.
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 purpose and constraints are front-loaded in the first two sentences, and the later paragraphs each add real information (expiry, send requirements, check coverage, language timing). It is somewhat longer than strictly necessary for a two-parameter tool, with some enumerations that could be trimmed.
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 async, email-mediated flow, the description covers the lifecycle well and an output schema exists so return values need not be detailed. It does not explicitly name which sibling to poll for the finished report or the sequencing after the message is sent, which is the main remaining gap for an agent orchestrating the workflow.
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 baseline is 3, and the description earns extra credit by explaining why lang is captured now rather than later and how it affects the two output surfaces. include_placement is not mentioned in the description at all, so it does not compensate for that gap, but the schema already documents it fully.
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 states a specific verb and resource ("Reserve a single-use address to send a draft email to") and defines the scope of the resulting check (42 checks, SPF through bulk-sender rules). It is clearly distinguishable from the siblings get_report, get_message_source, and wait_for_report, which it treats as downstream consumers of the address it creates.
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?
It establishes the workflow context (reserve here, send from your real platform, then read report_url or wait_for_report) and contrasts what wait_for_report returns versus what the report page shows. However, it never explicitly says when to choose this over the sibling tools or what happens if the address is used incorrectly beyond the one-message/one-hour constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait until the message arrives and has been analysed, then summarise it.
Call it after the email has been sent to the address from
get_test_address. Blocks rather than returning "not ready yet": an agent
told to poll writes a sleep loop and usually gives up before the analysis
finishes. Provider placement keeps filling in for up to 30 minutes after
the report; get_report reads the latest.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The slug get_test_address returned, the last part of the report URL. | |
| timeout_seconds | No | How long to block waiting for the message and its analysis, in seconds. The checks are ready in well under a minute; the fix plan takes about another one. Past this the tool returns what it has. |
| Name | Required | Description |
|---|---|---|
| view | Yes | Which card to draw. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnly/idempotent; the description adds the crucial blocking behavior, the 30-minute provider-placement window, and that it returns partial state after timeout. These are exactly the traits an agent cannot learn from the schema or annotations.
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?
Front-loads the purpose, then rationale, then sibling routing. The polling-explanation sentence is a touch long but its content is load-bearing rather than filler.
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?
An output schema exists, so return shape needs no explanation; the description covers everything else an agent needs: ordering, blocking semantics, timeout behavior, and where to go next (get_report).
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 coverage is 100%, so the baseline is 3; the description earns extra by tying slug provenance to get_test_address and clarifying the timeout trade-off (checks under a minute, fix plan ~another minute, then returns what it has). Slight redundancy with the schema's own timeout text.
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?
States a specific verb (wait) and resource (for the message/report), with the added twist that it summarises the analysed message. The polling-vs-blocking distinction and the 'call it after get_test_address' sequencing separate it cleanly from get_report and the other siblings.
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?
Explicit ordering ('Call it after the email has been sent to the address from get_test_address') and an explicit alternative ('get_report reads the latest'), plus a when-not rationale: agents that poll a non-blocking call write sleep loops and give up. Nothing is left to inference.
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.
get_report1 field changedOutput schema / properties / view / descriptionPrevious value: -"test, report, mailbox, mailboxes, series or error"New value: +"Which card to draw."get_test_address1 field changedOutput schema / properties / view / descriptionPrevious value: -"test, report, mailbox, mailboxes, series or error"New value: +"Which card to draw."wait_for_report1 field changedOutput schema / properties / view / descriptionPrevious value: -"test, report, mailbox, mailboxes, series or error"New value: +"Which card to draw."get_message_source1 field changedInput schema / properties / slug / descriptionPrevious value: -"The slug of a test or a series letter whose message has already arrived."New value: +"The slug of a test whose message has already arrived."get_report1 field changedInput schema / properties / slug / descriptionPrevious value: -"The slug of a test or of a letter in a series mailbox, the last part of the report URL."New value: +"The slug of a test, the last part of the report URL."get_test_address1 field changedInput schema / properties / include_placement / descriptionPrevious value: -"Also check which folder (inbox, spam, promotions) the email lands in at different mailbox providers, from the same send. The email then goes to a list of recipients instead of one address and needs a marker in the subject; both come back. Some provider inboxes are public test inboxes: the subject, the sender name and the folder are shown on a public web page. Only set it when the person asked for placement and the message is not confidential; say so to them."New value: +"Also check which folder (inbox, spam, promotions) the email lands in at different mailbox providers, from the same send. The email then goes to a list of recipients instead of one address and needs a marker in the subject; both come back. Some provider inboxes are public test inboxes: the subject, the sender name and the folder are shown on a public web page, so it suits messages that are not confidential."close_series_mailboxget_series_letterslist_series_mailboxesopen_series_mailboxwrite_fix_planclose_series_mailboxget_message_source1 field changedInput schema / properties / slug / descriptionPrevious value: -"The slug of a test whose message has already arrived."New value: +"The slug of a test or a series letter whose message has already arrived."get_report7 fields changedInput schema / properties / slug / descriptionPrevious value: -"The slug of a test, the last part of the report URL."New value: +"The slug of a test or of a letter in a series mailbox, the last part of the report URL."Output schema / additionalPropertiesAdded value: +trueOutput schema / descriptionAdded value: +"What every tool returns for the card; `view` says which card."Output schema / properties / resultRemoved value: -{
- "title": "Result",
- "type": "string"
-}Output schema / properties / viewAdded value: +{
+ "description": "test, report, mailbox, mailboxes, series or error",
+ "title": "View",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "view"
+]Output schema / titlePrevious value: -"get_reportOutput"New value: +"Output"get_series_lettersget_test_address11 fields changedInput schema / properties / include_placementAdded value: +{
+ "default": false,
+ "description": "Also check which folder (inbox, spam, promotions) the email lands in at different mailbox providers, from the same send. The email then goes to a list of recipients instead of one address and needs a marker in the subject; both come back. Some provider inboxes are public test inboxes: the subject, the sender name and the folder are shown on a public web page. Only set it when the person asked for placement and the message is not confidential; say so to them.",
+ "title": "Include Placement",
+ "type": "boolean"
+}Input schema / properties / lang / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / lang / defaultPrevious value: -"en"New value: +nullInput schema / properties / lang / descriptionPrevious value: -"ISO code of the language the report and the fix plan are written in for the person who opens the report page, for example \"en\", \"de\" or \"pt-BR\". Unknown codes fall back to English."New value: +"ISO code of the language the report and the fix plan are written in for the person who opens the report page, for example \"en\", \"de\" or \"pt-BR\". Defaults to the language of the conversation. Unknown codes fall back to English."Input schema / properties / lang / typeRemoved value: -"string"Output schema / additionalPropertiesAdded value: +trueOutput schema / descriptionAdded value: +"What every tool returns for the card; `view` says which card."Output schema / properties / resultRemoved value: -{
- "title": "Result",
- "type": "string"
-}Output schema / properties / viewAdded value: +{
+ "description": "test, report, mailbox, mailboxes, series or error",
+ "title": "View",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "view"
+]Output schema / titlePrevious value: -"get_test_addressOutput"New value: +"Output"list_series_mailboxesopen_series_mailboxwait_for_report6 fields changedOutput schema / additionalPropertiesAdded value: +trueOutput schema / descriptionAdded value: +"What every tool returns for the card; `view` says which card."Output schema / properties / resultRemoved value: -{
- "title": "Result",
- "type": "string"
-}Output schema / properties / viewAdded value: +{
+ "description": "test, report, mailbox, mailboxes, series or error",
+ "title": "View",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "result"
-]New value: +[
+ "view"
+]Output schema / titlePrevious value: -"wait_for_reportOutput"New value: +"Output"write_fix_planget_message_source1 field changedInput schema / properties / slug / descriptionAdded value: +"The slug of a test whose message has already arrived."get_report1 field changedInput schema / properties / slug / descriptionAdded value: +"The slug of a test, the last part of the report URL."get_test_address1 field changedInput schema / properties / lang / descriptionAdded value: +"ISO code of the language the report and the fix plan are written in for the person who opens the report page, for example \"en\", \"de\" or \"pt-BR\". Unknown codes fall back to English."wait_for_report4 fields changedInput schema / properties / slug / descriptionAdded value: +"The slug get_test_address returned, the last part of the report URL."Input schema / properties / timeout_seconds / descriptionAdded value: +"How long to block waiting for the message and its analysis, in seconds. The checks are ready in well under a minute; the fix plan takes about another one. Past this the tool returns what it has."Input schema / properties / timeout_seconds / maximumAdded value: +600Input schema / properties / timeout_seconds / minimumAdded value: +5get_message_sourceget_reportget_test_addresswait_for_reportVerify emails (syntax, MX, SMTP mailbox, catch-all), test email DNS and check Spamhaus blocklists.
Verify email deliverability with RFC format, MX, SMTP and disposable-domain checks.
Check whether an email address is real and will accept mail before you send to it.
Validate emails without sending mail: syntax, MX, disposable, role and typo checks, SPF/DMARC.
Add one secure layer between your agents and this server.