Read verification codes (OTP) and test email sent to your catch-all test hostnames.
Scored across 4 tools
Each tool has a distinct scope: list_domains covers hostnames, list_messages returns metadata, get_message returns full bodies, and get_latest_otp targets the single newest message's code. The only overlap is that list_messages and get_latest_otp both surface OTPs and metadata, but the 'newest single message' vs 'recent list' distinction is clear from the descriptions.
All four tools follow a strict snake_case verb_noun pattern (get_latest_otp, get_message, list_domains, list_messages), with get_/list_ mapping cleanly to single-resource vs collection operations.
Four tools is well-scoped for a narrow receive-only inbox/OTP API; each tool covers a distinct need (domains, listing, full message retrieval, OTP extraction) with no filler.
The core lifecycle for an inbound mail/OTP service is covered: discovering domains, listing messages, fetching a body, and extracting the newest OTP with retry guidance. Minor gaps exist (no delete/purge of messages, no filtering by sender/subject, no blocking wait-for-OTP), but agents can work around them by polling.
Return the newest message sent to an address and the verification code (OTP) extracted from it. Returns found=false when nothing has arrived yet; wait a few seconds and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Full recipient address, e.g. signup-42@otp.example.com. Case-insensitive. | |
| since | No | Optional ISO 8601 time. Ignore messages received before it, e.g. the moment the test started. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added value is the sentinel result semantics and the retry pattern, which are genuinely useful behavioral details beyond structured fields. It leaves out whether the OTP can be absent from an existing message or any rate/expiry behavior on the mailbox.
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 sentences, zero filler, with the primary outcome front-loaded and the failure/retry case immediately after. Every sentence carries information the agent needs.
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 low-complexity, read-only lookup with two fully documented parameters, the description covers the success concept, the not-found sentinel, and the retry loop. With no output schema, a fuller accounting of the returned message fields would help, but nothing essential to calling it correctly 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 100%, so both `to` and `since` are already fully documented with examples, and the description adds no new meaning about them. The mention of 'an address' and 'newest' loosely maps to the schema but is baseline-equivalent.
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 names a specific verb (return), a specific resource (the newest message plus the OTP extracted from it), and the address it is keyed to, which clearly separates it from list_messages and get_message. It stops short of explicitly naming those siblings, so an agent must infer the distinction from 'newest' and 'extracted'.
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 concrete operational guidance for the polling case: found=false means nothing has arrived yet, wait a few seconds and retry. It does not state when to prefer get_message or list_messages instead, so there is no explicit exclusion, but the polling context is clearly established.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one message by id, including its plain-text body (truncated to 20,000 characters).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Message id from list_messages or get_latest_otp. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that – the body is returned as plain text and truncated at 20,000 characters – but says nothing about the not-found case, error behavior, or the other fields returned.
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 sentence, front-loaded with the action and resource, with the truncation caveat appended where it is most useful. There is no redundant or filler wording.
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 tool with annotations covering safety and no output schema, the definition covers the essentials, and the truncation note is a meaningful addition. The minor gap is that "including its plain-text body" implies other fields (sender, subject, timestamp) exist in the response but never names them.
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 id parameter is already documented in the schema, including its provenance. The description adds nothing beyond it, but with full coverage and only one documented parameter, the baseline is satisfied.
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?
"Return one message by id" is a specific verb plus resource, and "by id" implicitly separates it from get_latest_otp and list_messages, which work off different selection criteria. It stops short of naming those siblings, so the differentiation is inferable rather than stated.
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?
Usage is only implied: the tool takes an id, and the schema notes that the id comes from list_messages or get_latest_otp. There is no explicit statement of when to call this versus those two alternatives, nor any exclusion such as "do not use for the latest OTP."
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the hostnames this API key can receive mail on, with their status. Any address at an active hostname reaches the inbox.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a safe, closed-world read, so the bar is lower, and the description adds real value on top by disclosing the API-key scoping, that each hostname carries a status, and the operational meaning of 'active' (any address there reaches the inbox). It stops short of describing the return shape or whether any pagination is involved.
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 zero filler, front-loaded with what is listed, followed by the semantic note that makes the status field actionable. 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 zero-parameter read with annotations covering the safety profile, the description is nearly sufficient: it says what is returned conceptually (hostnames plus status) and what status means. The only remaining gap is the concrete response shape, which has no output schema to cover it.
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 takes no parameters, so the baseline is 4 and there is no parameter semantics the description could or should explain. Nothing here conflicts with the empty schema.
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 gives a specific verb and resource ('List the hostnames') and clarifies that these are the receiving domains scoped to the current API key, which disambiguates the name 'list_domains' from a generic domain-management tool. It does not explicitly name a sibling, but the message/OTP siblings are clearly unrelated, so the purpose is unambiguous without that.
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?
Usage is only implied: an agent can infer this is the discovery call for which hostnames are available for inbound mail. There is no explicit 'use this when...' statement, no note on when to call it versus the message-reading siblings, and no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent messages, newest first, optionally only those sent to one address. Returns metadata and the OTP, not the body.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Full recipient address, e.g. signup-42@otp.example.com. Case-insensitive. | |
| limit | No | How many messages to return (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds the valuable disclosure that responses contain metadata and the OTP but never the message body. It also adds the sort order, which matters when consuming results. It stops short of saying what metadata fields appear or whether results are paginated, but that is a minor gap given 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?
Two short sentences with no filler, and the most decision-relevant facts (scope and ordering) are front-loaded before the return-content clarification.
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 read-only listing tool with only two fully documented parameters, the description covers purpose, ordering, filtering, and return payload, which is enough to call it correctly. The only real omission is how the 50-message cap interacts with a short result set, i.e. whether truncation occurs, which is minor.
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 both `to` and `limit` are fully documented in the schema, including format, case-insensitivity, default, and bounds. The description only restates that the address filter is optional, adding essentially no meaning beyond the schema, so the baseline of 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 and resource ("List recent messages") plus ordering ("newest first"), an optional scope ("only those sent to one address"), and what is returned ("metadata and the OTP, not the body"). The explicit note that the body is not returned implicitly distinguishes it from get_message, so an agent can route correctly without opening the schema.
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 "optionally only those sent to one address" signals when the filter is relevant, which is implied usage guidance. However, it never names siblings such as get_message or get_latest_otp or states when to prefer this list over them, leaving the agent to infer the boundary.
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_latest_otpget_messagelist_domainslist_messagesTest-inbox API for email and SMS: create inboxes, long-poll messages, extract OTPs and links.
Disposable email addresses for tests and agents: register, wait for mail, extract codes and links.
Disposable email inboxes for AI agents — read messages and verification codes.
Disposable test mailboxes on a real domain: send, receive and assert on real email.
Add one secure layer between your agents and this server.
