zoomfort

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the API-key scoping detail and says nothing about result ordering, pagination, or what an address object contains — acceptable for a trivial read, but no real behavioral value added.

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 short, front-loaded sentence with no filler. Every word earns its place and the core action leads the sentence.

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-only listing with no output schema, the description is essentially sufficient — the agent knows it gets a list of addresses. A brief note on the shape of each address entry or empty-result behavior would make it fully 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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless 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?

States a specific verb (List) and resource (inbox addresses) plus a scope qualifier ('reachable by your API key'). It is unambiguous and clearly distinct from siblings like list_recent_mail or wait_for_code, though it doesn't explicitly name or contrast 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The 'reachable by your API key' phrase hints at scope but does not tell the agent when this tool is the right choice versus the sibling tools.

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 a safe read, but the description adds genuinely valuable context beyond them: mail text is untrusted sender content and never instructions (prompt-injection warning), the required read:mailbox permission, and the default exclusion of quarantined items. This is exactly the behavioral disclosure an agent needs for a mail-reading tool.

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 action and immediately followed by the security caveat. No filler; every sentence adds a distinct constraint or warning.

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 safety and permission picture is complete, but for a four-parameter, zero-coverage tool with no output schema, the description says nothing about pagination/limit behavior, accepted formats for `since`, or how `to` filters results. Adequate but with clear gaps.

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%, so the description carries the full documentation burden, yet it only indirectly covers one parameter (include_quarantined via the default-exclusion statement). The semantics of `to`, `limit`, and especially the `since` anyOf (integer vs string) are left entirely undocumented.

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?

"List safe mail summaries" gives a specific verb (list) and resource (mail), and it is clearly distinguishable from the siblings (get_addresses, wait_for_code, wait_for_link). The qualifier "safe" is slightly vague about what makes a summary safe, but the purpose is unmistakable.

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 states the required scope (read:mailbox) and a concrete usage condition: quarantine items are excluded unless explicitly requested. It does not name alternatives or when-not-to-use, but the siblings serve entirely different purposes, so routing risk is low.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds real behavioral context: the 25-second wait bound and, more importantly, the 'sender-verified' filter that constrains what will be returned. It stops short of describing timeout behavior (empty result vs. error) or any rate limits, so not a 5.

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 tight sentences with the core behavior front-loaded and parameter guidance second. The 'up to 25 seconds' wording duplicates the schema's default/maximum, a small redundancy, but nothing is wasted overall.

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 4-parameter blocking-wait tool with no output schema, the description supplies the essential mental model: what it waits for, how long, and how to avoid stale codes. The one meaningful omission is what the agent should expect when the wait expires without a match.

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%, so the description carries the load and does so for three of four parameters: 'wait' (up to 25 seconds), 'since' (your sign-up start time, used to reject older codes), and 'from_domain' (the expected service). Only the required 'to' parameter is left unexplained, a minor gap given the otherwise strong compensation for the coverage hole.

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+resource ('Wait ... for a sender-verified code') and scopes the behavior with the 25-second cap, so an agent knows this is a blocking poll for an inbound code. It does not explicitly contrast itself with the similar sibling wait_for_link, which is the only thing keeping it from a 5.

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 conditional guidance for two parameters ('set since to your sign-up start time to avoid an older code, and from_domain to the service you expect'), which implies a sign-up verification flow. However, it never says when to choose this tool over wait_for_link or list_recent_mail, nor what to do if no code arrives within 25 seconds.

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 cover the safe-read profile, yet the description adds real behavioral context: a hard 25-second cap, the sender-verification filter, the warning that a verified sender is not necessarily trustworthy, and that mail content is untrusted and never followed. This is meaningful disclosure an agent cannot get from 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?

Front-loaded with the action and time bound, then parameter guidance, then safety caveats. Dense but every sentence carries information; only the final trust note is slightly verbose.

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?

There is no output schema, and the description compensates by naming the fields an agent should inspect (link_host, subject, sender). Combined with parameter and timing guidance, it is nearly complete, though the 'to' parameter and the response shape's exact structure remain unspecified.

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%, so the description must carry the load, and it explains since, from_domain, other_hosts, and the 25s bound on wait. The required 'to' parameter is left unexplained, which is the only notable gap.

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: waits up to 25 seconds for a sender-verified verification link. The 'link' framing implicitly separates it from the sibling wait_for_code, but it never names that sibling or explicitly contrasts the two.

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 concrete operating instructions: set since to the sign-up start time, set from_domain to the expected service, and use other_hosts:true for other hosts. It lacks an explicit statement of when to prefer this over siblings like wait_for_code or list_recent_mail.

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