AIsa Agent Mail

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

Adds substantial context beyond the readOnlyHint/openWorldHint/destructiveHint annotations: the call is free, it requires the Authorization header, and it discloses result semantics ('ok is true only when the balance was read; otherwise each entry of errors says what to do in next_step'). That tells an agent how to interpret partial failure, which annotations 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 sentences, front-loaded with what the agent gets, followed by cost/auth, then call triggers, then result interpretation. No sentence is redundant and none could be dropped 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?

For a zero-parameter read tool with an output schema already present, the description covers the remaining gaps: cost, auth requirement, invocation triggers, and the ok/errors/next_step contract. Nothing an agent needs to call or interpret 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, so the description has nothing parameter-level to compensate for, and the schema is fully covered. A 4 rather than 5 reflects that it adds no input-syntax detail, though none is possible 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?

The description states a concrete resource set (identity/key, account balance, Go-to-Market wallet, usage over 1/7/30 days) rather than restating the name. It is clearly distinguishable from every sibling, which are all Reddit, batch, or search tools. An agent knows exactly what it will learn by calling it.

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?

Explicit triggering conditions are given: 'Call it to verify a new connection or to explain a 402.' That is a strong when-to-use statement. It stops short of 5 because it names no alternative tool or a when-not condition, though the sibling list offers no obvious competing diagnostic.

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=true, idempotent=true, destructive=false, and openWorld=true, so the safety profile is covered. The description's one contribution beyond that is the per-request price ($0.012), which is real operational information. It says nothing about what the zone file contains or any retrieval caveats, but the annotation coverage lowers the bar.

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?

Very short and front-loaded, with the tool name first and the pricing note isolated in a marked block. The pricing markup consumes a disproportionate share of the text but is at least clearly delimited and not buried mid-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 single-parameter read tool with an output schema and full annotations, the definition is minimally sufficient — an agent can call it correctly with the domain ID. However, the description never clarifies the resource (DNS zone file) enough to distinguish intent from neighboring domain endpoints.

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% — domain_id is documented as 'The ID of the domain.' With only one fully documented parameter, the schema does the work and the baseline of 3 applies. The description adds no formatting or sourcing detail about the ID.

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 is essentially the title repeated: 'Get Zone File' with no expansion of what a zone file is, which domain resource it applies to, or how it differs from the sibling get_any_agentmail_apis_v1_agentmail_domains_domain_id. The only additional text is a pricing boilerplate block, not a purpose statement. This is tautological restatement rather than a description.

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 indication of when to call this tool, what prerequisites exist (e.g., domain must be verified), or how it relates to alternatives like the domain-get or domains-verify siblings. Nothing is misleading, but nothing guides usage either.

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 declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is already carried by structured data. The description adds nothing behavioral – it never says what gets mutated, whether the call is asynchronous, or whether it can be repeated – and only supplies a pricing note, which is metadata rather than behavioral context.

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 text is short and front-loaded with the title, but the only substantive content is inserted pricing boilerplate. Brevity here stems from under-specification rather than disciplined concision.

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 non-idempotent, destructive, open-world operation with no output schema, an agent needs to know what verification does and what state changes it triggers. The description omits all of this, leaving the definition materially incomplete despite the simple one-parameter schema.

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?

There is a single required parameter with 100% schema description coverage, so the schema already documents domain_id. Per the baseline rule, a 3 is appropriate; the description contributes no additional meaning about the parameter.

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 is just 'Verify Domain', which restates the tool name and title verbatim. It identifies a verb and resource but does not explain what verification entails (DNS record check, ownership confirmation, async job) or distinguish this from the sibling get/patch/delete domain 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?

There is no when-to-use guidance, no prerequisites (e.g., that DNS records must already be configured), and no mention of alternatives such as get_any_agentmail_apis_v1_agentmail_domains_domain_id for checking status instead.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is not required to restate it. It adds genuine operational context: the batch_use prohibition, exact-name/prefix requirements, and session reuse semantics. It does not cover failure handling when names are invalid, keeping it below 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?

Front-loaded with the core action and size limit, and every sentence carries workflow value. The session_id sentence duplicates the schema's own parameter description, which is minor redundancy rather than bloat.

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 batch retrieval tool with an output schema, the description supplies the orchestration context an agent needs (source of names, next steps, session handling) without needing to explain return values. Nothing essential to correct invocation 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 the baseline is 3. The description adds real meaning beyond the schema by constraining names to those returned by search and warning against a client prefix such as mcp__aisa__, which is not encoded in the 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 and resource ('Retrieve schemas for 1 to 20 exact tool names') and pins the source of those names to search. This clearly separates it from siblings like search (finds tools), batch_quote, and batch_use.

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?

Explicitly sequences the workflow: build arguments from successful schemas, then call batch_quote, and 'Do not call batch_use yet.' This is an explicit when-to-use and when-not-to-use instruction naming the alternative siblings.

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 past the readOnly/idempotent annotations by explaining that quotes are price observations rather than authorization grants, and precisely delimiting what auto_execute_eligible does and does not waive (user prohibition, narrower scope, tighter budget). It also guarantees no execution fallback, which is the key behavioral risk for this 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?

Purpose is front-loaded and most sentences carry distinct rules (no fallback, eligibility limits, naming, session reuse). It is on the long side and the argument-shape constraint is stated twice in spirit, but little is truly wasted.

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-value documentation isn't required, yet the description still flags the two response fields that matter for a downstream decision. Combined with session and naming guidance, an agent has everything needed to call it 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?

At 67% schema coverage the schema already documents each parameter, so the description earns credit only for added meaning: exact-name rules for 'tool', session_id reuse semantics, and the 1-to-20 argument-shape parallel with batch_use. It doesn't clarify search_id beyond what the schema states.

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 ('Obtain AIsaServices cost quotes for 1 to 20 published tools') plus the crucial scope qualifier 'without executing them.' It is immediately distinguishable from the sibling batch_use, which executes rather than quotes.

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?

Explicitly names the parallel sibling ('Same input as batch_use') and draws the boundary ('Never falls back to execution'). It also gives operational conditions: use names exactly as search returns them, strip any mcp__aisa__ prefix, and reuse session_id from Search for the task.

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 cover mutability, destructiveness, and open-world behavior. The description adds critical business logic: billable calls, quote dependency, the meaning of auto_execute_eligible (waives only cost confirmation, not user prohibitions), and no silent retry. It doesn't detail rate limits or return format, but with an output schema present, that's acceptable.

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 dense and front-loads the cost warning, but it packs many separate instructions into one block, making it less scannable. Some sentences like 'A missing or failed quote is not free' add value, but the overall flow could be better structured.

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 the destructive, open-world annotations and the presence of an output schema, the description covers the essential preconditions and behavioral constraints. It could mention error handling or partial failure behavior, but the core guidance is sufficient for correct invocation.

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%, and the description adds important semantics: tool names must be exact without client prefix, session_id reuse guidance, and 1-20 call limit. It doesn't explain search_id, but the schema description for search_id is already clear enough.

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 verb and resource: 'Execute 1 to 20 independent published-tool calls', and the title matches. It distinguishes itself from batch_quote by requiring a quote first, but doesn't explicitly contrast with the singular 'use' sibling, though that's implied by 'batch'.

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 when-to-use and when-not-to-use conditions: only after a successful batch_quote with auto_execute_eligible=true or explicit user authorization. It also states re-quote conditions and prohibits silent retries, leaving little ambiguity.

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, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — it does not say deletion is permanent, what is destroyed, or any auth/rate-limit detail, and instead describes return fields ('email, display name, client ID, timestamps') that read like a retrieve result rather than a destructive delete.

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 core content is two compact sentences with the operation front-loaded, which is efficient. The injected pricing block is required metadata rather than authored prose, so it does not meaningfully hurt structure.

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 destructive, non-idempotent delete tool with no output schema, the description should explain consequences and confirm what a delete affects. Instead it describes a retrieve-style return payload, leaving the agent without the information needed to call a destructive operation confidently.

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?

With a single parameter and 100% schema description coverage, the schema already documents inbox_id fully. The description only restates 'by its ID' and adds no format, validation, or lookup semantics, 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?

The description names a resource (inbox) and verbs, but it bundles three distinct operations — 'Retrieve, update, or delete' — while the tool name and the sibling set (get_agentmail_inbox, patch_agentmail_inbox, delete_agentmail_inbox) show these are separate tools. This makes the stated purpose actively misleading about what this specific tool does.

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 exclusions, and no routing to the obvious alternatives get_agentmail_inbox and patch_agentmail_inbox that appear as siblings. Usage is only vaguely implied by the operation list, which itself conflates the siblings.

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, readOnlyHint=false, idempotentHint=false and openWorldHint=true. The description only echoes that the draft can be 'removed entirely,' adding little; it says nothing about whether deletion is permanent, whether auth/permissions are needed, or side effects. The claim that the tool also retrieves and updates is misleading context for a delete endpoint, though it does not strictly contradict readOnlyHint=false.

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?

Reasonably short, but the second sentence largely restates the first ('get draft details, modify draft content... or remove the draft entirely'), adding no new information. The injected pricing block is boilerplate noise rather than authored 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 destructive mutation with no output schema, the description should clarify permanence, scope of destruction, and prerequisites. Instead it dilutes the tool's identity by describing three operations, leaving an agent uncertain what this endpoint actually does.

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 both required parameters (draft_id, inbox_id), so the schema already carries their meaning. The description adds no syntax, format, or source-of-ID detail beyond what the schema provides, making the baseline 3 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 names a specific resource (an email draft within an inbox, by ID) but describes three different operations — retrieve, update, delete — while the tool name is 'delete_agentmail_inbox_draft' and siblings get_agentmail_inbox_draft and patch_agentmail_inbox_draft each cover one of those verbs. This multi-verb framing blurs rather than sharpens the tool's actual scope for an agent choosing among siblings.

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 when-to-use guidance is given, and the description compounds the problem by claiming this delete tool also retrieves and updates drafts. With dedicated get_ and patch_ siblings present, the description provides no routing information and actively blurs the alternative-selection decision.

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 declare readOnlyHint=false and destructiveHint=true (a destructive write), while the description claims the tool only 'retrieves details' (a read). This is a direct contradiction of the safety profile, so the description actively misleads the agent about side effects.

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 single substantive sentence is front-loaded and reasonably tight, but the injected pricing block ('Published reference price: $0.012 USD...') consumes a large share of the text without helping the agent decide or invoke the tool.

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 four required parameters, no output schema, and a destructive annotation profile, the description should clarify the operation's effect and any return shape. Instead it describes a read, omits the deletion semantics implied by the name and annotations, and leaves the agent unable to call this safely.

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 all four parameters (type, entry, inbox_id, direction) documented and two enums enumerated. The description adds only a loose gloss ('email address or domain', 'based on direction and type') that the schema already conveys, 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 says 'Retrieve details of a specific list entry', which is a clear verb+resource, but the tool is named delete_agentmail_inbox_list_entry. An agent cannot tell whether this reads or deletes, and the sibling get_agentmail_inbox_list_entry already appears to cover retrieval, so the stated purpose is at best ambiguous and at worst misleading.

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 or when-not-to-use guidance, no mention of the near-identical sibling get_agentmail_inbox_list_entry or delete_agentmail_list_entry, and no indication of prerequisites. The agent is left to infer everything from the name/description conflict.

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 declare destructiveHint=true and readOnlyHint=false, but the description presents a harmless retrieval operation. It omits deletion side effects, irreversibility, required permissions, and any warning that the message may be removed.

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 main sentence is concise and front-loaded with the resource and returned fields. The embedded pricing boilerplate is irrelevant to invocation, but the description remains structurally efficient 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 destructive operation with no output schema and annotations indicating deletion, the description should carry critical context such as deletion warnings, irreversibility, and permissions. Instead it describes retrieval, leaving the agent without the information needed to call the tool safely or 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 description coverage is 100%, so inbox_id and message_id are fully documented in the input schema. The description adds return-content context but no additional parameter syntax or semantics beyond what the schema already provides.

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 says to retrieve message details, but the tool name is delete_agentmail_inbox_message and a sibling get_agentmail_inbox_message exists. This gives an agent the wrong operation verb, making the purpose misleading despite mentioning sender, recipients, content, labels, attachments, and timestamps.

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 when-to-use guidance, prerequisites, or alternatives are provided. It does not distinguish this tool from get_agentmail_inbox_message or explain when a message should be deleted versus retrieved.

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, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered by structured data. What the description adds is actively misleading: it advertises retrieval of 'messages, labels, senders, and timestamps', which reads as a read operation, and it never states that deletion is permanent, whether it cascades to contained messages, or what authorization is required.

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 core sentence is short and front-loaded, but it is padded with an unnecessary list of thread contents and prefixed by a verb set that does not match the tool name. The appended pricing block is injected boilerplate that consumes attention without aiding tool selection.

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 destructive, non-idempotent operation with no output schema, the description should state permanence, cascade behavior, and anything the caller gets back. Instead it describes thread contents as if the tool returned them, leaving the destructive semantics carried almost entirely by the annotations.

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% (inbox_id and thread_id are both documented in the schema), so the baseline is 3. The description adds no format, constraint, or sourcing detail about the two IDs beyond what the schema already provides.

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 concrete resource ('a specific email thread within an inbox') but opens with three verbs ('Retrieve, update, or delete') for a tool whose name is delete_agentmail_inbox_thread and whose title is the generic 'Manage Inbox Thread'. An agent cannot determine from the text whether this call destroys a thread or merely reads/updates it, and the multi-verb framing blurs it against the get_/patch_ siblings.

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 guidance on when to use this versus get_agentmail_inbox_thread, patch_agentmail_inbox_thread, or delete_agentmail_thread. The sibling list shows a full get/patch/delete family, and the description offers nothing to route between them. Usage must be inferred entirely from the tool name.

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, readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds no further behavioral context such as permanence, required permissions, or irreversibility, and its 'Retrieve' wording blurs the destructive profile already provided by 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?

The main purpose is front-loaded in a single sentence, with no unnecessary exposition. The included pricing HTML block is extraneous to tool selection and invocation, but it is brief.

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 schema fully covers the three required parameters and annotations carry the safety profile, so the basics are covered. However, for a destructive delete tool with close read/delete siblings, the description should clarify that it deletes rather than retrieves and when to choose it over get_agentmail_list_entry.

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 entry, direction, and type. The description mirrors these fields but adds no format, constraint, or example information beyond what the schema provides.

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 resource (email address or domain entry in a list) and the parameter dimensions direction and type, but the verb phrase 'Retrieve or delete' conflates two operations and does not distinguish this tool from the sibling get_agentmail_list_entry. Sibling selection is therefore ambiguous.

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 no guidance on when to use this tool versus alternatives such as get_agentmail_list_entry, and no prerequisites or when-not-to-use conditions are stated. The 'Retrieve or delete' wording could even misroute retrieval calls to this deletion-oriented 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, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description's only added value is the 'permanently or moving it to trash' distinction, but no schema parameter supports that choice, so it is misleading rather than informative, and the claim to 'retrieve' and 'update' conflicts with a tool the annotations mark as destructive-only.

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 operational sentence is compact and front-loaded, but a quarter of the text is injected pricing boilerplate that does not help an agent invoke the tool. Space is also spent enumerating three operations that the tool name contradicts.

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 destructive, non-idempotent, single-parameter tool with no output schema, the description should at minimum explain that deletion is irreversible and that no trash-mode parameter exists. Instead it advertises modes that cannot be selected and mixes in read/update semantics, leaving the agent with an inaccurate picture of the tool's actual surface.

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 thread_id parameter, so the schema carries the full burden; baseline 3 applies. The description adds no syntax or format detail for thread_id and instead describes behaviors (trash vs permanent) that have no corresponding parameter.

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 resource (email thread) and specific operations, but it conflates three distinct operations — retrieve, update, and delete — into a tool whose name and title (delete_agentmail_thread) promise only deletion. Sibling tools get_agentmail_thread and patch_agentmail_thread already exist for the other two verbs, so this bundling actively muddies tool selection rather than clarifying it.

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 guidance on when to choose this tool over get_agentmail_thread or patch_agentmail_thread, despite those siblings being present. The description also hints at a 'permanently or moving it to trash' choice, but offers no condition for picking either, leaving the agent to guess.

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, idempotentHint=false, readOnlyHint=false and openWorldHint=true, so the risk profile is covered without description help. The description contributes only the published per-request price ($0.012), a genuine behavioral fact not present in annotations, but says nothing about irreversibility, revoking effects on existing integrations, or confirmation requirements.

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 text is short and not padded with redundant prose, and the pricing note is clearly delimited. However, the only substantive content is the pricing boilerplate; relative to the tool's purpose the definition is under-specified rather than concise-and-complete.

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 destructive, non-idempotent delete with no output schema, an agent would benefit from knowing what happens on success (empty body? 204?), whether deletion cascades to related inboxes/domains, and whether the key is recoverable. None of this is present, so the definition is materially incomplete despite annotation coverage.

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?

There is a single parameter (api_key_id) with 100% schema description coverage, so the schema documents it fully. The description adds no meaning such as where to obtain the key ID or whether it accepts a key value versus an identifier, which is the baseline for high-coverage schemas.

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 body is literally the title 'Delete API Key' — a tautology that restates the tool name rather than describing behavior. It does convey a verb+resource (delete an API key), but adds no scope, target system detail, or differentiation from the many other delete_* siblings.

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, when-not-to-use, or alternative guidance at all. Nothing tells the agent how this differs from sibling deletes such as delete_any_agentmail_apis_v1_agentmail_domains_domain_id or delete_agentmail_inbox.

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, readOnlyHint=false, and idempotentHint=false, so the safety profile is partly conveyed. However, for a destructive irreversible operation the description gives no warning about permanence, what collateral data is removed, or any confirmation/auth requirements, and it emphasizes read-only fields instead.

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 core content is a single compact sentence, which is appropriately sized, but it wastes its slots enumerating operations the tool likely does not perform (retrieve/update) instead of front-loading the destructive action. The embedded pricing note is metadata, not descriptive text.

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 destructive tool with no output schema and no annotations covering irreversibility, the description should state consequences and any prerequisites. Instead it describes verification status, DNS records, and notification settings — fields associated with the retrieval siblings — leaving the actual delete behavior 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?

Only one parameter (domain_id) with 100% schema description coverage, so the schema fully documents it. The description adds no format, scope, or sourcing detail beyond the schema, which is the baseline expectation at full coverage.

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 name says delete, but the description claims the tool can "Retrieve, update, or delete" — conflating three distinct siblings (get_any_agentmail_apis_v1_agentmail_domains_domain_id, patch_..., and this delete). An agent cannot tell from the description what this specific tool actually does. The resource is clear but the verb is muddled.

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 guidance on when to use this versus the get/patch domain siblings, and no warning about the conditions under which a domain should be deleted. The reader is left to infer that deletion is the applicable path.

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, idempotentHint=false, readOnlyHint=false and openWorldHint=true, so the destructive/non-idempotent profile is covered. The description adds nothing behavioral beyond that – it does not say the key is permanently revoked, whether other resources are affected, or what auth is required; the only extra content is a cost notice.

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 text is short and front-loaded, which is good, but the second half is vendor pricing boilerplate that occupies space a usage or scoping hint could have filled. It is concise without being informative.

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 destructive, non-idempotent delete with two required identifiers and no output schema, the description leaves key questions unanswered: whether deletion is permanent, what happens to the inbox after the key is removed, and how this differs from the other API-key delete tool. Annotations cover the safety flag but not the operational semantics.

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 both required parameters (inbox_id, api_key_id) are documented in the schema, so the baseline of 3 applies. The description adds no additional meaning about how the two identifiers relate.

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 ("Delete API Key"), so the general action is recoverable, but it is essentially a restatement of the title with the "Inboxes" scope prefix stripped off. It does not distinguish this tool from the sibling delete_any_agentmail_apis_v1_agentmail_api_keys_a_3ff578 or explain the inbox-scoped API key model.

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, despite a large set of delete siblings that an agent must choose between. The pricing note is the only additional sentence and gives no usage direction.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds no operational context, only a price note; it says nothing about auth requirements, error behavior, or what the draft object contains.

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?

It is short, but the only non-title content is a pricing disclaimer that does not help an agent select or invoke the tool. This is under-specification rather than genuine conciseness; the text present does not earn 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?

An output schema exists, so return values need not be explained, but the description fails to establish scope (top-level vs inbox-scoped draft) among many near-identical siblings. For a getter in a crowded namespace, that is a real gap.

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?

There is one parameter and schema description coverage is 100%, so the schema already documents draft_id fully. The description adds 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?

The description is only the title restated ('Get Draft') plus a pricing footnote; it adds no specific verb, resource detail, or scope beyond the tool name. It does not distinguish this top-level 'get draft' from siblings such as get_agentmail_inbox_draft or get_agentmail_drafts. This is effectively a tautology.

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 when-to-use guidance, no conditions, and no reference to alternatives is given. With a large family of sibling getters (get_agentmail_inbox_draft, get_agentmail_drafts, get_agentmail_draft_attachment), the absence of routing guidance leaves the agent to guess.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only per-request cost information (useful but peripheral) and says nothing about response behavior, size limits, or auth scope beyond what annotations provide.

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?

It is short and front-loads the tool name, but the bulk of the body is pricing markup rather than functional content, and the pricing block arguably belongs in metadata rather than the description. There is no wasted prose, but also almost no substance.

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 explained, but for a tool surrounded by near-identical attachment getters the description provides no disambiguation of which attachment source it targets. Missing scope/routing detail leaves the agent unable to place it confidently among siblings.

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 draft_id and attachment_id are documented in the schema itself; per the rubric this yields a baseline of 3. The description contributes no additional parameter meaning (e.g., ID formats or where draft_id comes from).

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 is only the header 'Get Attachment' plus pricing boilerplate, which essentially restates the tool name/title. It does not specify what kind of attachment is fetched (draft vs message vs thread) or what the returned payload is, so an agent cannot distinguish it from the many sibling attachment getters.

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 such as get_agentmail_inbox_draft_attachment or get_agentmail_thread_attachment. The only added text is pricing, which does not help an agent decide when this tool applies.

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, and open-world, so the safety profile is covered elsewhere. The description adds nothing beyond a pricing note — no mention of pagination behavior, filtering scope, or what the listing returns, even though those behaviors matter for a paginated list endpoint.

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 just a duplicated title plus an HTML-commented pricing block, which is noise for an agent and not front-loaded useful information. It is short but wastes what little space it has.

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 six-parameter paginated list tool surrounded by many similar draft/sibling getters, the description should at least state scope (all drafts vs. inbox-scoped drafts) and that results are paginated. The output schema exists, but the description fails to disambiguate from siblings, leaving the agent under-informed for this complexity.

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 six parameters (after, before, limit, labels, ascending, page_token) are already documented in the schema. The description adds no parameter meaning beyond that, which meets the baseline of 3.

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 is simply 'List Drafts', which restates the title verbatim and provides no distinguishing detail from the closely related siblings get_agentmail_inbox_drafts, get_agentmail_draft, and get_agentmail_inbox_draft. The only added content is a pricing banner, which does not clarify the tool's 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 guidance on when to use this tool versus get_agentmail_inbox_drafts or the singular draft getters. An agent has no basis for choosing among the many list/get draft siblings.

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 explicitly says the tool can 'update, or delete' an inbox, but annotations declare readOnlyHint=true and destructiveHint=false, and dedicated patch_agentmail_inbox / delete_agentmail_inbox siblings exist. This is a direct contradiction of the safety profile and could lead an agent to expect mutation capabilities that do not exist.

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 core is two short sentences, but the first sentence carries the misleading update/delete claim and a block of pricing boilerplate is injected mid-description. Structure is acceptable but not clean.

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 needn't be explained, yet the description restates them and never clarifies the read-only nature of the operation. The contradiction with annotations leaves an agent with an incomplete and inaccurate picture of the tool's behavior.

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 inbox_id parameter, so the schema already documents it fully. The description's 'by its ID' phrasing adds no meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 core action is stated with a specific verb and resource (retrieve a specific inbox by its ID), which is discernible. However, the description claims it can also 'update, or delete' an inbox, which muddies the purpose and conflicts with the read-only nature of the tool. It also fails to differentiate from siblings like get_agentmail_inboxes or the duplicate get_any_agentmail_apis_v1_agentmail_inboxes_inbox_81bd1e.

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 guidance on when to use this tool versus alternatives. With siblings such as get_agentmail_inboxes (list) and the update/delete variants, an agent gets no routing signal. The only implied usage is the 'by its ID' phrasing.

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 claims the tool can 'modify draft content and recipients' and 'remove the draft entirely', while annotations declare readOnlyHint=true and destructiveHint=false. This is a direct contradiction of the safety profile an agent relies on.

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 resource and action, then a clarifying sentence; reasonably tight. The injected pricing boilerplate and the three-verb sprawl are minor waste but the core is efficient.

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 needn't be described, but the description still misrepresents the tool's mutability and offers no routing to the real update/delete siblings. For a seemingly simple retrieval tool, the definition leaves the agent with a wrong mental model.

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 draft_id and inbox_id are already documented in the schema. The description adds no syntax, format, or constraint detail beyond that, matching the baseline for schema-covered parameters.

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 resource (email draft in an inbox) and identifier (draft ID), which is clear enough against siblings like get_agentmail_draft. However, it bundles three operations (retrieve/update/delete) into one tool whose name and annotations indicate a read-only GET, so the stated purpose is partly inaccurate.

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 guidance on when to use this versus the many siblings that actually cover the claimed operations (patch_agentmail_inbox_draft, delete_agentmail_inbox_draft, get_agentmail_draft). Nothing indicates the read-only scope or prerequisites.

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, destructiveHint=false and openWorldHint, so the safety profile is covered structurally. The description adds nothing behavioral beyond a pricing note, which is not relevant to invoking the tool correctly.

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?

It is short but not substantive: the text is effectively a title repeat plus a pricing/HTML-comment block that does not help an agent select or call the tool. The signal-to-noise ratio is poor even at this length.

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 explained, and annotations cover safety. But for a heavily-populated sibling family of attachment getters, the description provides no differentiation, leaving the agent to infer scope from the name alone.

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 three IDs (attachment_id, draft_id, inbox_id) are documented in the schema. Baseline 3 applies; the description contributes no additional meaning about the parameters.

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 is just "Get Attachment," which restates the title "Inboxes - Get Attachment" without adding a verb-resource-scope statement an agent can use. It does not distinguish this tool from siblings like get_agentmail_draft_attachment or get_agentmail_inbox_message_attachment.

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 mention of alternatives, and no prerequisite/context statement. The only usable signal is the naming convention itself; the description offers nothing about when this attachment-getter applies versus the other attachment getters.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read profile is covered by structured data. The description adds only that filtering and pagination are supported; it says nothing about auth scope, result caps, or how pagination tokens behave. The appended pricing line is boilerplate billing metadata, not behavioral disclosure.

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 carrying the core information with no wasted phrasing. The trailing pricing comment block is extraneous to tool selection, though it appears to be injected metadata rather than authored description text.

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 full schema coverage handles parameter detail; annotations cover safety and idempotency. The remaining gap is only the absence of sibling-routing guidance, which is minor for a straightforward list endpoint.

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 every parameter (after, before, labels, limit, ascending, page_token, inbox_id) is already documented in the schema. The description generalizes about filters and pagination but adds no field-level meaning beyond it, matching the baseline-3 expectation.

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 ('Retrieve a list of email drafts') and scopes it to 'the specified inbox,' which matches the required inbox_id. It does not, however, explicitly distinguish itself from the sibling get_agentmail_drafts (the non-inbox-scoped list) or get_agentmail_inbox_draft (single draft), so the differentiation is left to the name.

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?

Mentioning 'optional filters and pagination support' implies the intended listing/filtering use case, but the description never says when to pick this over get_agentmail_drafts, get_agentmail_inbox_draft, or the thread/message list siblings, nor does it state any prerequisites.

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 advertises a create (write) capability while the annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. This directly contradicts the structured safety profile. Additionally, it discloses nothing about pagination behavior or rate limits beyond the boilerplate pricing note.

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 core is a single sentence, but it merges two unrelated operations into one clause, and the injected aisa-pricing HTML block adds non-selection-relevant clutter. The payload is not front-loaded around a single clear capability.

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?

Although an output schema exists (so return structure need not be described), the definition is incomplete: it leaves the create-vs-list ambiguity unresolved, omits create parameters the schema does not have, and contradicts its own annotations. For a tool surrounded by many near-named siblings, this is insufficient to call 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 100% and the three actual parameters (limit, ascending, page_token) are self-documented. The description instead names 'custom username, domain, and display name' as inputs, none of which exist in the schema, so it misleads rather than adds meaning about the real parameters.

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 leading clause states a clear verb+resource ('Retrieve a list of inboxes with pagination support'), which matches the tool name and the read-oriented siblings. However, it then appends 'or create a new inbox', conflating two distinct operations and blurring the tool's identity against siblings like get_agentmail_inbox (singular) and post_agentmail_inbox (the real create path). An agent cannot cleanly tell what this tool does from the description alone.

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 mentions pagination support but gives no conditions for choosing this tool over get_agentmail_inbox, get_agentmail_inbox_messages, or the dedicated create endpoints. There is no when-to-use, when-not-to-use, or alternative routing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The only added behavior is the pricing note ($0.012 per successful request), which is genuinely useful cost context but is gateway boilerplate rather than tool-specific behavior; nothing is said about pagination or result traversal despite page_token/limit parameters being present.

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?

Brevity here reflects under-specification rather than economy. The single meaningful line duplicates the title and the remaining content is an injected HTML-comment pricing block, so the space that should carry purpose and usage is spent on boilerplate.

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 and rich annotations relieve the description of explaining return values and safety, but for a four-parameter listing tool with dozens of near-identical siblings, the description supplies no notion of what an inbox event is or when this call is the right one. It is not sufficient for correct tool selection.

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 limit, inbox_id, ascending and page_token are all documented in the schema itself; the baseline of 3 applies. The description adds no parameter meaning beyond the 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 text is the tool title verbatim ('List Inbox Events'), which is a restatement of the name rather than an explanation of scope. It does not say what an 'event' is or how this differs from the many sibling readers (get_agentmail_inbox_messages, get_agentmail_inbox_threads, get_agentmail_inbox_drafts), so an agent cannot discriminate it from structured fields alone.

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 when-to-use guidance, no exclusions, no named alternatives, and no prerequisites are given. With over sixty sibling tools in this namespace, the absence of any routing signal is a serious gap rather than a minor omission.

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 claims the tool 'add[s]' and 'creat[es] new entries', which is a write operation, while annotations declare readOnlyHint=true and destructiveHint=false. This is a direct contradiction of the structured safety profile, so the description actively misleads the agent about the tool's mutating behavior.

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 front-loaded sentences with no redundant padding; the purpose leads and the capability detail follows. The only bloat is the injected pricing boilerplate, which is not part of the author's prose.

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?

Although an output schema exists and relieves the description of explaining returns, the definition is incomplete and misleading for a tool it presents as both a reader and a creator: it contradicts the read-only annotation and references a 'reason' concept with no corresponding parameter. An agent cannot reliably determine whether calling it mutates state.

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 type, limit, inbox_id, direction, and page_token; baseline is 3. The description adds only that pagination is supported, and its mention of 'optional reasons' does not map to any parameter in the schema, adding confusion rather than meaning.

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 verb and resource ('Retrieve or add entries to a specific inbox list') scoped by direction and type, but it conflates two distinct operations (read and write) in a tool whose name is 'get_...' while its title is 'List Or Create'. It does not distinguish this tool from siblings like get_agentmail_list_entries or post_agentmail_inbox_list_entry, leaving the agent unsure what the tool actually is.

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 or when-not-to-use guidance and no alternative sibling is named, despite the environment containing get_agentmail_inbox_list_entry, get_agentmail_list_entries, and post_agentmail_inbox_list_entry. The agent must infer usage entirely from the name and schema.

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 fully declare the read-only, idempotent, non-destructive, open-world profile, so the safety burden is off the description. The description adds only the qualifier that entries are email addresses or domains and that lookups are keyed on direction and type; it says nothing about failure modes (missing entry) or result shape.

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 functional sentence is single, front-loaded, and free of padding. The appended pricing boilerplate is injected infrastructure rather than authorial prose, so it does not undermine the concise core.

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 a rich schema (100% coverage), four enums-annotated required params, full annotations, and an output schema that documents return values, the one-sentence description is sufficient for an agent to call this correctly. Only the sibling-disambiguation for the plural list tool is left unstated.

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 all four parameters (type, entry, inbox_id, direction) are documented in the schema, including enum values. The description only loosely echoes 'direction and type' and 'email address or domain', adding no format or syntax 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?

Specific verb 'Retrieve details of' plus a specific resource 'a specific list entry ... within an inbox's list', and it clarifies the entry is an email address or domain filtered by direction and type. It distinguishes the singular lookup from the plural sibling get_agentmail_inbox_list_entries only implicitly ('a specific list entry'), so differentiation is present but not sharp.

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 implies usage (fetch one known entry, scoped to an inbox, identified by direction and type) but never says when to choose it over get_agentmail_inbox_list_entries, get_agentmail_list_entry, or the inbox-scoped variants. No exclusions or prerequisites are given.

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 fully carried by structured data. The description adds only the field inventory of the response, which is arguably redundant given an output schema exists, and says nothing about auth requirements, error cases (missing inbox/message), or rate limits. Adds some context but not much 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?

The core purpose is a single front-loaded sentence with no waste. However, the appended pricing boilerplate block is tool-agnostic metadata that does not earn a place in a description intended to drive invocation, diluting the structure.

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 read tool with full schema coverage, complete annotations, and an output schema, the description covers what an agent needs to call it correctly. Return-value detail is present but redundant since the output schema handles it; the only real gap is sibling disambiguation.

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 both parameters (inbox_id, message_id) are documented in the schema, so the baseline is 3. The description does not add any format, ID-source, or constraint detail beyond what the schema already states.

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 ("Retrieve detailed information") and a precise resource ("a specific message within an inbox"), and enumerates the returned fields (sender, recipients, content, labels, attachments, timestamps). It distinguishes adequately from the list sibling get_agentmail_inbox_messages by saying "a specific message," but never explicitly differentiates from get_agentmail_inbox_message_raw or get_agentmail_inbox_message_attachment.

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 and no alternatives named, even though the sibling set contains get_agentmail_inbox_message_raw, get_agentmail_inbox_message_attachment, and get_agentmail_inbox_thread. The purpose implies "fetch one message by ID," but nothing routes the agent among these near-identical retrieval 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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear without description help. The description does add the published request price, which annotations do not cover, but it says nothing about authentication, rate limits, or response behavior.

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 short and front-loads the only substantive phrase, "Get Attachment." However, it is under-specified for a tool with this many siblings, and the embedded pricing boilerplate is not central to invoking the tool correctly.

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 schema is fully documented, an output schema exists, and annotations cover the read-only/idempotent behavior. Still, the description itself does not clarify the inbox-message scope or distinguish this attachment getter from sibling attachment tools, leaving context to be inferred from the tool name.

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 three required parameters (inbox_id, message_id, attachment_id) are each described in the schema. The description adds no parameter meaning beyond what the schema already provides, 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 is essentially "Get Attachment," which restates the title "Inboxes - Get Attachment" rather than stating a distinct purpose. It does not differentiate this inbox-message attachment getter from sibling tools such as get_agentmail_draft_attachment, get_agentmail_inbox_draft_attachment, or get_agentmail_inbox_thread_attachment.

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 guidance is given about when to use this tool versus the many adjacent attachment and message retrieval tools. The only extra text is a pricing note, which does not help an agent choose between alternatives.

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, non-destructive, and openWorld, so the safety profile is covered. The description's only added behavioral fact is the $0.012 per-request price, which is real but thin and not enough to explain what 'raw' output entails (e.g., raw MIME vs parsed 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?

It is short and front-loaded, but the pricing comment block is boilerplate that occupies most of the body without helping the agent invoke the tool. Nothing is bloated, yet nothing earns its place either.

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, but the core ambiguity — how this differs from get_agentmail_inbox_message and what 'raw' means — is left entirely unresolved for a tool with many near-identical siblings.

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 both required parameters (inbox_id, message_id) are documented in the schema itself. The description adds no meaning 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?

The description is effectively the title restated: 'Get Raw Message' with no expansion of what 'raw' means or what resource is actually fetched. With dozens of sibling getters (get_agentmail_inbox_message, get_agentmail_inbox_message_attachment, etc.), the agent gets no basis for distinguishing this tool from the normal message getter.

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 mention of the alternative get_agentmail_inbox_message, and no note about when the raw representation is preferable. The only additional text is a pricing boilerplate block, which does not help selection.

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 by structured data. The description adds nothing behavioral about the tool itself — no pagination behavior, no default filtering (e.g., whether spam/trash are excluded by default), no result ordering — only a billing note.

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?

It is short, but shortness here reflects under-specification rather than efficiency. The embedded pricing HTML comment block is boilerplate noise that consumes most of the text without describing the tool.

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 14-parameter filtered list tool with rich pagination and include_* semantics, the description supplies none of the context an agent needs about defaults or scope, relying entirely on the schema and annotations. The existence of an output schema excuses omitting return values, but not omitting usage and default-filtering context.

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% across all 14 parameters, so the schema fully documents filters such as to/from/subject, date bounds, and the include_* flags. The description adds no additional meaning beyond the schema, which is the expected baseline of 3 when the schema does the heavy lifting.

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 Messages" merely restates the tool title ("Inboxes - List Messages") without stating scope, what an inbox message is, or how it differs from siblings like get_agentmail_inbox_threads or get_agentmail_inbox_message. It is a tautological restatement rather than a description of what the tool does.

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 condition for choosing this over thread- or message-level siblings, and no mention of prerequisites. The only additional sentence is a pricing disclaimer, which does not help an agent decide whether to invoke the 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 readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds only a per-request price note, which is useful cost context but does not explain metrics computation, event filtering, or rate limits.

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 extremely terse ('Query Metrics') and largely consumed by pricing boilerplate. For a 7-parameter inbox metrics endpoint, this is under-specification rather than appropriately concise, and nothing useful about the operation is front-loaded.

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 tool has 7 parameters, many AgentMail siblings, and an output schema. The description does not state the inbox-specific scope or distinguish it from global metrics, leaving sibling selection and operational intent unclear despite rich structured fields.

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 7 parameters are already documented in the input schema. The description adds no parameter meaning, which is the expected baseline when the schema carries the full burden.

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 is only 'Query Metrics', which restates the title and tool name rather than specifying what metrics are queried, for which inbox, or how it differs from sibling tools like get_agentmail_metrics. It is a tautology rather than a clear verb+resource description.

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 such as get_agentmail_metrics or get_agentmail_inbox_events. The agent receives no routing information.

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 claims 'update, or delete' while annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. This directly contradicts the declared safety profile and could lead an agent to believe it is invoking a mutating or destructive operation.

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 opens with the action and resource, followed by the injected pricing boilerplate. The prose itself is tight, though the misleading verb list is a content flaw rather than a length problem.

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 explained, and the schema fully covers inputs. The remaining gap is that the description fails to resolve the read-vs-write ambiguity created by its own wording against the annotations.

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 all four parameters (limit, inbox_id, thread_id, page_token) are documented in the schema. The description adds no extra meaning such as pagination semantics or thread_id format, 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?

Names a specific resource (a specific email thread within an inbox) and enumerates the data it surfaces (messages, labels, senders, timestamps). However, the verb set 'Retrieve, update, or delete' is over-broad and wrong for a tool whose name and annotations indicate a read, so the purpose is muddled rather than crisp.

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 when-to-use guidance and no routing to alternatives, despite many plausible siblings such as get_agentmail_thread, get_agentmail_inbox_threads, patch_agentmail_inbox_thread, and delete_agentmail_inbox_thread. The agent is left to infer when this tool beats a sibling.

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, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds only a pricing blurb; it says nothing about auth requirements, what the returned attachment payload looks like, or how errors are surfaced.

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 text is short and front-loaded with the operation name, but the sole substantive content is a pricing/marketing block that contributes nothing to correct invocation. It is concise but not informative.

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 explained, but for a tool sitting among ~60 siblings with three near-duplicate attachment getters, the description provides no scope differentiation, no prerequisite context, and no behavioral detail. It is under-specified for the ambiguity an agent faces.

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 three required IDs are documented in the schema itself. The description adds no syntax, format, or scoping nuance beyond that, which is the correct baseline-3 outcome when the schema does the work.

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 is literally just 'Get Attachment', which restates the title 'Inboxes - Get Attachment' without adding a verb+resource+scope. It does not distinguish this tool from near-identical siblings such as get_agentmail_thread_attachment, get_agentmail_inbox_message_attachment, or get_agentmail_draft_attachment.

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 indication of when to use this tool versus the many other attachment-fetching siblings, nor any prerequisite about needing an inbox_id/thread_id/attachment_id combination. Nothing misleading, but also no guidance whatsoever.

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 fully covered by structured data. The description adds only a pricing note, which is cost context rather than behavioral disclosure about filtering, pagination, or result scope.

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 text is short and the purpose line is front-loaded, but the only substantive content is an HTML-commented pricing boilerplate block, so the brevity reflects a lack of information rather than efficient editing.

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 and annotations cover safety, but for a 14-parameter listing tool the description offers no explanation of filtering semantics, spam/trash/blocked inclusion behavior, or how this differs from the global thread-listing sibling, leaving an agent without routing guidance.

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% across all 14 parameters, so the schema already documents each filter, sort, and pagination option thoroughly, establishing the baseline of 3. The description contributes nothing beyond the schema for any parameter.

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 is 'List Threads', which merely restates the title 'Inboxes - List Threads' with no additional detail. It does state a verb+resource, but it does not distinguish this inbox-scoped thread listing from siblings such as get_agentmail_threads or get_agentmail_inbox_messages, so it reads as a tautology rather than an explanation.

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 usage guidance whatsoever: no statement of when to prefer this inbox-scoped listing over get_agentmail_threads, no prerequisites, and no mention of the 14 filtering options available.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, yet the description advertises creating entries and adding email addresses/domains. That is a direct write-vs-read contradiction, and no permission, side-effect, or rate-limit context is offered to resolve it.

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 two substantive sentences are front-loaded and compact. The injected pricing block is extraneous to tool semantics but appears to be boilerplate rather than authored 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?

An output schema exists so return values need not be explained, but the description's central claim (creation support) is unsupported by the schema and contradicted by the annotations, leaving the agent unable to know what the tool actually does.

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 all four parameters (direction, type, limit, page_token) are documented there, so the baseline is 3. The description adds nothing to their semantics and instead references an 'optional reason' that does not exist in the schema, which muddies rather than clarifies.

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 name and the first clause point at retrieving list entries, but the description then claims it can 'create entries' and add addresses/domains, which the schema does not support and the annotations deny. The mixed verb signal makes it hard to tell whether this is the read-side counterpart of post_agentmail_list_entry or a merged read/write tool.

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 mentions pagination and an 'optional reason' for additions but never says when to use this tool versus the many siblings (get_agentmail_list_entry, post_agentmail_list_entry, delete_agentmail_list_entry). No exclusions, no prerequisites, no routing 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?

The description claims the tool can 'delete' an entry, while annotations declare readOnlyHint=true and destructiveHint=false, and a dedicated sibling delete_agentmail_list_entry exists for that purpose. This is a direct contradiction of the structured safety metadata on a security-relevant list-management tool. The pricing boilerplate adds no behavioral context.

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 core is a single front-loaded sentence, which is appropriately sized. But it wastes framing on a 'delete' capability the tool does not have, and the embedded pricing comment block occupies description space without helping selection or invocation.

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 explained. Still, for a tool with three required parameters and multiple near-identical siblings, the description omits any scoping or disambiguation and introduces a read/write ambiguity an agent must resolve some other way.

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 both enums documented inline, so the schema already carries the parameter burden. The description's phrase 'based on its direction and type' only restates what the schema already says and adds no format or constraint detail.

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 (retrieve a list entry by direction and type), which is enough to identify the operation. However, the added 'or delete' overstates the tool's scope and conflicts with the 'get_' prefix, muddling what the tool actually does. It also fails to distinguish this from close siblings such as get_agentmail_list_entries, get_agentmail_inbox_list_entry, and delete_agentmail_list_entry.

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 when-to-use guidance is given: nothing explains when to call this single-entry lookup versus the plural get_agentmail_list_entries, or the inbox-scoped get_agentmail_inbox_list_entry. No prerequisites or conditions are stated, so the agent must infer routing from the name alone.

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 by structured data. The description's only added behavioral fact is the per-request price ($0.012 USD), which is genuinely useful context annotations do not carry, but it says nothing about rate limits, aggregation behavior, or data freshness.

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 text is short and front-loaded with the heading, but most of its body is marketplace pricing boilerplate that does not help an agent select or invoke the tool. It is not bloated, but the useful-content-to-total-content ratio is poor.

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 explained, and annotations cover safety. However, for a tool with six optional query parameters and a confusingly similar sibling, the description provides no domain framing at all — no statement of what event metrics are, what time windows mean, or how this differs from get_agentmail_inbox_metrics.

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 six parameters (start, end, period, limit, descending, event_types) are already documented in the schema. The description adds no additional meaning beyond that baseline, so a 3 is the correct floor.

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 is literally the title repeated: 'Query Metrics.' It restates the name rather than explaining what is being measured (delivery events? inbox activity?) or what resource the metrics belong to. With a near-identical sibling, get_agentmail_inbox_metrics, an agent cannot distinguish the two from this text.

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, when-not-to-use, or alternative-tool guidance anywhere in the description. The existence of get_agentmail_inbox_metrics makes this omission actively harmful, since nothing tells the agent which metrics endpoint to pick.

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 asserts mutating and destructive behavior ('update', 'delete the thread permanently') while annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. This directly contradicts structured data an agent relies on, and the schema offers only thread_id/limit/page_token with no action or force/trash parameter to select a delete mode. Pricing note is the only additive context.

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 core is only two sentences and is front-loaded, which is good. However, the injected pricing boilerplate interrupts the definition, and the second sentence spends its space enumerating capabilities the parameters cannot actually invoke.

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 no exposition, but for a tool advertised as capable of permanent deletion the description omits permission requirements, reversibility, and which parameter selects each mode. Combined with the readOnly annotation conflict, an agent lacks what it needs to call this safely.

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 all three parameters (thread_id, limit, page_token) are documented in the schema, so the baseline is 3. The description adds nothing about pagination or list-size behavior, and notably never explains how a single thread_id call could trigger the update/delete paths it advertises.

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 claims three distinct operations ('Retrieve, update, or delete') for a tool named get_agentmail_thread whose title is 'Manage Email Thread'. That tri-verb claim collides with both the tool's own name and real siblings like patch_agentmail_thread and delete_agentmail_thread, so an agent cannot tell which tool performs which action. It effectively restates the vague title rather than pinning down a single 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?

No when-to-use guidance is given, and the closest siblings (get_agentmail_inbox_thread, get_agentmail_threads, patch_agentmail_thread, delete_agentmail_thread) are never named or contrasted. The mention of 'permanently or moving it to trash' hints at a deletion mode but never says when to prefer which, nor which tool owns those paths.

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 structurally. The description adds no behavioral context beyond that — nothing about what is returned (file bytes vs. metadata), auth/inbox scoping requirements, or rate limits — only a boilerplate price note.

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?

It is short and front-loads the tool name, but the remaining content is an HTML-comment pricing block that conveys no functional information. Brevity here reflects under-specification rather than well-earned conciseness.

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, but in a toolset crowded with near-identical attachment getters, the description provides no differentiation or scoping context. An agent cannot confidently choose this over get_agentmail_inbox_thread_attachment or get_agentmail_inbox_message_attachment.

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 both required parameters (thread_id and attachment_id), so the schema already documents the inputs. The description adds nothing on parameter meaning, but per the baseline for high coverage, 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 is essentially the title repeated ("Get Attachment"), a tautology over the tool name get_agentmail_thread_attachment. It does not say what kind of attachment is retrieved, from where, or how it differs from the many sibling attachment getters such as get_agentmail_inbox_message_attachment and get_agentmail_draft_attachment.

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 when-to-use guidance, no prerequisites, and no routing among the numerous sibling attachment/message/draft retrieval tools. The only additional sentence is a pricing disclaimer, which does not help an agent decide whether to call this 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description contributes no additional behavioral context — no pagination behavior, no default filter state, no scope/auth notes — only a generic per-request price that is not tool-specific.

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?

It is short, but the content does not earn its place: one line repeats the title and the other is an HTML-commented pricing block that aids neither selection nor invocation. There is no front-loaded scoping or filtering information to orient the agent.

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 13-parameter listing tool with many near-identical siblings, the description omits the one thing an agent cannot infer from the schema: which threads are listed (all inboxes? a scoped set?) and how this differs from get_agentmail_inbox_threads. The output schema does cover return values, so that gap is excused, but the scope ambiguity remains.

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% across all 13 parameters (each has a description covering date filters, substring-match semantics, repeatability, pagination token, and include_* flags), so the baseline of 3 applies. The description adds no parameter meaning of its own, neither compensating nor detracting.

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 body is literally 'List Threads', an exact restatement of the tool title, which the rubric classifies as tautology. It gives no verb+resource specificity beyond the name and does nothing to separate this tool from close siblings such as get_agentmail_inbox_threads, get_agentmail_inbox_thread, or get_agentmail_thread.

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 at all: no scope statement (all inboxes vs. a specific inbox), no mention of when to prefer this over get_agentmail_inbox_threads, and no exclusions. The only sentence present besides the title is a pricing boilerplate note, which does not help selection.

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 states a destructive write operation ("Delete API Key") while the annotations declare readOnlyHint=true and destructiveHint=false. This is a direct contradiction, so the description cannot be trusted to reflect actual behavior. No permanence warning, authorization requirements, or rate-limit context is provided either.

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 and very short, which is appropriate for a one-parameter tool. But the second block is generic pricing boilerplate that does not help an agent invoke the tool, so the content is minimal rather than efficiently earned.

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 no explanation. However, for a destructive delete with annotations that actively misrepresent the operation, the description should compensate with permanence/irreversibility and auth context; it offers none.

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 a single api_key_id parameter documented in the schema. The description adds no meaning about the parameter (format, source, or where to obtain the ID), so the baseline 3 applies when the schema carries the burden.

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?

"Delete API Key" gives a specific verb (delete) and resource (API key), which is clearer than the opaque tool name. However, it is a verbatim restatement of the title with zero added specificity, and it does not distinguish this from sibling deletes such as delete_any_agentmail_apis_v1_agentmail_api_keys_a_3ff578 or the other delete_* 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?

The description provides no when-to-use, when-not-to-use, prerequisites, or alternatives. The only extra text is a pricing boilerplate note, which gives no invocation guidance at all.

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?

Annotation contradiction. Annotations declare readOnlyHint=true, but the description claims the tool updates and deletes a domain. It cannot be both read-only and destructive. The description also does not disclose that the paid price applies per successful request beyond the embedded pricing block.

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 core sentence is reasonably tight and front-loaded with the verb and resource, but the embedded pricing HTML comment block is noise in a tool description and the multi-verb claim makes the sentence misleading rather than concise.

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-value detail is not required. But for a tool whose annotations and description disagree about whether it is read-only or destructive, the description leaves the agent unable to determine the actual safety profile, which is the most important thing to get right here.

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 one fully documented parameter (domain_id, 'The ID of the domain.'), so the baseline is 3. The description adds nothing beyond what the schema already states about the parameter.

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 generic verb 'Retrieve, update, or delete' with the resource 'domain', and names fields returned. However, the name implies a read (get_) while the description claims three operations, and the sibling list contains distinct dedicated tools (patch_any_agentmail_apis_v1_agentmail_domains_domain_id, delete_any_agentmail_apis_v1_agentmail_domains_domain_id). It doesn't clearly position itself against those siblings.

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 guidance on when to use this tool versus the dedicated patch and delete domain siblings, or versus verify. The 'update or delete' framing actively blurs the boundary with siblings that perform those operations specifically.

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 declare readOnlyHint=true and idempotentHint=true, but the description says it can 'create a new API key' — an obvious mutation. This is a direct contradiction: creation is not a read-only or idempotent operation. The annotation contradiction is a serious issue as it misrepresents the tool's behavior. The description also fails to disclose permission requirements or side effects of key creation.

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 core sentence is concise, but the inclusion of a pricing note unrelated to tool functionality and the mention of non-existent parameters dilute focus. Still, it is relatively front-loaded and not overly 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?

For a tool that both reads and creates API keys, the description is too thin. It omits authentication requirements, the nature of created keys (e.g., secret return), pagination behavior for listing, and the fact that creation is destructive/state-changing. With annotations contradicting the described behavior, an agent could easily misuse this 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 all three parameters (limit, inbox_id, page_token). The description mentions 'optional permissions and name' which are not actual parameters in the schema, adding confusion rather than clarity. Baseline 3 is correct since the schema carries the load, but the extra mention of non-existent parameters is a slight negative.

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 two operations (list and create) on a specific resource (API keys for an inbox), which conveys the general purpose. However, the name 'get_any_agentmail_apis_v1_agentmail_inboxes_inbox_81bd1e' misleadingly starts with 'get' while the tool also creates API keys, and the description does not clarify that this is a dual-purpose tool. The purpose is vaguer than a specific verb+resource, landing at a 3.

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 guidance on when to use this tool versus siblings like get_any_agentmail_apis_v1_agentmail_api_keys_api_key_id or post_get_agentmail_api_keys. No prerequisites, no alternatives, no context about when to list vs create.

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 establish that this is a safe, read-only, closed-world operation. The description adds useful context beyond annotations by saying it returns categories, servers, tool counts, and the dedicated endpoint, and that it is free. It omits auth/rate-limit details, but those are less critical given the read-only 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?

The description is front-loaded with what the tool returns and is generally efficient. The parenthetical about tool-router and the endpoint URL add some density, but each part contributes usage or content context.

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, read-only annotations, and an output schema available, the description supplies enough context for correct invocation. It explains the catalogue contents and gives the category-specific endpoint alternative, leaving no critical gap for an agent.

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 parameters, so parameter semantics are not a meaningful differentiator. The schema has no properties to explain, and the description does not need to document any inputs.

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 that this tool gives a catalogue overview: categories, servers per category, tool counts, and a dedicated endpoint. The resource is specific and recognizable, though sibling differentiation is only partial because it references 'tool-router' rather than the listed siblings like search/use.

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 alternative: use the category-specific endpoint if you only need one category, rather than going via search. It also notes the tool is free and AIsa-only, but it does not explicitly state when to call list_categories instead of search or use.

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, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds no real behavioral context: it doesn't say this is a partial update, that at least one of display_name/status/metadata must be supplied, or how metadata merges/clears. Its return-value sentence duplicates the output schema.

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 two operative sentences are front-loaded and short, but they are inaccurate, and the appended aisa-pricing block is boilerplate that adds no selection value. Structure is acceptable; content efficiency is not.

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 needn't be described, yet the description omits the critical update constraint (at least one updatable field required) and the boundary against the sibling get/delete tools. For a destructive, non-idempotent mutation on a nested schema, this leaves meaningful 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?

With only 50% schema description coverage and a nested body object, the description should compensate, but it says nothing about the body fields (status, metadata, display_name) or their merge semantics. 'By its ID' merely restates the required inbox_id already documented in the 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 claims the tool will 'Retrieve, update, or delete a specific inbox by its ID,' but the tool name (patch_agentmail_inbox) and the dedicated siblings get_agentmail_inbox and delete_agentmail_inbox show it only performs the update. The over-broad claim actively misroutes an agent looking to read or delete an inbox.

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 when-to-use guidance is given, and the description never points to get_agentmail_inbox or delete_agentmail_inbox for the read/delete cases it erroneously claims. The only implicit guidance is the mention of an inbox ID, which the schema already requires.

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=false, destructiveHint=true, and idempotentHint=false, so the safety profile is covered externally. The description adds only "remove the draft entirely," which is consistent with destructiveHint but redundant with it, and it omits mutation context such as partial-update behavior and the fact that draft kind is fixed. No contradiction, but little value added beyond 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?

The opening sentence is well front-loaded, but the second sentence largely restates it ("get draft details, modify draft content and recipients, or remove the draft entirely"). The injected pricing boilerplate is noise but is system-generated. Net effect is a short but partly redundant description.

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 explained, and the input schema fully documents parameters. What is missing is the piece the structured data cannot provide: how this PATCH endpoint relates to the dedicated get/delete draft siblings it appears to overlap with, leaving the agent's tool selection 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%, so the schema already documents draft_id, inbox_id, and every field inside the nested UpdateDraftRequest, including the omit-vs-null clearing semantics. The description mentions "draft content and recipients" at a high level but adds no format or edge-case detail beyond the schema. 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 resource is stated precisely ("a specific email draft within an inbox by its ID"), which an agent can map to the two required IDs. However, the verb is muddled: it claims to "Retrieve, update, or delete" a draft, even though dedicated siblings get_agentmail_inbox_draft and delete_agentmail_inbox_draft exist and the tool is named PATCH. The multi-verb framing blurs rather than sharpens the tool's identity.

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 guidance on when to choose this over the sibling readers/deleters it claims to duplicate (get_agentmail_inbox_draft, delete_agentmail_inbox_draft). An agent reading only the description would reasonably call this for a read or a delete, which is the wrong routing. No prerequisites or preconditions are given.

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 claims a pure retrieval, while annotations declare readOnlyHint=false and destructiveHint=true and the schema exposes add_labels/remove_labels mutations. This directly contradicts both structured sources and hides the destructive label-modification behavior an agent must know about.

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 plus a pricing block; it is short and front-loaded, but the content is factually wrong for the tool, so the brevity is not earned. The pricing boilerplate is incidental noise.

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 destructive patch operation with an output schema and a nested body object, the description fails to explain the mutation, the label add/remove semantics, or any prerequisites. It is actively incomplete and misdirecting.

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 word 'labels' in the description refers to returned fields, not the input body parameters add_labels/remove_labels, so it adds no meaning about the 3 inputs. With only 67% schema coverage, the body object's add/remove label semantics go unexplained in both places.

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 says the tool will 'Retrieve detailed information about a specific message,' which is a read operation, but the tool name is patch_agentmail_inbox_message and the schema requires a body with add_labels/remove_labels. This describes the wrong operation entirely and collides with the sibling get_agentmail_inbox_message.

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 when-to-use guidance is given, and the implied guidance is misleading: an agent reading this would invoke it as a read, when the actual read tool is the sibling get_agentmail_inbox_message. No alternatives or conditions are mentioned.

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, readOnlyHint=false, idempotentHint=false, so the safety profile is partly covered. The description adds nothing beyond the verb list: it does not say a delete path removes the thread permanently, does not mention that label changes are non-idempotent in ordering (remove beats add), and does not state any auth requirement. The "retrieve" claim also sits awkwardly against a non-read-only annotation.

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 with no padding; the only extra text is an auto-injected pricing block that is not author content. It is tight, though the three-verb enumeration is imprecise rather than economical.

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 no explanation, but for a destructive, non-idempotent mutation tool with a nested body object the description leaves the scope of mutation, the identity of sibling alternatives, and any safety preconditions unaddressed. An agent could not confidently choose this over patch_agentmail_thread or get_agentmail_inbox_thread.

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 67%, and the schema already explains add_labels/remove_labels and the remove-over-add precedence. The description's mention of "labels" loosely maps to the body params but adds no format, constraint, or system-label caveat. With the schema doing most of the work, 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 claims the tool will "Retrieve, update, or delete" a thread, but sibling tools get_agentmail_inbox_thread and delete_agentmail_inbox_thread already own the retrieve and delete paths for the same resource. Advertising three CRUD verbs on a PATCH endpoint actively blurs which tool does what, so an agent cannot reliably distinguish it from its siblings on the description alone.

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 statement at all, despite the sibling list containing direct competitors (get_agentmail_inbox_thread, patch_agentmail_thread, delete_agentmail_inbox_thread). The phrase "within an inbox" hints at inbox-scoped versus top-level variant, but the agent must infer that; no exclusions or alternatives are named.

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, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description's added behavioral claims — retrieval and permanent/trash deletion — are not achievable through this schema, so the extra context is inaccurate rather than additive. No PATCH/partial-update semantics are 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 tool-specific portion is short and front-loaded, with no wasted sentences about the actual update behavior. However, the embedded 'aisa-pricing' boilerplate adds noise irrelevant to tool selection, and the brevity comes at the cost of accuracy rather than precision.

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 explained. But for a mutation tool with annotations carrying only the safety profile, the description should clarify idempotency, label-only scope, and non-reversibility; instead it describes capabilities the schema cannot perform, leaving the agent with an incorrect model of the 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 coverage is 50%, and the nested update body's add_labels/remove_labels constraints (no system labels, remove priority) are documented only in the schema. The description's generic 'modifying labels' neither clarifies that the body is the sole mutation channel nor warns that no other thread field can be patched, and it implies parameters that do not exist.

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 claims three incompatible operations — 'Retrieve, update, or delete an email thread by its ID' — while the schema only accepts a thread_id and an update body containing add_labels/remove_labels, i.e. label modification only. Retrieval and deletion are already covered by sibling tools get_agentmail_thread and delete_agentmail_thread, so the stated purpose actively misroutes the agent rather than distinguishing this tool.

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 when-to-use guidance and no alternatives are named, despite a dense sibling set (get_agentmail_thread, delete_agentmail_thread, patch_agentmail_inbox_thread). Worse, the 'fetching thread details' and 'deleting the thread' claims point the agent at the wrong tools for those operations. This is misleading rather than merely absent.

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, readOnlyHint=false, idempotentHint=false and openWorldHint=true, covering the safety profile. The description adds no behavioral context about revocation, permission requirements, or irreversibility — its only non-title content is a published price ($0.012 per request), which is a small but genuine addition.

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?

It is short and front-loads the operation name, with no filler sentences. The injected aisa-pricing comment block is wrapper boilerplate, but it does carry cost information, so it is not pure waste.

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 mutation tool with a nested permissions object (the richest part of the schema), the description conveys none of what the call actually does and mislabels it as a deletion. An output schema exists so return values need no explanation, but the basic semantics an agent needs before invoking it are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.