Send a test email, get SPF, DKIM, DMARC, TLS and IPv6 results plus sender rules. No key.
Scored across 3 tools
The three tools map to distinct phases of a single workflow: create a throwaway address, poll for analysis, then fetch the full report. The only soft boundary is between wait_for_report and get_report, both of which can return a digest, though the descriptions clarify that one blocks/polls and the other retrieves the complete check set.
All three names follow the same snake_case verb_noun pattern (create_test_address, get_report, wait_for_report), with verbs that accurately reflect each action.
Three tools is exactly the size of the create-wait-fetch workflow this server implements; nothing feels padded or missing.
The core lifecycle (provision address, await analysis, retrieve report) is fully covered with no dead ends. Minor gaps exist: no way to delete or list test addresses, and no direct status check short of calling wait_for_report.
Create a temporary echo.email address. Send one email to it from the system under test, then call wait_for_report with the returned token and key. The address dies after 10 minutes without a wait_for_report call and accepts one message.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses important lifecycle behavior: the address expires after 10 minutes without a wait_for_report call and accepts only one message. It still omits some operational details such as whether wait_for_report extends the expiration or what happens after expiry.
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 short sentences, front-loaded with the purpose and followed by the required workflow and lifecycle constraints. Every sentence contributes useful information.
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 zero-parameter setup tool with no output schema, the description is complete enough: it explains what the tool creates, how to use the resulting address, what values are returned, and the expiration/message constraints.
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 zero input parameters, so the baseline is 4. The description mentions returned token and key but correctly does not invent parameter semantics for a no-argument tool.
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: 'Create a temporary echo.email address.' It also distinguishes the tool from its siblings by explaining that it is the setup step before calling wait_for_report.
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 clear procedural usage guideline: send one email from the system under test, then call wait_for_report with the returned token and key. It does not state when not to use the tool or name any alternative beyond the next workflow step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a finished report as JSON: the digest plus every check (SPF trace, DKIM, DMARC, BIMI, TLS, IPv6, images, links, unsubscribe, headers, DNS log).
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It discloses the return payload well (digest plus named checks), but says nothing about failure behavior when the report is pending, permissions, or whether results are cached/immutable.
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?
One front-loaded sentence with a compact, informative enumeration; every element adds signal. The parenthetical list is long but each entry is meaningful.
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?
With no output schema, the content list is valuable and needed, but the definition omits the report_id contract and the not-ready path, both of which an agent must know to invoke this correctly.
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 0% for the single required report_id, and the description never explains its format or where the agent obtains it (presumably from create_test_address or wait_for_report). With zero structured documentation, the description should have compensated and does not.
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?
Specific verb (fetch) and resource (finished report) with an explicit enumeration of returned sections that makes its scope concrete. It distinguishes itself from wait_for_report only implicitly via the word 'finished'.
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?
'Finished report' implies it should be called only after completion, which hints at the wait_for_report sibling, but no alternative or precondition is stated explicitly. Nothing tells the agent what to do if the report is not yet finished.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait up to timeout_s seconds (max 50) for the email sent to a test address to be analysed. Returns status waiting or received (call again), or done with a digest: score, SPF, DKIM, DMARC, TLS, IPv6 and the failing sender requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key from create_test_address | |
| token | Yes | Token from create_test_address (the address local part) | |
| timeout_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it caps the wait ('max 50'), discloses the three possible return states and what each means, and lists the digest fields. It omits error/timeout-expiry behaviour and any auth or rate-limit notes.
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 compact sentences with the timeout constraint front-loaded and the return states following. Dense but every clause carries information; the digest field list is slightly crammed but 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?
Given three simple parameters, no output schema, and no annotations, the description covers the timer, the states, and the eventual payload. The main residual gap is what the agent should do when the timeout expires without a 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 67% — key and token are documented, timeout_s is not — and the description compensates by explaining timeout_s as a wait duration with a max of 50. That adds real meaning beyond the schema's bare minimum/maximum bounds.
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 opens with a specific verb and resource: 'Wait ... for the email sent to a test address to be analysed', and it enumerates what the finished digest contains. It is easy to distinguish from create_test_address, but there's no explicit contrast with the sibling get_report, so the agent must infer the division of labour.
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?
Polling behaviour is implied by 'call again' on the waiting/received states, which is useful operational guidance. However, it never says when to prefer this over get_report, nor what to do if the timeout elapses — usage is implied rather than stated.
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.
create_test_addressget_reportwait_for_reportEmail deliverability check: MX, SPF, DKIM, DMARC, blacklists, MTA-STS, DNSSEC, BIMI. Graded, no key.
Test an email before it goes out: a disposable address, 41 checks with RFC citations, a fix plan.
Check SPF, DKIM, DMARC, blocklists, reverse DNS and email headers against Gmail/Yahoo sender rules.
Free, no login: verify an email address, check SPF/DKIM/DMARC, explain SMTP errors, build SPF/DMARC.
Add one secure layer between your agents and this server.
