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

No annotations are present, so the description carries the full burden. It usefully discloses that this is an OAuth-based connection and that it is stdio-only, implying a local interactive flow. However, it does not disclose side effects such as storing credentials, modifying the account list, or waiting for user interaction, nor does it mention reversibility.

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

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

The description is one compact sentence with no filler. The key action, resource, and transport are front-loaded, and the high-value constraint 'stdio only' is included without extra prose.

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

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

For a zero-parameter tool with an output schema, the description is close to sufficient. However, it misses important operational context about the interactive OAuth behavior—such as opening a browser, blocking, waiting for user completion, and persisting the account—which an agent should understand before invoking it, especially with no annotations to fill the 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?

The tool has zero parameters and an empty input schema, so schema description coverage is trivially 100%. Since there are no parameters to document, there is nothing the description needs to add; the zero-parameter baseline of 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?

The description uses a specific verb ('Connect'), names the resource ('Gmail account'), and identifies the mechanism ('local loopback OAuth') and transport ('stdio only'). This clearly separates it from listing or removing accounts, but it does not explicitly distinguish it from the sibling accounts_auth_start, which could plausibly also involve OAuth.

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 'stdio only' provides a clear environment constraint, and 'Connect a Gmail account' implies the intended use case. However, there is no explicit guidance about when to use this tool instead of accounts_auth_start or any other alternative, and no prerequisites or exclusions 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?

With no annotations, the description must carry the behavioral burden, and it does: it reveals that the call returns a human-openable URL, consent finishes asynchronously via a public /oauth/callback, and the account appears only after consent. It does not cover failure/timeout behavior, but the main side-effect flow is disclosed.

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

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

Two sentences deliver the action, the return value, the required human step, the callback path, and the eventual outcome. The most important detail ('Start Google OAuth') is front-loaded with 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 zero-parameter tool with an output schema, the description covers the full lifecycle an agent needs to convey: invoke, receive auth_url, have a human open it, and observe the account in accounts_list after callback. No essential missing context is apparent.

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 are no input parameters, so schema coverage is trivially 100% and there is no parameter meaning to add. The baseline 4 applies because the description cannot add parameter value beyond an empty schema.

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

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

The description opens with a specific verb and resource: 'Start Google OAuth for a mailbox over HTTP.' It also distinguishes the flow from sibling list/admin tools by stating it returns an auth_url and that the finished account surfaces in accounts_list.

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 conveys clear context: call this tool when Google OAuth needs to begin for a mailbox, and the result must be opened by a human. It does not explicitly contrast it with accounts_add or other account-management siblings, so it stops short of full when-not guidance.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. 'List' conveys a non-mutating, read-only operation, and 'whether each refresh token still works' adds diagnostic context about what the tool reports. It does not mention whether checking tokens triggers network calls, but for this simple tool the behavior is reasonably clear.

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 conveys the action, resource, and purpose without waste. It is front-loaded with the verb and resource and immediately states what the tool reports.

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

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

The tool has zero parameters and an output schema is present, so the description does not need to explain return values or prerequisites. It fully covers purpose and behavior for a simple listing operation.

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

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

There are no parameters and schema coverage is 100%, so the description has nothing to add beyond the schema. The zero-parameter baseline of 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?

The description uses a specific verb ('List') and a clear resource ('connected Gmail addresses') while adding a distinct purpose: checking whether refresh tokens still work. This differentiates it from account management siblings like accounts_add, accounts_remove, and accounts_auth_start, and from status tools like gmail_status.

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 read-only listing and token-status wording imply it should be used for an account/token overview, but it does not explicitly state when to use it versus alternatives. For a simple zero-parameter list tool, this is adequate but minimally guided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly names two effects: removing the account and revoking its token at Google, which is helpful and concrete. It does not mention irreversibility or potential downstream consequences, but the two-part behavior is a strong 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?

The description is a single sentence with no filler. The action and consequence are front-loaded, making it easy to parse quickly.

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-parameter destructive tool, the description covers the action and its main side effect, and an output schema exists so return values do not need explanation. It could be more complete by specifying the account parameter format and usage caveats, but overall it is adequate for basic invocation.

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

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

The schema has one required string parameter 'account' with no description, and schema description coverage is 0%. The tool description does not explain what value to pass, such as an email address or account ID, or where to obtain that 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?

The description states a specific verb and resource: 'Remove a connected Gmail account', and adds the key side effect 'revoke its token at Google'. This clearly distinguishes the tool from sibling account tools like accounts_add and accounts_list.

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 alternatives, no prerequisites, and no exclusions. The intended context is only implied by the action itself.

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

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

No annotations are provided, so the description carries the full burden. It only states the immediate action and does not disclose whether the thread remains accessible, whether other labels are preserved, whether the operation is reversible, or any side effects beyond INBOX removal.

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

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

The description is a single clear sentence with no filler or redundancy. It front-loads the entire meaning of the tool and is appropriately sized for the simple operation.

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

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

The tool is simple and has an output schema, so return-value documentation is not needed. However, with no annotations and no usage or parameter description, the context is only minimally complete; account and behavior around labels are still under-specified.

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%, and the description does not explain the parameters. It implies thread_id refers to a Gmail thread, but account is left entirely ambiguous, and no format, source, or validation details are provided.

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

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

The description states a specific verb and resource: 'Remove INBOX from a thread.' This clearly defines the archiving action and distinguishes it from siblings like trash (delete) and unlabel (any label), so an agent can tell what the tool does.

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

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

The description gives no guidance on when to use archive versus alternatives such as trash, untrash, or unlabel. There is no mention of intended workflow, prerequisites, or exclusions, leaving the agent to infer usage from the action name alone.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the draft follows send's MIME rules and from_identity behavior, but it does not explain what those rules entail, whether the operation mutates state, what side effects occur, or what auth/permissions are needed. Much is left to inference.

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

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

The description is a single concise sentence with the core action front-loaded and no wasted words. However, it is so terse that it sacrifices necessary detail for a tool with 10 parameters.

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 tool's complexity — 10 parameters, no annotations, no parameter descriptions — a one-sentence description is severely incomplete. The output schema may cover return values, but the description fails to explain parameter semantics, side effects, usage context, or how this differs from sibling draft/send tools, so an agent cannot reliably invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, but it only references from_identity's similarity to send and vague MIME rules. It does not clarify the meaning of required parameters like to, subject, or account, nor optional ones like attachments_json or thread_id. This leaves the agent guessing beyond the schema titles.

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

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

The description clearly states the action ('Create a draft') and the resource, and references send's MIME rules, which helps situate it among email tools. However, it does not explicitly distinguish it from the sibling tool draft_send, keeping it from being a perfect 5.

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

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

No explicit guidance is given on when to use this tool versus alternatives like send or draft_send. The only signal is the verb 'create', which implies the agent wants a draft rather than sending, but no concrete scenarios or exclusions are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'post-send proof' as an outcome, but it does not describe side effects, authorization requirements, idempotency behavior, or what happens to the draft after sending.

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

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

The description is a single concise sentence with no filler, and it front-loads the core action. It is appropriately short, though the brevity comes at the cost of missing important contextual and parameter guidance.

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

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

The presence of an output schema reduces the need to describe return structure, but the tool still lacks behavioral transparency, param semantics, and usage alternatives. For a send operation with an idempotency key, an agent has too little information to call it confidently.

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

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

The input schema has 0% description coverage, and the description does not explain `account`, `draft_id`, or especially `idempotency_key`. The word 'draft' adds minor meaning to `draft_id`, but the critical semantics of idempotency and account selection are left to inference.

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 uses a specific verb and resource: 'Send a draft', which is actionable and clear. The phrase 'with post-send proof' adds a distinguishing outcome from sibling tools like `send`, though it does not explicitly name or contrast that sibling.

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 clearly implies the tool is used when a draft already exists and needs to be sent, which is a distinct context from `draft_create` or `send`. However, it does not explicitly state when not to use it or name 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?

With no annotations provided, the description carries the full behavioral disclosure burden, but it only references 'same attachment and proof rules as send' without explaining those rules. It does not disclose mutation behavior, idempotency effects, required identity/auth context, or potential side effects of forwarding on-thread.

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

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

The description is compact, front-loads the core action, and uses a terse reference to send for shared rules. It contains no filler, though the brevity veers toward under-specification rather than polished conciseness.

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

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

Given a 10-parameter input schema with no annotation coverage and no parameter descriptions, the description leaves too much unresolved. An agent still needs to consult send to understand attachment/proof rules, and the meaning of 'on-thread' is not elaborated.

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% and the description offers almost no parameter-level meaning beyond the property names. The only hint is 'attachment and proof rules as send' for attachments_json, but it does not explain required fields like idempotency_key, message_id, to, or account, nor the format of attachments_json.

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 uses a specific verb ('Forward') and resource ('a message') and adds the distinct 'on-thread' behavior, which sets it apart from a generic send. It does not explicitly contrast with sibling tools like reply, but the action and scope are clear enough.

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 'Same attachment and proof rules as send' implies that forward inherits usage constraints from send, giving some contextual guidance. However, it does not explicitly state when to choose forward over reply or draft_send, nor does it describe 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?

With no annotations, the description carries the full behavioral burden. It discloses that the tool writes to the filesystem, explains output_path constraints, and mentions the return value. However, it omits important side effects such as whether existing files are overwritten, whether directories are created, and whether authentication or prior fetching of message/attachment metadata is required.

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

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

The description is two sentences with no filler. The primary action is front-loaded, output_path rules are compactly stated, and the return value is mentioned. Every sentence contributes essential 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?

The description covers the core write behavior, path constraints, and return value, and an output schema exists to document return structure. But it lacks context about how to obtain valid account/message/attachment identifiers, whether downloads are overwrite-safe, and what download_root itself is. These gaps matter for correct invocation in an agent workflow.

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 compensate. It adds meaningful semantics for output_path, including bare filename versus absolute path behavior. However, account, message_id, and attachment_id remain undocumented beyond their names; their formats and relationships are left to inference.

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 uses a specific verb and resource: 'Write an attachment under download_root.' It clearly distinguishes this tool as the attachment-download operation among siblings like get_message and messages_list, and specifies the output location.

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

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

No guidance is given about when to use this tool versus alternatives, nor any exclusions or prerequisites. The intended use is implied by the name and parameters, but the description never explicitly routes the agent away from similar tools or states when this tool is the right choice.

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

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

With no annotations, the description carries the behavioral burden. It meaningfully discloses the three output modes, notes that metadata is 'cheap,' and indicates what plain and full add. This gives useful behavioral context beyond just 'get a message,' even though it does not mention auth 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?

Two tight sentences. The core purpose is front-loaded, and the format details are packed efficiently without redundancy.

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

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

The tool is simple, has an output schema, and the description covers the only non-obvious parameter behavior. It does not mention prerequisites like where account or message_id come from, but those are inferable from sibling tools, and the output schema handles return shape.

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 add meaning. It does exactly that for the format parameter by explaining the three allowed values and their payload differences. Account and message_id are left unexplained, but their names are self-evident and the schema marks them required.

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

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

The description opens with 'Get one message,' a specific verb and resource, and the format breakdown clarifies the scope. This distinguishes it clearly from sibling tools like messages_list or get_thread that operate on collections or threads.

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 this is for retrieving a single message by ID and offers format choices, but it never explicitly says when to prefer this over messages_list, search, or get_thread. There are no exclusions or named 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?

With no annotations, the description carries the burden of explaining behavior. It does this well by disclosing what each format returns and the relative cost ('metadata is headers+snippet only (cheap); plain adds the text body; full adds HTML and attachment metadata'). It does not mention auth or error behavior, but for a read-only thread fetch the format semantics are the main behavioral detail.

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

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

The description is a single, tightly written sentence. The core purpose is front-loaded, followed by compact, useful format details. There is no redundant or filler content.

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

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

The description covers the key decision-relevant behavior—format and cost—and an output schema exists, so return structure need not be explained. It is slightly incomplete because it does not clarify the account/thread_id parameters or give any sibling routing guidance, but it is mostly sufficient for calling the tool.

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

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

Schema description coverage is 0%, so the prose must compensate. It thoroughly explains the format parameter's values and meaning, but account and thread_id are left entirely to inference from their names despite being required parameters. This is a clear 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?

The description states a clear action and resource: 'Get messages on a thread', which distinguishes it from single-message operations like get_message. However, it does not explicitly differentiate itself from sibling tools such as messages_list or get_message, so it stops short of a 5.

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

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

The description gives no guidance on when to prefer get_thread over alternatives like get_message or messages_list. It explains format tradeoffs, but not the conditions that should lead an agent to select this tool rather than a sibling.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly states 'no Gmail API calls', which conveys that this is a non-mutating, local read-only operation. The output schema covers return-value details, so the description provides the key safety-relevant transparency without needing to repeat response structure.

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

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

The description is a single front-loaded sentence that conveys purpose and a key behavioral constraint. There is no redundant wording, and every part adds value.

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 status tool with an output schema, the description is complete enough for an agent to select and invoke it correctly. It clarifies its relationship to the Gmail API toolset and needs no further detail for correct usage.

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

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

The tool has zero parameters and an empty input schema, so there is nothing for the description to explain. The baseline of 4 for zero-parameter tools applies here.

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

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

The description states a specific verb ('Report') and resource ('server version and configuration'), and the parenthetical '(no Gmail API calls)' clearly distinguishes it from the sibling Gmail operation tools. This leaves no ambiguity about what the tool does.

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

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

The description clearly indicates this is a local/server-side diagnostics tool rather than a Gmail API operation, which effectively guides an agent away from using it for Gmail data tasks. It does not name explicit alternatives, but the context of the sibling list and the parenthetical exclusion make the intended use 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?

With no annotations, the description carries the burden of behavior and does add useful context: the identities are verified and are the exclusive valid from_identity values. It does not explicitly state that the operation is read-only, how the account is matched, or how empty or invalid account cases behave, though the output schema covers 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?

Two short sentences with no filler, and the operational constraint is stated directly. Every phrase 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 one-parameter listing tool with an output schema, the definition is nearly sufficient: it explains the resource and the constraint on its use. The gap is the undocumented account parameter and the lack of explicit safety or return-behavior language, which makes it merely adequate rather than complete.

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

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

The only parameter, account, receives no description in the schema (0% coverage) and the tool description only says 'for an account.' It does not specify the expected format, the source of valid account values, or how account relates to the accounts_list sibling 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?

The description names a specific resource ('Verified send-as identities') and ties it to the from_identity constraint, which separates it from sibling list tools such as accounts_list or labels_list. However, all action is left to the tool name; the description itself is a noun-phrase definition rather than an explicit 'list' statement.

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 rule 'Only these may be used as from_identity' gives clear context for when to call this tool: before sending, replying, or forwarding when a sender must be chosen. It does not explicitly state when not to use it or mention alternatives, so it does not reach 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It states that labels are added, but does not explain whether existing labels are preserved or replaced, whether duplicate labels are handled, or what side effects occur. This is a meaningful gap for a mutation 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 front-loaded sentence states the action first and then adds the input format parenthetically. There is no filler, and every part of the description 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?

The description is close to the minimum viable definition for a simple labeling tool, and the presence of an output schema reduces the need to explain return values. However, it still omits important context about account and the append-versus-replace semantics of adding 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?

Schema description coverage is 0%, so the description must compensate. It explains the format of the labels parameter (comma-separated names or ids), but leaves account and thread_id to be inferred from their parameter names. account in particular is ambiguous.

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 uses a specific verb and resource ('Add labels to a thread') and clearly differentiates this from the sibling unlabel tool. The parenthetical also clarifies that labels can be supplied as names or ids, leaving no doubt about what the operation does.

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

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

It clearly communicates the use case: when labels need to be added to a thread. It does not explicitly mention alternatives or exclusions, but the additive framing is unambiguous enough for an agent to know when to invoke this tool.

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

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

With no annotations, the description carries the full behavioral disclosure burden, but it only states that a label is created. It does not disclose side effects, naming constraints, authorization needs, or behavior when a label with the same name already exists.

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

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

The description is compact and front-loaded with the core action, with no wasted words. However, it is so terse that it borders on under-specification rather than effective conciseness.

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

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

For a tool with two required but undocumented parameters and no annotation context, the description omits too much for reliable invocation. The output schema exists, but the input semantics and usage context are not covered, leaving the agent to guess.

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%, and the description does not explain the meaning, format, or constraints of 'account' or 'name.' An agent cannot determine what values are valid or how the two parameters relate to creating a user label.

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 uses the specific verb 'Create' with the resource 'a user label,' clearly indicating the operation. It is distinguishable from siblings like labels_list (listing) and label/unlabel (applying/removing labels), though it does not explicitly call out those distinctions.

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

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

No guidance is provided on when to call labels_create instead of labels_list, label, or other label-related tools. There is no mention of prerequisites, such as an existing account, or whether duplicate label names should be checked first.

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

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

With no annotations provided, the description carries the full burden of behavioral transparency. The verb 'List' communicates a read-only operation, and the phrase 'system and user labels for an account' clarifies scope. However, it does not disclose potential behaviors like authentication requirements, pagination, or permission-based filtering, so it adds only basic context beyond the tool name.

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

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

The description is a single front-loaded sentence: 'List system and user labels for an account.' It contains no redundant words and communicates action, resource, and scope efficiently. Every word earns its place.

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

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

For a simple one-parameter operation that has an output schema and no annotations, the description covers the core purpose and scope. However, it omits any usage context, such as how to obtain the account value or when to choose this tool over siblings. It is minimally viable but not fully complete.

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

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

The schema has one required parameter, 'account', with zero description coverage. The description's phrase 'for an account' gives the parameter semantic meaning, indicating that the account is the scope of the listing. It does not explain accepted formats or value sources, leaving some ambiguity, but it does add meaning beyond the bare schema title.

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 ('List'), a clear resource ('labels'), and a scope ('system and user labels for an account'). This distinguishes it from siblings like labels_create, label, and unlabel, which perform different operations on the same resource. It is not a tautology and fully clarifies what the tool does.

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

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

The description provides no explicit guidance about when to use this tool versus alternatives. It does not name any sibling tool or suggest conditions for choosing another operation. The resource term 'labels' implies listing rather than creating or applying, but this is left to inference 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?

With no annotations, the description carries the burden and does disclose important behavior: headers only, no bodies, and specific header fields (originalTo, authResults) that reveal the real recipient and dkim/dmarc status. It stops short of pagination, ordering, or account-scope details, so not a 5.

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

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

Three short sentences, each adding value: what is returned, when to use it, and how to get bodies. Information is front-loaded and no words are 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?

The description gives a clear mental model and output schema exists, but input parameter semantics are a gap. An agent can start a call, but lacks guidance on query format and pagination behavior, making it adequate but incomplete.

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% and the description does not explain query, account, page_token, or max_results. The routing context hints at what data matters, but an agent gets no syntax or semantics for the required query parameter.

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

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

States a specific operation: 'List messages (not threads) with headers only — no bodies.' This distinguishes it from get_thread and get_message, and names the routing-sweep use case. No ambiguity about what the tool returns or omits.

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 ('Use for routing sweeps') and points to get_message as the follow-up for bodies 'only where needed'. This gives an agent a clear decision rule against sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It reveals little beyond the fact that a reply has attachment and proof rules like send, but does not state what those rules are, whether the action is destructive, how idempotency is handled, or what side effects occur.

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

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

The description is concise and front-loaded, but it is too sparse for the complexity of the tool. The sentence is efficient yet omits necessary context, making it under-specification rather than effective conciseness.

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

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

With 9 parameters, 3 required, no annotations, and no parameter explanation, the description is not complete enough for an agent to use the tool correctly. The presence of an output schema helps, but key behavioral and parameter context 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%, and the description does not compensate by explaining any of the 9 parameters. 'Attachment and proof rules' vaguely references behavior but gives no meaning for required fields like account, message_id, 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?

The description clearly states the tool replies on a thread, which is a specific verb and resource. However, it does not explicitly distinguish this from send or forward, so it stops short of a 5.

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

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

The phrase 'Reply on a thread' implies the use case, but there is no explicit guidance about when to choose this tool over send or forward. The reference to 'same rules as send' hints at shared behavior but does not provide 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool searches threads using Gmail query syntax; it does not disclose whether the operation is read-only, how pagination behaves, whether results are limited, or any authentication requirements.

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

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

The description is a single concise sentence with no wasted words and front-loads the core action. However, its brevity contributes to under-specification in other dimensions rather than being a well-structured, complete definition.

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 four parameters, no annotations, and zero schema descriptions, the description is not complete enough for an agent to invoke the tool confidently. Pagination and account targeting are unaddressed, though the presence of an output schema reduces the need to explain return values.

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

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

Schema description coverage is 0%, so the description must compensate for the four undocumented parameters. It adds meaning only for 'query' by mentioning Gmail query syntax; 'account', 'page_token', and 'max_results' receive no semantic explanation.

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

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

The description names a specific verb ('Search'), a clear resource ('Gmail threads'), and the method ('Gmail query syntax'). It is clear enough to be distinguished from account/label/message-level tools in the sibling list, though it does not explicitly contrast with messages_list.

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

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

No guidance is provided about when to use this tool versus alternatives such as messages_list or get_thread. The intended use is implied by the word 'search', but there is no explicit context, exclusions, or mention of when a different tool would be more appropriate.

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

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

With no annotations, the description carries the full burden and does add useful behavioral detail: attachments must be outbox file paths, a proof payload is returned, and from_identity changes From/Reply-To behavior. However, it does not disclose side effects such as creating a sent message, authentication requirements, or the semantics of idempotency_key, which is a required parameter.

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

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

The description is short and front-loaded with the core action, then adds two focused notes about attachments and from_identity. Every sentence adds information, though the parameter discussion is slightly unstructured.

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?

Despite an output schema existing, this is a 10-parameter mutation tool with no annotations and substantial schema coverage gaps. The description covers attachments and from_identity but omits guidance on idempotency, account selection, body/html_body relationship, footer, and cc handling, making it incomplete for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains from_identity behavior and the attachment path restriction, but 8 of 10 parameters remain undocumented beyond their names. Critical fields like idempotency_key, account, body vs html_body, and footer have no added meaning, leaving significant ambiguity.

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?

'Send new mail' states a clear verb and resource, and the phrase 'new mail' distinguishes this from sibling reply/forward tools. It does not explicitly name a sibling to contrast against, but the core purpose is unambiguous.

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

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

The phrase 'Send new mail' implies this is for creating and sending a new outgoing message, which distinguishes it from reply/forward/draft_send. However, the description never explicitly states when to use this tool over those alternatives or any exclusion criteria, leaving some inference required.

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

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

With no annotations, the description must disclose behavioral traits on its own, but it only states the mutation. It does not indicate whether trashing is reversible, whether it affects all messages in the thread, or what authentication or visibility requirements exist.

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

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

The description is a single, front-loaded sentence with no filler. It is concise, though it is also spare enough that important context is missing, which is better captured in other dimensions.

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

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

For a tool with no annotations and no parameter descriptions, the one-line description leaves the agent with no usage context, no side-effect information, and no relationship between account and thread_id. The presence of an output schema helps with return values, but the overall definition is incomplete.

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% and the description does not explain either parameter. The names 'account' and 'thread_id' allow some inference, but the description adds no meaning 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?

The description uses a specific verb and resource ('Move a thread to trash'), precisely stating what the tool does. It clearly distinguishes the operation from siblings like archive, unlabel, and untrash, so an agent can select it without opening schemas.

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

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

No guidance is provided on when to trash versus archive, label, or untrash, and no alternative tools are mentioned. The description states only the action with no context for choosing it over siblings.

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

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

No annotations are present, so the description must carry the behavioral burden. It discloses the core mutation (removing labels) but does not describe behavior for nonexistent labels, idempotence, permission requirements, or whether only the specified labels are removed.

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

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

The description is a single sentence with no filler. The core action is front-loaded, and the parenthetical adds valuable parameter format information without bloating the text.

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

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

The description is adequate for a simple operation and an output schema exists, but with no annotations and three required parameters it could state more explicitly which labels are affected and how account/thread IDs are resolved.

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

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

The schema has zero description coverage, so the description must compensate. It adds useful meaning for 'labels' by specifying 'comma-separated names or ids', but 'account' and 'thread_id' formats are left implicit.

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 uses a specific verb ('Remove'), names the resource ('a thread'), and names the target ('labels'). This clearly distinguishes it from the sibling tool 'label', which has the opposite purpose.

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

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

The intended use is implied by the action: use this when removing labels from a thread. However, the description does not explicitly state when not to use it or when to prefer the sibling 'label' or other thread-manipulation tools.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only states the operation itself and gives no information about side effects, irreversibility, permissions, or what happens to associated labels or thread state.

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

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

The description is a single clear sentence with no filler and states the core purpose immediately. It is concise, though it is so brief that it omits helpful behavioral and parameter context.

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

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

Given no annotations and no parameter descriptions, the definition leaves too much to inference. An output schema exists, so return values do not need explanation, but the agent still lacks guidance on how to identify the correct account or what side effects restoring might have. It is below the minimum viable bar for a mutation 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%, so the description must compensate by explaining the parameters. It does not clarify what 'account' refers to or that 'thread_id' must identify a thread currently in trash; it only implicitly maps 'thread' to thread_id. The agent is left to infer meaning from parameter names alone.

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

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

The description names a specific action, 'Restore', and a specific resource, 'a thread from trash'. It clearly expresses the inverse of the sibling 'trash' tool and distinguishes itself from related tools like 'archive' and 'unlabel'.

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 this tool should be used when a previously trashed thread needs to be recovered, so usage context is inferable. However, it does not explicitly state when not to use it, mention prerequisites, or contrast it with alternatives like get_thread or archive.

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