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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so the safety profile is covered. The description adds only what data is surfaced (quota, plans, rate) and says nothing about auth requirements, rate limits, or freshness of the values, so it adds modest value beyond structured fields.

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?

A single front-loaded sentence that names the resource and the three data points with no filler. Nothing could be removed without losing 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?

With zero parameters, a complete annotation set, and an output schema documenting the return shape, the description only needs to convey scope — which it does. It stops short of noting any account-level access requirements, but nothing essential for invoking 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?

The tool takes zero parameters, which is the baseline-4 case. There are no parameter semantics for the description to clarify, and the schema fully covers the empty argument object.

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 ('Show') plus three concrete resources (remaining mailbox quota, active plans, request rate) scoped to the account. This is clearly distinguishable from every sibling, which operate on mailboxes, messages, or domains.

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 implied by the tool's scope: an agent wanting account-level quota/plan/rate info should call it. However, no explicit when-to-use guidance, prerequisites, or alternatives are given, and none of the siblings overlap enough to require routing advice.

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?

Goes well beyond the annotations by disclosing quota cost ('Uses 1 unit of the account's mailbox quota'), noting that reading mail is free, and stating addresses 'never expire' so deletion is required. These are meaningful operational traits the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true) do not convey.

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 core purpose, then cost, then lifecycle. Every sentence carries distinct information with no redundancy or 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 values need not be described. The description covers the essential non-schema facts an agent needs: quota impact, non-expiry, deletion requirement, and the follow-up tool for receiving mail.

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%, with 'name' and 'domain' fully documented in the schema, including the 'leave empty for random' behavior and the list_domains reference. The description adds no parameter detail beyond what the schema already provides, 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 ('Create a new temporary email address') plus a scope note that it can receive mail immediately. This clearly distinguishes it from siblings like list_mailboxes, delete_mailbox and the message-reading tools.

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?

Provides explicit lifecycle guidance: 'call delete_mailbox when it is no longer needed' and 'use wait_for_message to get the mail it receives.' It routes the agent to the right follow-up tools, though it doesn't explicitly say when not to use this tool or name a competing alternative (there is no sibling create tool).

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?

Annotations already declare destructiveHint=true and idempotentHint=false, and the description goes further by disclosing the concrete consequences: the address stops receiving, cannot be restored, and used quota is not returned. These are operational facts an agent cannot derive from the annotation flags alone.

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 irreversible consequence and the quota caveat front-loaded before the usage condition. No filler or restated name/title 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 single-parameter destructive tool with a full annotation set and an output schema, the description covers what the agent most needs: irreversibility, loss of receiving capability, and quota non-return. 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 description coverage is 100% and the schema already explains that 'email' is the address returned by create_mailbox or list_mailboxes. The description adds no format, casing, or lookup guidance beyond that, so the 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 ('Delete') and resource ('an address'), with the scope qualifier 'for good' clarifying it is permanent. No sibling tool performs deletion, so it is unambiguous within the toolset.

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 an explicit invocation condition: 'Only call this when the user's task no longer needs the address.' That is real when-to-use guidance rather than implied usage. It does not name alternatives, but no sibling offers a non-destructive substitute, so there is little to route against.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a behavioral nuance — custom domain names are permitted only on verified domains, and a flag for shared-domain availability — but the phrasing is ambiguous and does not explain the difference between own vs. shared domains.

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?

A single sentence that front-loads the resource being listed. The parenthetical adds a caveat without bloating the text, though its wording is denser than necessary.

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 an output schema present, return values need not be explained, and there are no parameters or authorization caveats the description must carry. It states what is listed and the shared-domain flag, which is adequate for a read-only, parameterless lister.

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 zero parameters, so the baseline is 4. Nothing in the description contradicts 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?

States a specific verb ('List') and resource (the account's domains), plus a secondary output (shared-domain availability). It is clearly distinguishable from all siblings, none of which deal with domains. The parenthetical about custom names on verified domains is slightly cryptic but does not obscure the core 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?

There is no explicit when-to-use guidance and no alternatives named. The tool is plausibly a prerequisite for create_mailbox, but the description never says so. Usage is only inferable from context, not stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds ordering ('newest first') and that counts accompany each entry, which is real behavioral context, but it says nothing about pagination, truncation, or how the open-world remote fetch behaves.

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?

A single well-formed sentence that front-loads the verb and resource and appends the two useful qualifiers. Nothing is redundant, though the sentence is thin enough that it leaves obvious questions (pagination, filtering) unaddressed.

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 an output schema present, return-value shape needn't be described, and the one optional parameter is fully covered by the schema. The remaining gap is the absence of any usage context against sibling list tools, which is minor for a simple read.

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% for the single optional 'limit' parameter (default 20, max 100), so the schema fully documents it. The description adds no syntax or semantics beyond what the schema provides, which is the expected baseline here.

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 the account's addresses') and adds scope detail (ordering, message counts). It does not explicitly differentiate itself from siblings like list_messages or list_domains, and it renames the resource from 'mailboxes' (tool name) to 'addresses', which creates mild terminology drift.

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 no when-to-use guidance, no prerequisites, and never names an alternative such as list_messages or list_domains. The agent must infer from the tool name alone that this is the enumeration entry point for mailbox resources.

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?

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral facts the annotations do not convey: a fixed 24-hour lookback window, newest-first ordering, and that message bodies are omitted from results. It could still note whether the 24h window is fixed or derived from a parameter.

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?

A single sentence front-loads the filtering/window constraint and ordering, then appends the sibling routing in parentheses. Every clause earns its place with no redundancy.

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 an output schema present, return values need no explanation, and the description covers the non-obvious behaviors (24h window, ordering, body omission). It is essentially complete for a simple filtered list tool; only the nature of the time window (fixed vs. relative) is left slightly ambiguous.

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%, with every filter (email, limit, unread_only, from_contains, subject_contains) documented in the schema itself. The description adds no parameter-level detail beyond that, so the baseline 3 applies when the schema carries the load.

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 (List), resource (messages), recipient scope (an address), time window (last 24 hours), and ordering (newest first), then explicitly distinguishes itself from read_message. An agent can separate this from read_message without opening either 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?

It explicitly routes body-reading to read_message ('no body; use read_message'), which is a clear when-to-use-alternative. It does not address when to prefer wait_for_message or how this relates to the mailbox-list siblings, so it stops short of full when/when-not coverage.

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?

Annotations only hint at mutation via readOnlyHint=false; the description supplies the concrete side effect ('Marks the message as read'), which is exactly the kind of behavior an agent needs before calling. It does not cover failure modes or whether re-reading re-marks an already-read message, but idempotentHint=true already addresses the latter.

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 clauses, front-loaded with the action and its return payload, then the side effect. No filler and nothing redundant with the schema or annotations.

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 an output schema present, return values need not be explained, and annotations cover safety/idempotency; the description's coverage of the read-marking side effect closes the main gap. Minor omissions (behavior when the message id is invalid) are acceptable for a simple read tool.

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 schema already documents email, message_id and the max_chars truncation bound. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 correct.

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+resource ('Read one message') and goes further by naming what is extracted from the body: text, `otp`, `codes`, `links`. It is clearly distinguishable from list_messages by the singular scope, though it never names the sibling explicitly.

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?

No explicit when-to-use or when-not-to-use guidance; the workflow is only implied (read a single message obtained from list_messages, per the schema note on message_id). No mention of how this relates to wait_for_message for a not-yet-arrived 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?

Discloses the key non-obvious side effect that explains the annotation profile (readOnlyHint=false, idempotentHint=false): 'Returning a message marks it as read, so the next call waits for the next one.' It also explains the timeout/status contract and the retry expectation, which annotations alone cannot convey.

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 chunks, front-loaded with the core behavior and then the side effect and the timeout remedy. Every sentence carries operational information; nothing is 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?

With an output schema present the description is not obliged to enumerate return fields, yet it still names otp/codes/links/status because they drive the agent's next action, and it covers the read-marking side effect and retry loop. Nothing needed to call 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 all five parameters (email, max_chars, from_contains, timeout_seconds, subject_contains) are already documented in the schema. The description only echoes filter behavior generically ('matching the filters') without adding syntax or format detail, 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-and-resource with scope: 'Return the newest UNREAD message matching the filters, or wait until one arrives.' An agent can distinguish it from list_messages and read_message purely from this sentence, and the blocking/waiting semantics are named explicitly.

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 clear usage context: it is the polling/waiting variant, and on a 'timeout' status the agent should call again if the email may still arrive. It does not, however, contrast itself with list_messages or read_message for the non-blocking case, so the when-not guidance is only implicit.

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