Test an email before it goes out: a disposable address, 41 checks with RFC citations, a fix plan.
Scored across 4 tools
Each tool occupies a distinct step in the workflow: reserving a test address, waiting for analysis, reading an existing report, and retrieving the raw message source. get_report and wait_for_report are related but clearly separated by non-blocking slug-based retrieval versus blocking on a new submission.
Three tools follow a clean get_* pattern, and wait_for_report uses the same object noun 'report' with a different verb. The overall snake_case verb_noun convention is predictable, with only a minor verb-style deviation.
Four tools is well-scoped for a focused email-spam-testing server. Each tool earns its place and there is no redundancy or padding.
The tool surface covers the complete flow: create a test address, wait for the message to be analyzed, retrieve the report, and inspect the raw message. No essential operation appears missing for the stated purpose.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the result is the unmodified received message with both bodies and headers, which goes beyond what the schema alone shows. It does not claim any side effects, and nothing suggests a contradiction.
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 with no filler: the first defines the returned artifact, the second gives the motivating scenario. It is front-loaded and every sentence earns its place.
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 simple one-parameter read tool with an output schema, the description covers what is returned and when it is useful. However, it leaves the slug parameter undefined and does not route the agent away from sibling tools, leaving some selection and invocation details to inference.
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 0%, and the description does not explain the 'slug' parameter at all. The name implies an identifier for the message, but the tool description provides no guidance on what value should be passed or how to obtain it.
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 identifies the tool's output: the message exactly as received, including headers, both bodies, and source. It conveys the core purpose of retrieving raw message data, though it does not explicitly differentiate itself from sibling tools by name.
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 gives a concrete use case: when a finding points at a header and the agent needs the actual sent message rather than its belief about it. This provides clear context for when to invoke the tool, but it does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an existing report by its slug, without waiting.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It communicates that this is a read operation, applies only to existing reports, and does not block or wait. For a simple read tool with an output schema, this is meaningful behavioral coverage, though it does not mention failure modes like a missing or not-yet-generated report.
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 entire description is one efficient, front-loaded sentence. Every word earns its place: the action, the target, the identifier, and the behavioral qualifier are all present with no fluff.
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 one-parameter read operation with an output schema, the description is nearly complete. It tells the agent what to call, what input is needed, and that it returns immediately. The only notable gap is the lack of explicit guidance on what happens when the report does not exist or is still being generated.
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 provides only a required string named 'slug' with no description, and schema coverage is 0%. The description mentions 'by its slug' but adds no real semantics about what a slug is, how it is formatted, or how to obtain it. The description does not compensate for the undocumented parameter.
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 ('Read'), a concrete resource ('existing report'), and the exact lookup mechanism ('by its slug'). The qualifier 'without waiting' also separates it from the sibling wait_for_report, so an agent can distinguish this tool without inspecting schemas.
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: this is for reports that already exist and should be read immediately, without polling or waiting. It does not explicitly name wait_for_report as the alternative or state when not to use this tool, so it falls just short of full explicit routing guidance.
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 message to.
Returns the address and the URL its report will appear at. The address
accepts exactly one message and expires after an hour.
lang is the language the fix plan will be written in, as an ISO code
("de", "pt-BR"). Set it to the language the person you are working for
reads: it decides the plan and the per-check findings on the page they
open, and it has to be decided now because the message arrives minutes
later over SMTP, which carries no hint of who is waiting for it. Unknown
codes fall back to English rather than failing.
What you get back from wait_for_report stays English whatever you set: the
check lines it quotes come from the report's `summary` field, which is
English by design so a script reading it reads the same words every time.
The person following report_url sees their own language.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and exceeds it: exactly one message, one-hour expiry, unknown-language fallback to English, and the English-vs-localized report distinction are all disclosed. This gives the agent reliable expectations for side effects and edge cases.
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 detailed but front-loaded and every sentence earns its place. The first sentence states the purpose, the second covers outputs and constraints, and the rest explains the parameter and the downstream language behavior without repetition.
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, no-annotation tool, this is complete: it explains the return value, lifetime, constraints, parameter semantics, edge-case behavior, and downstream interaction with wait_for_report. Nothing needed for correct invocation 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 description coverage is 0%, but the description fully compensates for the lang parameter: meaning, ISO code examples, why it must be chosen now, and the fallback behavior for unknown codes. The agent knows both how to set it and what happens if it is wrong.
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 first sentence states a specific verb and resource: 'Reserve a single-use address to send a draft message to,' followed by what is returned. This clearly separates it from the sibling tools, which deal with messages, reports, and waiting.
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 gives clear usage context: set lang to the language the recipient reads, decide it now, and expect a time-limited address. It mentions wait_for_report's behavior downstream but does not explicitly state when to prefer this tool over each sibling or when not to use it.
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.
Blocks rather than returning "not ready yet": an agent told to poll writes a
sleep loop and usually gives up before the analysis finishes.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool blocks rather than returning 'not ready yet', which is a critical non-obvious behavior that directly affects how an agent should use it. It does not mention timeout failure behavior, but the main blocking trait is clearly disclosed.
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 short and front-loaded: the core behavior is stated first, and the second sentence explains why blocking matters. It is concise, though 'then summarise it' could be clearer and slightly weakens the precision.
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 description covers the main purpose and the blocking advantage, and an output schema exists so return details do not need to be spelled out. However, it leaves parameter semantics unexplained and does not mention timeout outcomes, which are relevant for a tool with a timeout parameter and no annotation coverage.
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 input schema has 0% description coverage, and the description does not explain what 'slug' refers to or how timeout_seconds behaves. It implies the tool waits on a message/report but does not connect the parameters to that behavior, leaving the agent to infer their meanings.
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 identifies the tool as a blocking wait: it waits until the message has arrived and been analysed, then summarises it. It conveys the main purpose distinctly from the sibling get_report/get_message_source tools, though 'summarise it' is slightly ambiguous about what exactly is summarised.
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 gives a strong use signal: use this instead of writing a polling loop, because polling tends to give up too early. It does not explicitly name sibling alternatives or state when not to use it, but the behavioral contrast with polling is well articulated.
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_message_sourceget_reportget_test_addresswait_for_reportVerify email deliverability by SMTP. Catch-all/disposable/role detection. EU-hosted, GDPR-ready.
Verify emails — deliverability, disposable/role/free detection, MX validity, domain age.
Disposable test mailboxes on a real domain: send, receive and assert on real email.
Fast email validation at the edge: syntax, MX records, disposable-domain detection.
Add one secure layer between your agents and this server.
