Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral burden, and it does well: it states that the inbox is temporary, can receive mail, and that the response includes the address and expiration time. It does not cover every operational detail such as cleanup or duplicate-name behavior, but the essential lifecycle is 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 three tight sentences: the core action, the usage context, and the return value. Every sentence adds information, and there is no redundant or filler content.

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 create tool with no required parameters and no output schema, the description covers what the tool does, when to use it, and what the response contains. It could mention interactions with sibling tools or what happens if a requested domain/username is unavailable, but those are minor gaps given the schema already documents allowed values.

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 already provides 100% coverage of both optional parameters, including the allowed characters for username and the fact that domain comes from list_domains. The description adds no parameter-specific meaning, so it stays at the baseline expected when the schema is fully documented.

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 action and resource: creating a temporary email address that can receive mail. It also clarifies the intended use case (signups, trials, avoiding real addresses), which makes the tool's role unambiguous compared to siblings like list_messages, delete_inbox, and wait_for_email.

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 explicitly says when to use the tool: when the user needs an email address for a signup, trial, or similar situation. It does not mention alternatives or exclusions, but because this is the only creation-focused sibling, the guidance is still clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the destructive and irreversible nature of the operation ('Delete an inbox and everything in it'), which is important since no annotations are provided. It also mentions the immediate effect, though it doesn't explicitly state irreversibility, but the implication is strong.

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 concise, using just two sentences to convey the action, scope, and usage context. No redundant or extraneous information is present.

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 provides sufficient context for a simple delete operation: it explains the action, the scope (everything in the inbox), and the typical usage scenario. No output schema is needed, and the parameter is clearly defined, so the description is complete.

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 only parameter 'address' is fully described in the schema ('The inbox address to delete'), and the description does not add further semantic detail beyond that. Schema coverage is 100%, so the baseline of 3 is appropriate.

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 states the action ('Delete an inbox and everything in it') with a specific verb and object. It distinguishes itself from sibling tools like create_inbox without needing to name them.

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 explicitly explains when to use the tool: 'only needed when the user wants it gone immediately', noting that inboxes normally expire on their own, which provides clear guidance on when this tool is appropriate versus relying on expiration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description notes two behavioral facts: 'Requires a paid API key' and the no-guessing policy: 'If no code is found with confidence, that is reported rather than guessed, because a wrong code is worse than none.' This gives the agent expectations about authentication prerequisites and failure behavior, but doesn't cover whether the operation is strictly read-only or how the no-code result is 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?

Three sentences, no filler: action, usage context, key requirement, and failure behavior. The most important information is front-loaded. 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 two-parameter read-like tool with high schema coverage, the description includes the trigger, required auth, and failure mode. It does not specify the output structure or edge cases like multiple codes, but these are minor given the tool's simplicity.

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 already covers both parameters with descriptions ('The inbox address'; 'Message id from wait_for_email or list_messages'). Description reiterates the wait_for_email relationship but adds no new format, constraints, or semantics beyond the schema, 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?

The description opens with the specific action 'Pull the verification or one-time code out of a message,' naming the verb, resource, and result. This clearly distinguishes it from siblings like list_messages or read_message by focusing on extraction of a code rather than retrieving whole messages or managing inboxes.

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 an explicit invocation condition: 'Use this after wait_for_email when the user needs a code to complete a signup or login.' This tells the agent when to call it relative to wait_for_email. However, it does not name two or more alternatives or state when not to use other tools like read_message, so it falls short of a full when/when-not guide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description indicates that the tool performs a list operation, which implies a read-only behavior with no side effects. However, it does not explicitly state permissions or output format, but given the simplicity, it is sufficiently transparent.

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 concise, using only two sentences to convey the tool's function and usage context. It avoids unnecessary details.

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 provides complete context for a parameterless tool, including its purpose and when it is needed relative to sibling tools. There is no ambiguity or missing information.

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 no parameters, so there is nothing to explain. The description does not need to elaborate on any input, making it fully clear.

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 states the tool's purpose: to list domains available for inbox creation. It also differentiates it from create_inbox by noting that create_inbox picks a domain automatically. This makes the purpose unambiguous.

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 explicitly advises when to use the tool, namely when a specific domain is desired, and contrasts it with create_inbox's automatic selection. This gives clear usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does disclose that the tool is non-blocking (it lists messages already arrived rather than waiting) and that results are newest first. However, it does not describe what the response contains, whether messages are returned as summaries or full content, or whether any side effects occur.

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 wasted wording. The core action and ordering are in the first sentence, and the usage distinction is in the second, making it easy to scan and understand.

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 tool with one required parameter, the description is largely complete: it explains what the tool does, the ordering, and when to use it. The lack of an output schema could make response-shape details useful, but they are not necessary for selecting or invoking this tool 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?

The schema already fully documents the single parameter 'address' as 'The inbox address.' The description adds only that the tool operates on an inbox, which is implied by the title and schema. This meets the baseline but adds no extra parameter semantics.

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 ('List'), a specific resource ('messages in an inbox'), and adds scope ('currently') and ordering ('newest first'). This clearly distinguishes the tool from siblings like read_message, which reads a single message, and wait_for_email, which waits for new arrivals.

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 explicitly says to use this tool 'to see what has already arrived, rather than waiting for something new,' which gives clear guidance relative to wait_for_email. It does not explicitly mention alternatives like read_message or delete_inbox, but the context makes the main distinction clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose behavioral traits itself. It clearly states this is a read operation returning the full body and attachment list, which implies non-destructive behavior. It does not explicitly confirm no side effects or mention permissions, but the verb 'Read' and resource scope make the safety profile evident.

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, no wasted words. The action and resource come first, followed by usage conditions and an explicit alternative. 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 tool with two required parameters and no output schema, the description provides sufficient context: what it reads, what it returns, and when to use it instead of the key sibling. No critical operational detail 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%, with both 'address' and 'message_id' described meaningfully. The message_id parameter even notes it comes from wait_for_email or list_messages, which is helpful. The description body adds no extra parameter semantics, but the schema already carries the full load, so baseline 3 is appropriate.

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') and resource ('a message's full body and attachment list'), making the tool's purpose unambiguous. It also distinguishes itself from the sibling get_verification_code by addressing the case where code extraction fails. The title reinforces the same purpose.

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 explicit usage conditions: use when the user wants to see an email's actual content, or when get_verification_code could not find a code. It names an alternative tool and specifies the scenario that selects this one, leaving no ambiguity about when to invoke read_message.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full behavioral disclosure. It clearly states the timeout limit ('up to 55 seconds'), the return behavior ('Returns the message summary, or reports that nothing arrived'), and the critical nuance that a missing email is not an error. The retry semantic 'calling this again continues waiting' goes beyond what the schema conveys and is highly valuable for an agent.

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 four sentences, each serving a distinct purpose: action, usage context, return value, and error semantics. It is front-loaded with the core behavior and avoids redundant restatements of the title or schema. 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 two-parameter tool with no output schema, this description is complete. It covers what the tool does, when to use it, what it returns, and how to interpret the empty result. An agent can invoke it correctly and know how to proceed on no result, which is the main uncertainty for a wait operation.

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. The description adds context that the timeout is used after signup/password reset flows, but it does not add significant meaning beyond the schema's parameter descriptions. The schema already documents address as 'The inbox address to watch' and timeout with default and maximum values.

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 states the tool's function: 'Wait for the next email to arrive at an inbox, up to 55 seconds.' The verb 'wait' and resource 'email at an inbox' make the action unambiguous, and the 'arrive' distinction separates it from siblings like list_messages and read_message that handle existing messages. The signup/password reset context reinforces the specific scenario.

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 explicitly says when to use the tool: 'Use this straight after triggering a signup or password reset.' It also explains retry behavior with 'calling this again continues waiting.' However, it does not mention alternatives or when not to use it, such as when the email may already have arrived and list_messages would be appropriate, so it stops short of full exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.