Cherami

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

Annotations already declare the safety profile (not read-only, idempotent, non-destructive). The description adds a genuinely useful behavioral trait beyond them: all-or-nothing semantics when any message is missing. However it omits whether add/remove labels are merged or replaced and how conflicting labels are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no waste; the scope limit leads and the atomicity caveat follows immediately. Everything earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and annotations cover safety. But for a 3-param mutation with 0% schema coverage, the description leaves add/remove semantics and sibling-tool selection unaddressed.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden, yet it never distinguishes add_labels from remove_labels or explains that message_ids is required and uuid-formatted. 'The same label changes' is vague about the add/remove mechanics.

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 (apply label changes to received messages) and adds a concrete scope bound (up to 100). The word 'received' implicitly distinguishes it from bulk_update_sent_message_labels, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'bulk' framing and the 100-message cap imply this is for multi-message operations, but there is no explicit guidance on when to choose this over update_message_labels (single) or bulk_update_sent_message_labels. Usage is inferable but not stated.

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

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

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=true, closed world), so the bar is lower. The description adds genuinely new behavioral context: the 100-message cap and the all-or-nothing atomicity ('If any message is not found, nothing changes'), which an agent could not infer from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler; the scope and the atomicity caveat are both front-loaded and each earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be described, and atomicity is covered. However, for a mutation tool with three parameters the description omits what add_labels/remove_labels do and provides no routing to the single-message or general-message 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 0% at the property level, so the description should compensate, but it never mentions add_labels or remove_labels at all. It only echoes the 100-item cap on message_ids, leaving two of three parameters unexplained in both schema and description.

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 (apply label changes), resource (sent messages), and batching scope (up to 100). The 'sent' qualifier distinguishes it from the sibling bulk_update_message_labels, and the batch wording distinguishes it from the single-message update_sent_message_labels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use or when-not-to-use guidance, and never mentions the alternatives (single-message update_sent_message_labels or the non-sent bulk_update_message_labels). The 100-message cap is a hard limit, not a routing rule.

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=false, so safety and repeatability are covered. The description adds only filter-parity with list_messages and says nothing about count accuracy, caps, or whether large mailbox counts are truncated or estimated.

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 tight sentence with the counting purpose front-loaded and no filler. Nothing is wasted and nothing needs reordering.

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 and 90% parameter coverage, the description needn't explain return values or filter syntax, and the one sentence covers purpose and filter scope adequately. It falls just short of complete because it omits any note on count exactness or upper bounds for a tool whose whole output is a single number.

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 90%, so the 10 filter parameters (from, subject, query, labels_*, date bounds) are already well documented in the schema itself. The description's only added semantic is that these filters behave identically to list_messages, which is a modest cross-reference and not parameter-level detail. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (count) and resource (received messages) and immediately distinguishes itself from the sibling list_messages by framing this as the counting counterpart. An agent can tell what it returns without opening the schema or comparing sibling 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?

Referencing 'the same search and filters as list_messages' implies the pairing (use list_messages to fetch, count_messages to tally), but the description never explicitly says when to prefer counting over listing, nor rules out any scenario. Usage is inferable rather than stated.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the mutation and safety profile is already carried by structured data. The description adds one genuinely useful behavioral fact beyond that: the result is persisted but not transmitted. It says nothing about quota, permissions, or that the draft belongs to the inbox_id given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, purpose front-loaded ahead of the optional capability clause. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, for a 12-parameter creation tool with nested recipient and attachment objects, the description leaves the source/in_reply_to/recipient-assembly story and the idempotency contract entirely to the 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?

With 12 parameters and 58% schema description coverage, the schema carries most of the semantics; several parameters (subject, to/cc/bcc structure, inbox_id) are undocumented in both places. The description hints at the source path ('prepare a reply, reply-all or forward from an existing message') but never explains the source-versus-in_reply_to choice or the idempotency_key retry behavior, so it does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Save an email without sending it.' The clause 'without sending it' cleanly separates it from send_draft and send_message, and 'Can prepare a reply, reply-all or forward from an existing message' pins down the creation-mode variants. It never names update_draft, so the boundary with the tool that modifies an existing draft is left implicit.

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?

'To continue or review later' gives a use case, and the reply/forward clause implies the source-plus-message_id path, so usage is implied rather than stated. There is no explicit 'when not to use' and no sibling named (e.g., use update_draft to change an existing draft, or reply_message to reply and send in one step).

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 and destructiveHint=false, so the write/non-destructive profile is known. The description adds that the address must be authorized, but omits permanence, idempotency behavior (though in schema), uniqueness constraints, and what happens on conflict — a gap for a creation 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?

A single tight sentence that front-loads the verb, resource, and domain. Every clause (authorization requirement) earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% param coverage, the description needn't explain return values. However, for a creation tool with no exclusive behavior from annotations beyond safety, the absent permanence, conflict, and uniqueness context leaves an agent needing more than the one-liner supplies.

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 fully documents local_part, name, sender_name, and idempotency_key with formats and constraints. The description adds no parameter-level detail beyond what the schema provides, which is the correct baseline 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?

States a specific verb (create) and resource (inbox) with the domain address @cherami.to. Siblings include create_draft, delete_inbox, update_inbox, so the create action is distinguishable, but the description doesn't differentiate from those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage through the authorization caveat ('at an address the human or the assignment authorizes'), but gives no explicit when-to-use vs create_draft or other siblings, and no exclusions or 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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds real context beyond that: deletion is permanent, human confirmation is required, and a previously sent email derived from the draft survives. That scope-of-destruction detail is genuinely useful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action, with zero padding. Every clause carries 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?

An output schema exists, so return values need not be explained. Combined with annotations covering the safety profile, the description supplies the two non-obvious behavioral facts an agent needs (permanence and the surviving sent email). Only the identification of the draft_id source is unaddressed.

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 1 parameter at 0% schema description coverage, and the description provides no information about draft_id (format, where to obtain it, or validity). The name and UUID format are self-evident from the schema, but the description does nothing to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delete) and resource (draft) with the modifier 'permanently', so the agent can tell it apart from delete_message, delete_thread, and delete_sent_message by resource. It does not explicitly name a sibling to contrast with, but the resource naming makes the target unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is one clear prerequisite: confirm with the human before deleting. However, it gives no guidance on when to prefer this over related delete tools or what to do if the draft does not exist. Usage is implied rather than spelled out.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds context annotations cannot carry: the mail bypasses Trash entirely, the deletion is permanent, and the address is retired so it cannot be recreated. This tells the agent the blast radius is broader than a single message and that the operation is irreversible — exactly what a destructive tool needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the destructive action, followed by the two highest-value caveats (no Trash, address retired). Nothing is padded and nothing important is buried.

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 one-parameter mutation tool with an output schema, the description covers everything the agent needs: irreversibility, scope, non-recoverability, and a human-confirmation prerequisite. Return values are handled by the output schema and correctly omitted 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?

The single inbox_id parameter has 0% description coverage, but the schema self-documents via format: uuid plus a strict UUID regex, so syntax meaning is not really missing. The description's reference to "the exact address" describes a human confirmation step rather than the inbox_id argument itself and does not clarify that the identifier is a UUID, so it adds only marginal semantic value.

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 ("permanently delete an inbox") and immediately differentiates scope from the sibling delete_message / delete_thread / delete_draft tools by adding "and all its mail." An agent can tell what this destroys without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit precondition — confirm the exact address and full scope with the human — which is unusually strong guidance for a destructive tool. It does not, however, name an alternative (e.g., update_inbox or restore_message) or state a when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description adds real substance: this is a soft delete into Trash, reversible via restore_message for seven days, after which deletion is permanent. That lifecycle and the recovery window are exactly the behavioral facts an agent needs and cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The human-confirmation precondition and the Trash/recovery behavior are both front-loaded where an agent will see them before acting.

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, and the description covers the remaining essentials for a one-parameter destructive tool: the confirmation prerequisite, the reversibility window, and the permanence deadline.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden, and it says only 'the exact message' without naming message_id, its UUID format, or how to obtain it. The parameter is largely self-evident for a delete tool and the schema supplies the uuid format, so this is adequate but not compensating for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delete) and a precisely scoped resource (a received email), which distinguishes it from the many sibling delete tools (delete_draft, delete_sent_message, delete_thread, delete_inbox). An agent can pick this tool without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition — confirm the exact message with the human before deleting — and points to restore_message as the recovery path. It does not state when-not to use it (e.g., bulk cleanup vs delete_thread), but the routing context is clear.

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

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

Annotations only declare destructiveHint/idempotentHint; the description goes further by disclosing that the delete is a soft delete (moves to Trash), that it is reversible via restore_sent_message, and that the retention window is seven days before permanent deletion. That recovery model is exactly the context an agent cannot get from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the action and the human-confirmation gate, then the reversibility consequence. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive tool with an output schema already covering returns, the description supplies the missing lifecycle and recovery context. Nothing an agent needs to call it correctly is absent.

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?

One parameter at 0% schema description coverage, so the description carries some burden. 'Confirming the exact message' implies message_id identifies the target, but it adds no format, UUID, or lookup guidance beyond what the schema's type/pattern already encode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Delete) and a precisely scoped resource (a sent email's saved copy), which cleanly separates it from the sibling delete_message and delete_draft. The scope word 'sent' plus the Trash semantic makes the target unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear precondition ('after confirming the exact message with the human') and names the recovery alternative restore_sent_message with its seven-day window. It does not explicitly say when to reach for delete_message vs this tool, so it stops short of full alternative routing.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: what is affected (received and sent messages), the recovery path (moved to Trash, restorable individually within seven days), and the terminal state (permanent deletion afterward). This tells the agent both the blast radius and the reversibility window.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The action and the human-confirmation requirement are front-loaded, with the recovery/irreversibility detail following. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive tool with destructive annotations and an output schema (which handles return values), the description covers scope, precondition, and lifetime of the deletion. Nothing an agent needs to invoke it correctly is missing.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single thread_id parameter, so the description carries the burden. It only implicitly maps 'conversation' to the thread_id and adds no detail on format or how to obtain the value, while the schema itself supplies type, uuid format, pattern, and required status. Baseline-level compensation, not more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delete) and resource (every message in a conversation), and explicitly scopes it to 'received and sent', which distinguishes it from the sibling tools delete_message and delete_sent_message. An agent can identify the operation and its breadth without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear precondition for use: confirm the conversation and its full scope with the human first, which is meaningful guidance for a destructive bulk operation. It does not, however, name alternatives (e.g. delete_message for a single message, restore_message for undo) or state when not to use it, so it falls short of the explicit routing a 5 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 destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: original bodies, quoted history and files are forwarded as stored and should be checked for disclosure, and the note is placed before the original content. It omits retry/idempotency behavior, but that is documented on idempotency_key in the 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?

Three short sentences, front-loaded with the action, then the key disclosure caveat, then the thread behavior. No filler and every sentence carries distinct 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?

An output schema exists, so return values need not be explained. For a destructive open-world send tool it covers the essentials - what content goes out, the authorization constraint, and new-thread behavior - with only labeling and idempotency left to the 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?

Schema coverage is 56%, so the description must compensate and only partly does: it explains the optional note and implies attachments are carried as stored (relevant to include_attachments). It says nothing about to/cc/bcc, labels, or inbox_id/message_id semantics, leaving those to 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+resource ('Forward a message') and adds a genuine differentiator from the reply siblings ('Starts a new conversation'). It doesn't name reply_message/reply_all_message directly, but the new-thread distinction already lets an agent separate this from those 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?

'recipients the assignment authorizes' implies a prerequisite (authorization scope) and 'Starts a new conversation' implies when it should be chosen over a reply, but neither is stated as an explicit when-to-use rule and no alternative tool is named. Usage is inferable rather than spelled out.

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=false, so the safety profile is fully covered without the description. The description adds the content dimension (what permissions and capacity are reported), which is useful but modest; it says nothing about freshness, scope (account-wide vs. workspace), or failure 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?

A single sentence, front-loaded with the verb and the three data points it returns. Nothing is padded or redundant.

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 the safety profile for this parameterless read. What remains missing is sibling differentiation against the policy/quota getters, which is the main thing an agent still has to infer.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies. Schema coverage is 100% and there is nothing parameter-wise for the description to compensate for.

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 ('Check') and enumerates the exact resources returned: sending permissions, deletion permissions, and remaining inbox capacity. However, it does not distinguish itself from siblings that overlap in scope, notably get_sending_policy, get_outbound_quota, and get_receiving_policy, which an agent could easily confuse with 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, when-not-to-use, or alternative tool is mentioned. With several siblings covering policy/quota concepts (get_sending_policy, get_outbound_quota, get_receiving_policy), the absence of routing guidance is a real gap.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond them by noting the read includes file bytes, hinting at potentially heavy payloads. It stops short of pagination, size limits, or error 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?

A single front-loaded sentence with no filler; the resource is stated first and its contents enumerated immediately after. Efficient and easy to scan.

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-resource read with an output schema and full annotation coverage, the description covers the essentials. The only gap is the absence of any usage routing against the many sibling read/list tools.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameter meaning, and it only implies selection by a single draft via 'a draft's'. The lone draft_id parameter is trivially named and format-constrained in the schema, so little is actually lost, but no syntax or constraint detail is added.

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 verb ('Read') and resource ('draft') and goes on to enumerate the returned contents (recipients, bodies, reply target, attachments, file bytes), so the agent knows exactly what a draft fetch yields. It is clearly distinguished from list_drafts by the singular, by-ID framing, though it never names a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the singular 'a draft's' signals retrieval by ID rather than listing. There is no statement of when to prefer this over list_drafts or get_message, and no prerequisites or exclusions 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, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds the returned field set, but that overlaps with the existing output schema and says nothing about missing-inbox errors or permissions.

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 filler, proportionate to a simple one-parameter read tool. It is efficient, though minimal.

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 getter with an output schema, the annotation and output schema carry much of the burden, so the description is close to complete. It still omits the meaning/source of inbox_id and any error behavior, leaving a modest 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?

One parameter with 0% schema description coverage, and the description never mentions inbox_id, its UUID format, or where to obtain a valid id. The schema supplies type/pattern but no prose, so the description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Read) and resource (an inbox) plus the exact fields returned, so it is distinguishable from create_inbox/update_inbox/delete_inbox. It stops short of naming the sibling it complements (list_inboxes) for multi-inbox retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the single required inbox_id makes clear this fetches one inbox, as opposed to the list_inboxes sibling. There is no explicit when-to-use statement or routing to an alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral detail beyond that — nothing about the readable/full format choice, attachment handling, or permissions — so it is only minimum-viable on this dimension.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight clauses with the main action front-loaded and the routing hint second. No filler, though it is terse enough that it withholds information an agent would find useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and annotations cover the safety profile. For a two-parameter read tool the description is nearly sufficient, missing only a note on the format trade-off and cross-references to raw/attachment readers.

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%: the format enum is richly documented inside the schema itself, while message_id carries no description. The description contributes zero parameter meaning — it never mentions format, readable-vs-full, or message_id — so it does not compensate for the uncovered half.

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+resource ("Read a received email") and explicitly separates itself from the sibling get_thread. "Received" implicitly distinguishes it from get_sent_message/read_raw_message, though those siblings are never named, so it falls just short of the top tier.

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 names the alternative (get_thread) and the condition that selects it ("for its conversation"), which is exactly the routing an agent needs. It gives no when-not-to-use guidance relative to read_raw_message or read_attachment, so it is clear context rather than full exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the accounting rule that governs the returned allowance — one unit per To/Cc/Bcc recipient, held for 24 hours — which an agent cannot infer from the 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?

Two short sentences with no waste. The core purpose is front-loaded and the quota rule follows as supporting detail.

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 the description adequately covers what the tool reports and how the allowance is consumed. The only gap is routing guidance against get_sending_policy.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; the description correctly adds no parameter discussion, and there is nothing further to document.

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 ('Check') and resource ('sending allowance'), with the scope clarified as shared across all the account's inboxes. It does not, however, differentiate itself from the sibling get_sending_policy, which an agent could reasonably confuse with a quota check.

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 quota mechanics ('each To, Cc and Bcc recipient uses one unit for 24 hours') imply the tool is for pre-send capacity checks, but there is no explicit when-to-use statement and no mention of get_sending_policy as the alternative for policy questions.

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 closed-world behavior. The description adds meaningful context beyond them: what the returned data represents (blocked senders/domains whose mail never arrives) and that mutation is a human-only action in a specific UI location. It does not describe return shape or pagination, but the output schema covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the tool's output and followed by the permission constraint. Every clause carries information; no filler or restatement of the title.

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 the safety profile. The description supplies purpose, data meaning, and mutation constraints, leaving only minor gaps like result volume or ordering.

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 0%, so the schema only supplies a UUID pattern for inbox_id with no prose. The description's phrase 'from this inbox' implies the parameter scopes the policy to a single inbox but adds no format, sourcing, or lookup detail. With only one self-evident parameter, this is minimally adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('senders and domains blocked from this inbox') and clarifies the consequence ('mail from them does not arrive'), which disambiguates it from the parallel get_sending_policy sibling by name alone. It never explicitly contrasts itself with get_sending_policy, so it stops short of the top score.

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 sentence 'Only the human can change them, in Account > Receiving rules' usefully tells the agent this is read-only and that no update tool exists for it, implicitly steering away from write attempts. It does not name an alternative tool or state when to prefer this over get_sending_policy, so guidance is implied rather than explicit.

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 read-only, idempotent, non-destructive. The description adds real context beyond them: the rules are human-controlled and cannot be modified via the API, and circumventing them via another inbox is forbidden. It doesn't describe what the policy response contains, but with an output schema present that is 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?

Two tight sentences, front-loaded with the action and its timing, then the constraint. No wasted words.

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 one-param read tool with an output schema and full annotations, this covers what an agent needs: when to call it and the hard constraint on bypassing rules. Slightly short on what the returned policy means, but the output schema carries that.

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?

One required parameter (inbox_id) with 0% schema description coverage; the description implies the policy is scoped to a specific inbox but gives no format or lookup guidance. Baseline 3 for a single-param tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check which recipients this inbox may send to') and ties it to the send workflow. It is clearly distinct from the sibling get_receiving_policy and from the send_* 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?

Explicitly says when to use it ('before preparing a send') and adds a when-not/alternative constraint: only the human can change rules, and the agent must not route through another inbox to bypass them. That routing prohibition is genuine, non-obvious 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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds only the phrase 'and its sending status', which is a thin restatement of the title rather than meaningful behavioral context (no note on format-dependent output size or attachment handling).

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 wasted words. It is efficient, though the brevity edges toward under-specification for a tool with two distinct output modes.

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, and annotations cover the safety profile. The remaining gaps are usage context and any hint about the format parameter's effect, leaving the definition minimally viable for a simple read tool.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: the format enum is richly documented in the schema while message_id (a UUID) is self-evident. The description says nothing about either parameter and does not mention that the format choice radically changes the returned content, but the schema largely carries this load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb (Read) and resource (sent email), plus the extra payload of 'sending status', which distinguishes it from a generic read. It does not explicitly contrast itself with the sibling get_message or read_raw_message, so an agent must infer the sent-vs-received scope.

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 tool is named. With siblings like get_message, get_thread, list_sent, and read_raw_message in the set, the description gives the agent nothing to route on.

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=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only the 'not a prerequisite' note, which is mildly useful but not rich 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?

Two short sentences, zero filler, with the primary trigger front-loaded before the clarifying exclusion.

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 no parameters, rich annotations, and an output schema carrying the return content, the description covers what an agent needs to decide to call it. It could note what the explanation contains, but nothing essential 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 there is nothing for the description to clarify and the schema is inherently complete. Baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb ('Explain') and resource ('Cherami') and clarifies the scope is informational about the service itself. It is distinguishable from the mail-operation siblings, though it never says what content the explanation covers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('when asked about the service') plus an exclusion ('Not a prerequisite for mail tasks'), which usefully tells the agent not to call it before mail work. No alternative tool is named for related questions, but none is obviously needed.

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 carry readOnlyHint, idempotentHint and destructiveHint=false, so the description is not required to restate safety. It instead adds a real behavioral trait beyond the structured fields: the page ordering (newest first, chronological within the page) and that next_cursor walks toward older messages.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, purpose front-loaded before the pagination detail. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the safety profile is covered by annotations. Purpose plus pagination direction is enough for a read tool, though the absence of any hint about what a message entry contains vs. read_raw_message is a minor 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?

Schema coverage is 50%: cursor and format are richly described in the schema (including the attachment caveat), while thread_id and limit carry no description there or in the description. The description mentions next_cursor but only repeats the pagination semantics already stated in the cursor schema field, so it adds little parameter 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?

Specific verb + resource: read a conversation's received and sent messages, which separates it from get_message (single message), list_threads (thread index) and list_messages. It stops short of naming any sibling as the alternative, so the differentiation must be inferred from the sibling names.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by the purpose statement; there is no explicit when-to-use, no exclusion (e.g. drafts or attachments are not mentioned) and no routing to get_message, read_raw_message or read_attachment. An agent can infer the context but gets no comparative 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description's one contribution beyond structured data is the sort order (most recently created first), which the schema does not state; it says nothing about pagination limits or the return 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?

A single front-loaded sentence with no filler and no repetition of the title. It is efficient, though arguably too terse for a tool whose filter semantics carry real behavioral weight.

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 carry the safety profile. However, for a 4-parameter paginated listing tool with only half the parameters documented, the description leaves the limit parameter and pagination workflow entirely unexplained.

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 only 50%, and the description adds nothing about limit, state, or cursor semantics. 'An inbox's drafts' loosely implies inbox_id filtering, but the undocumented limit parameter receives no explanation in either place, so the description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (list) and resource (an inbox's drafts) plus an ordering guarantee. It is distinguishable from singular siblings like get_draft and from list_messages/list_sent, though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives no when-to-use context: no mention of the state filter for choosing between editable and submitted drafts, no note about paginating via cursor, and no routing to related tools such as get_draft or list_trash. The agent must infer usage entirely from the 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered by structured data. The description adds modest value by disclosing that the result includes IDs, addresses, and remaining inbox slots, but says nothing about pagination, limits, or scope beyond the account.

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 filler. Every clause (IDs, addresses, remaining slots) conveys distinct 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 full annotations and an output schema, the description covers enough to call it correctly. The only gap is the missing routing hint against get_inbox, which is a usage rather than completeness concern.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to clarify; schema coverage is 100% and the baseline for a parameterless tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Find the account's inbox IDs and addresses') plus a secondary output detail ('remaining inbox slots'). It is distinguishable from create_inbox/delete_inbox/update_inbox by the listing verb, but it never disambiguates from the close sibling get_inbox, which fetches a single 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 or when-not-to-use guidance is given, and the most relevant alternative (get_inbox for a single inbox) is not named. An agent must infer that this tool enumerates all inboxes while get_inbox retrieves one.

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 closed-world, covering the safety profile. The description adds useful behavioral detail — results are alphabetically ordered and include message counts — but says nothing about pagination behavior or result size limits, so it is a modest supplement rather than rich 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?

A single front-loaded sentence with no filler; the scope, ordering, and payload are all packed in efficiently.

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 spelled out, and the description still notes the shape of the result (labels with counts). It omits any hint about pagination semantics, but for a simple paged list tool the sentence covers what an agent minimally needs.

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 50%: cursor and prefix are documented in the schema, while limit and inbox_id are not. The description covers the inbox scoping that inbox_id represents but says nothing about the limit cap or the case-sensitive prefix filter, so it does not compensate for the uncovered half of 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?

States a specific verb (find/list), a specific resource (labels), and the scope (used in an inbox), plus ordering and returned data (alphabetical, with message counts). It is clearly distinguishable from the sibling label tools, which are all update/bulk-update operations rather than lists.

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 statement of when to use this tool, when to prefer an alternative, or any prerequisite (e.g. needing inbox_id first). Usage is only implied by the sentence describing the resource, so an agent gets no routing guidance beyond the obvious.

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, closed-world behavior. The description adds the meaningful semantic that 'all supplied filters must match' (conjunctive filtering), which is behavior the annotations do not express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short clauses, no filler, with the core purpose and the conjunctive-filter rule front-loaded before the pointer to the sibling 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?

An output schema exists, so return-value narration is unnecessary, and the 14 parameters are 86% documented in-schema. The description is adequate but adds little for a tool this richly parameterized; a note on pagination/defaults is left entirely to the 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?

Schema description coverage is 86%, so the schema already documents filter formats, limits, ordering defaults, and cursor usage. The description adds no parameter-level detail beyond what the structured fields provide; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (search/list) and resource (inbox's received mail), and the scope constraint 'received' immediately separates it from list_sent, list_drafts, and list_trash. An agent can pick this over siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use get_message to read one message' explicitly routes the agent to the alternative for a single-message read. It stops short of saying when list_messages beats count_messages or list_threads, so it is clear but not exhaustive.

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 closed-world, so the safety profile is free. The description adds only the AND semantics of filter combination, which the schema also spells out per-parameter; it says nothing about default ordering, result caps, or pagination behavior beyond what the cursor field documents.

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 zero filler and the filter-matching rule immediately visible. It is terse to the point of omitting orientation hints, but nothing is 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?

With an output schema present, a rich cursor parameter, 85% description coverage, and annotations covering the safety profile, the definition is nearly self-sufficient. The only gap is routing guidance versus the many sibling list/get tools, which the description does not supply.

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 85% and each of the 13 parameters carries its own format/constraint text (e.g. 'relevance requires query', cursor continuation rules). The description contributes no parameter-level meaning 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?

States a specific verb pair (search/list) and resource (an inbox's sent mail) with the inbox scope made explicit. The word 'sent' implicitly separates it from list_messages, but no sibling is named and the differentiation is left to inference.

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?

'All supplied filters must match' gives a working contract for combining filters, but there is no guidance on when to pick this over list_messages, get_sent_message, or count_messages, and no when-not conditions. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real value by specifying AND semantics across filters and that matching happens at the message level, but says nothing about pagination behavior or how results are ordered/capped beyond what the schema already documents.

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 filler; the qualifying condition is stated immediately and nothing is repeated from the title or schema.

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 tool the description is thin, relying on the schema and an existing output schema for return values. It omits when-to-use context and behavior for the no-filter case, leaving real gaps even though the structured fields carry most of the load.

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 85%, so the schema already explains nearly every parameter (from, query, cursor, labels_*, order, etc.). The description only reinforces the AND-of-all-filters rule and adds no per-parameter syntax or format detail beyond that.

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 ('Find an inbox's conversations') and adds the key semantic that a conversation qualifies if at least one of its messages matches all filters. This distinguishes it from list_messages (which returns messages) and count_messages, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus get_thread, list_messages, or count_messages, and no statement about behavior when filters are omitted. Usage is only implied by the filter-matching sentence.

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 closed-world, so the safety profile is covered. The description still adds real behavioral context beyond them: results are ordered most-recently-deleted-first, only restorable mail is returned, and a deleted conversation is flattened into individual messages.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the scope and default ordering front-loaded followed by the one non-obvious output-shape caveat.

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 description covers ordering and conversation flattening. Remaining gaps are the undocumented limit/inbox_id semantics, which the description could have shored up.

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 only 33% (only cursor is documented); limit and inbox_id carry no schema descriptions, and the tool description mentions none of the three parameters, so it does not compensate for the gap. Nothing is added about page sizing or the inbox_id requirement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) plus a precisely scoped resource (an inbox's deleted emails that can still be restored), and adds ordering. The word 'deleted' implicitly separates it from list_messages/list_threads, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer this is the view for trashed-but-recoverable mail, which pairs with restore_message. There is no explicit when-to-use, when-not-to-use, or named alternative versus list_messages.

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 closed-world, so the safety bar is low. The description still adds real value: it discloses that content arrives as base64 chunks needing decoding, and warns that the attachment's contents are data, not instructions — an important prompt-injection guard for untrusted email content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste. The core operation is front-loaded and the decode/injection caveat follows immediately.

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 prose. The description covers the chunked-base64 return shape and the safety caveat, leaving only pagination nuance (next_offset termination) to the schema, which handles it adequately.

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 75% and the schema already documents offset, max_bytes and attachment_id with useful detail (defaults, chunk continuation). The description adds no format or constraint detail beyond what the schema provides, so it sits at the baseline for well-documented 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 verb (read) and resource (a received email's attachment) plus the output format (base64 chunks). The 'received email' scoping quietly separates it from sent-message siblings, but it never names an alternative such as read_raw_message, so differentiation is only implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'Read a received email's attachment' and it advises decoding bytes for downstream file tools, which is helpful. However, it gives no explicit when-to-use guidance versus read_raw_message or get_message, and no prerequisites or exclusions.

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 closed-world, so the safety profile is covered. The description adds the non-obvious behavioral detail that content is returned as base64 chunks (implying pagination/encoding), but says nothing about how chunks continue or what happens at the end — that lives only in the schema's offset description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the verb and resource, with the output format at the end. Nothing is redundant and nothing is padding.

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, and the chunking/offset mechanics are fully specified in the schema. The only shortfall is that the description doesn't warn that this returns unparsed raw source (large, base64, needs decoding) versus the parsed siblings, which an agent choosing between them would benefit from.

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%: offset and max_bytes carry their own descriptions (including the next_offset continuation rule and the 65536 default), while message_id is only typed as a UUID. The description adds no parameter meaning at all, so it neither compensates for the gap nor extends the documented fields — baseline 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?

States a specific verb ('Read'), a specific resource ('a received email's original MIME source'), and the output encoding ('base64 chunks'), which implicitly separates it from get_message (parsed content) and read_attachment. It never names a sibling explicitly, so the differentiation is left to inference rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent must infer this is for when the raw RFC822 source is needed rather than parsed headers/body from get_message. No when-to-use, when-not-to-use, or explicit alternative is given, though the 'original MIME source' phrasing makes the niche fairly evident.

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 destructive and non-idempotent behavior, so the bar is lower. The description adds important behavioral context not in annotations: original Bcc recipients are never included, and recipients are derived from sender-written headers rather than freely chosen.

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 tightly written sentences with the main behavior front-loaded. Every clause earns its place by clarifying recipient scope, derivation, or the alternative 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?

Given the annotations, rich schema, and output schema, the description is largely complete for this mutation tool. It covers recipient derivation and the send_message alternative, though the phrase 'check them against the assignment' introduces minor ambiguity about an external 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 high at 86%, so the baseline is 3. The description adds some recipient-derivation meaning around message_id and inbox_id, but it does not supplement the remaining parameters such as labels, attachments, or idempotency_key.

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: replying to everyone visible on a message, with the inbox excluded and Bcc recipients explicitly omitted. The scope is precise enough that an agent can distinguish it from a simple reply.

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 alternative for manual recipient selection: use send_message with in_reply_to. It also frames the default behavior as deriving recipients from sender-written headers, so the when-to-use condition is clear.

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

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

Annotations already declare destructive=true and idempotent=false, so the safety profile is covered. The description adds genuine non-obvious context: that recipients are taken from sender-written headers and should be verified before sending, which is a spoofing-relevant warning not present in the 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?

Two sentences with no waste, front-loaded with the core action and then the derivation caveat and the alternative routing. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists so return values need no explanation, and annotations cover the safety profile. The description covers the recipient-derivation nuance and the alternative tool; the only gap is that it never mentions the idempotency guarantee, leaving that entirely to the 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?

Schema description coverage is 86%, so the schema already documents every parameter in detail (inbox_id, message_id, text, labels, attachments, idempotency_key). The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Reply to a message') plus the key distinguishing behavior: recipients and subject are derived from the source rather than supplied by the caller. It routes away from send_message but does not explicitly distinguish itself from the sibling reply_all_message, which an agent would need to choose correctly.

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 alternative (send_message with in_reply_to) for the case where the caller wants to pick recipients, and warns to check derived recipients against the assignment. It lacks explicit when-not guidance versus reply_all_message, so it falls short of a 5.

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=false, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuine behavioral detail beyond that: restoration puts the message back into conversation and search results and preserves its labels, which tells the agent about side effects not visible in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that states the action, the source, the destination, and preserved state with zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering safety/idempotency and an output schema present, the description is nearly complete for a one-parameter tool. Minor gaps remain: it does not say what happens if the message is no longer in Trash or whether restoring an already-inbox message is a no-op.

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 message_id is fully documented (format, pattern, and provenance from list_trash), so the schema carries the parameter burden. The description adds no parameter-level detail, which is the expected baseline of 3 when the schema is complete.

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 (restore) + resource (received email) + source and destination (from Trash to inbox), and 'received' explicitly distinguishes it from the sibling restore_sent_message. An agent can pick this apart from its siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'from Trash' implies the precondition that the message must currently be in Trash, but there is no explicit when-to-use guidance, no statement of when not to use it, and no named alternative such as restore_sent_message for the sent-mail case.

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 idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the restore repopulates sent mail, the conversation, search results, and preserves labels, which tells the agent what state is reconstructed.

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 with no filler; the action and its effects are packed efficiently with nothing redundant.

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 the safety profile. The description covers what is restored and where; only edge cases (e.g., failure if the message is not in Trash, permission requirements) remain 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 coverage is 100% and the single parameter already documents its UUID format and that the value comes from list_trash. The description adds no parameter-level detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (restore) and resource (a sent email's copy) plus the source (Trash) and destination (sent mail, conversation, search results). This clearly separates it from the generic sibling restore_message by scoping it to sent-mail entries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'from Trash' implies the usage condition (the message must already be in Trash), but the description never explicitly states when to use this versus restore_message, nor does it mention prerequisites or exclusions.

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 the mutation/safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true), so the bar is lower, yet the description adds meaningful behavioral context: a returned status (accepted/rejected/unknown) freezes the draft and rejection requires saving a new draft. This 'freeze' semantics is real value beyond the annotations, though it doesn't explain what freezing entails operationally or auth details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste, front-loaded with the action and its authorization gate. The retry/freeze rule follows immediately, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values needn't be explained, and annotations cover the safety profile. The description complements these by explaining the freeze/retry lifecycle consequence of a send, making it largely complete; minor gaps are the lack of an explicit sibling comparison and edge-case behavior for 'unknown' status.

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 (idempotent-retry semantics) and idempotency_key are already fully documented in the schema. The description adds no parameter-level meaning beyond this, 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 states a specific verb+resource ('send a saved draft'), which is clear and distinct from create_draft/update_draft siblings. However, it does not explicitly differentiate itself from send_message, the most likely alternative for outbound sending, leaving the agent to infer the distinction from the name 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?

It gives a clear precondition ('when the human or the assignment authorizes it') and specific retry guidance ('to try again after a rejection, save a new draft'). This is actionable context, but it never names an alternative tool (e.g., send_message) or states an explicit when-not condition beyond the authorization gate.

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, openWorldHint=true, and idempotentHint=false, so the safety profile is largely covered. The description adds the reply-mode behavior, but it never warns that sending is irreversible or quota-consuming, nor does it reconcile the schema's idempotency_key parameter with the idempotentHint=false 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?

It is a single compact sentence with no filler, and the two operating modes are front-loaded. The phrasing ('recipients the assignment authorizes') is dense and slightly awkward, costing it the top mark.

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 carry the safety profile. For an 11-parameter tool the description covers the core two-mode behavior adequately, though it is silent on attachments, html/text alternatives, and quota implications.

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 82%, so the schema already documents to/cc/bcc, attachments, labels, and idempotency_key in detail. The description's only parameter-level contribution is the in_reply_to semantics, which the schema already states; nothing new is added beyond that baseline.

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 (send) and resource (email) and distinguishes two modes: a fresh send to author-authorized recipients, and a reply when in_reply_to is supplied. It does not, however, differentiate itself from closely related siblings such as reply_message, reply_all_message, or send_draft.

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 one real routing rule — supply in_reply_to to send a reply rather than a new message — which is useful conditional guidance. It says nothing about when to prefer this tool over reply_message, reply_all_message, forward_message, or send_draft, all of which are siblings that overlap heavily.

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 idempotentHint=false, and the description notably adds no behavioral context about permanence, delivery guarantees, rate limits, or why it is destructive. It does add one useful behavioral fact: the request carries the human's verified email and replies are directed there, which is not derivable from annotations. With annotations already covering the safety profile, this partial addition earns a middling score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the action and its scope, then the delivery detail. No filler. Slightly more could be said about the feedback-vs-mail distinction, but nothing here is 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?

Output schema exists, so return values need no explanation, and annotations carry the safety profile. The remaining gap is routing clarity: nothing tells the agent how this differs from send_message for the same recipient, which matters given ~40 adjacent email tools.

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% – both 'body' and 'title' are documented in the schema, including the explicit warning to omit credentials and unrelated private mail. The description adds no parameter syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('send') and resource ('Cherami') and enumerates the feedback types covered (problem report, suggestion, allowance request). It's distinguishable from the email siblings (send_message, send_draft) as an out-of-band feedback channel, though the description never explicitly says 'feedback' is separate from normal mail flow.

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?

Implied usage: send a problem report/suggestion/allowance request. But no guidance on when to prefer this over send_message, what counts as feedback vs. regular mail, or any preconditions (though the 'verified email' note hints at identity requirements). Nothing names an alternative or an exclusion.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the mutation nature is already known. The description goes beyond that by disclosing patch semantics — supplied fields replace saved values, recipient and attachment lists are replaced wholesale, omitted fields are preserved — which is exactly the behavior an agent needs and cannot get from the annotations. It does not address concurrency/conflict or invalid-ID handling, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste: purpose is front-loaded, then the replacement/preservation semantics follow. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. Combined with the patch-semantics sentence, an agent has enough to call it correctly; only auth requirements and failure behavior are unaddressed.

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 50%, so the description must carry weight, and it does: it explains that to/cc/bcc/attachments replace as a whole and that omitted fields stay unchanged, which is the single most consequential parameter behavior for this tool. This meaningfully compensates for the coverage gap, though it adds nothing about the remaining partially documented fields.

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 ('Edit an unsent draft'), and the 'unsent' qualifier usefully distinguishes it from sent-message siblings such as update_sent_message_labels and from send_draft. It is clear without needing the schema, though it does not name any sibling explicitly the way the top-tier examples do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent can infer this applies when modifying an already-saved, unsent draft. There is no explicit when-to-use vs. when-not, no named alternative (e.g. create_draft for new drafts, send_draft to send), and no stated 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 cover the safety profile (readOnly=false, destructive=false, idempotent=true), so the bar is lower; the description still adds real value by declaring the immutable field constraint ('address cannot be changed'). It does not mention permission requirements or whether the rename is reflected on previously sent mail, so it falls short of 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, with the actionable scope stated first and the constraint second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the annotations plus schema cover the mutation semantics. The remaining gap is absence of usage/authorization context for a write operation, which keeps it just below complete.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and the two optional parameters' descriptions already carry the omit-to-keep / null-clears semantics and length limits. The description only restates which fields are updatable ('internal name', 'outgoing sender name'), adding little beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Change) and resource scope (an inbox's internal name or outgoing sender name), and adds the boundary that the address cannot be changed. No sibling performs inbox renaming, so an agent can route to this tool confidently.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the mutation verb and the 'address cannot be changed' exclusion, but there is no explicit guidance on when to use this versus get_inbox, create_inbox or delete_inbox, and no prerequisites (e.g. permissions on the inbox) are stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and repeatability profile is covered. The description adds only that the operation is additive and subtractive in one call, and says nothing about behavior for unknown labels, partial failures, or limits, so it is adequate but thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with no filler and the key operation front-loaded. It is efficient, though its brevity comes at the cost of omitted detail rather than being a model of well-packed information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and annotations cover the mutation safety profile. Still missing is any routing versus the closely named sibling tools and any statement of failure semantics, which leaves the definition minimally viable for a mutating 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 0% at the property level, so the description carries the burden for three parameters. 'Add or remove labels' loosely maps to add_labels/remove_labels but conveys nothing about the required message_id, the 32-item cap, or the case-sensitive/128-byte label constraints.

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 pair ('Add or remove') and resource ('labels') scoped to a 'received message', which distinguishes it from update_sent_message_labels and update_thread_labels. It does not, however, distinguish itself from bulk_update_message_labels or explain the single-vs-bulk boundary.

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 update_sent_message_labels, update_thread_labels, or bulk_update_message_labels, nor any stated prerequisites (e.g. label must already exist). The agent must infer usage entirely from the 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 readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, which tells the agent this is a safe, repeatable local mutation. The description adds only the fact that both addition and removal are supported in one call. It says nothing about what happens when a label is unknown, whether add and remove may overlap, or any auth requirement — acceptable given annotations, but thin.

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 states the operation with zero filler. Nothing is repeated from the title beyond what is needed for clarity.

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, and annotations cover the safety profile. What is missing is the routing information an agent actually needs in a 40-tool namespace: differentiation from update_message_labels and the bulk variant, and edge-case behavior for unknown or duplicate labels.

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?

Top-level schema description coverage is 0%, but property names (add_labels / remove_labels / message_id) are self-explanatory and the array item schemas carry the label constraints (128 bytes, no control chars, max 32). The description confirms the add-or-remove semantics that map to the two array parameters, but adds no extra syntax or format detail. Baseline 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?

Specific verb pair (add/remove), resource (labels) and scope (sent message) are all present, so an agent knows exactly what mutation is performed. It does not, however, explicitly disambiguate itself from the close sibling update_message_labels or from bulk_update_sent_message_labels; only the name and the word 'sent' carry that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the operation but gives no when-to-use guidance: no indication of when to prefer update_sent_message_labels over update_message_labels, over bulk_update_sent_message_labels, or of any prerequisite (sent message must exist, labels must already exist). Usage is only inferable from the 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 the safety profile (not read-only, not destructive, not idempotent, closed-world). The description adds important behavioral context beyond annotations: labels apply to every message currently in the conversation, both received and sent, and future messages are excluded. It does not cover permissions or return behavior, but the annotations and output schema reduce the burden.

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 tightly written sentences with no waste. The core behavior is front-loaded, and the temporal caveat follows immediately without unnecessary detail.

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 annotations and the presence of an output schema, the description covers the key non-obvious behavior: scope to current messages and exclusion of future messages. It could say more about permissions or repeated-call behavior, but for an agent selecting and invoking the tool, the essential context is present.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the top-level parameters, so the description must compensate. It only implies that add_labels and remove_labels are used to add or remove labels and that thread_id identifies a conversation; it adds no label format, array limits, case-sensitivity, or add/remove edge-case semantics beyond what the parameter names already suggest.

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 action: adding or removing labels on every message currently in a conversation, received and sent. This scoping clearly distinguishes it from message-level and sent-message-level label tools, which update individual messages rather than an entire conversation's existing messages.

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 the tool is for applying labels across all current messages in a thread and warns that later messages will not receive them. However, it does not explicitly name alternatives such as update_message_labels or update_sent_message_labels, nor does it state when-not to use this tool.

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