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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context on what capabilities are checked, but no additional behavioral traits beyond those implied by annotations.

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

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

Three concise sentences, front-loaded with purpose, no redundant 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?

Includes usage rationale and specific capabilities checked. Does not explain return format but output schema exists; still adequate for a simple introspection 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 has folder_id with 0% description. Description does not elaborate on folder_id format or purpose, leaving the parameter semantically unclear despite low schema coverage.

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

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

The description clearly states it reports folder capabilities, listing specific checks (hold messages, subfolders, rename, delete, message deletion). It distinguishes from sibling mutation 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 advises calling before attempting folder actions to avoid refusal, giving clear context. Does not explicitly list when not to use but implies preventive use.

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

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

The description discloses important behaviors beyond sparse annotations: 'the store is rewritten' (non-idempotent, not read-only) and 'Nothing readable is lost' (not destructive despite rewriting). It also warns 'do not interrupt it,' which is critical for a mutation operation.

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

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

The description is only three sentences, all essential: first states purpose, second provides context, third gives parameter guidance and a warning. It is front-loaded and wastes no 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?

The description covers the main effect, parameter options, and a key warning. However, it does not explain the confirm parameter or the expected duration. Since an output schema exists, return values need not be described, so the omission is minor but notable.

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 description explains the core parameters folder_id and account_id, but the confirm parameter (boolean, default false) is not mentioned. With 0% schema description coverage, the description should cover all parameters; the omission of confirm leaves a 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 clearly states the tool's purpose: 'Reclaim the disk space left behind by deleted messages.' It explains the compaction operation and distinguishes between compacting a single folder vs. all folders for an account, aligning precisely with the title 'Compact folders'.

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

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

The description gives explicit guidance on when to use each parameter: 'Pass folder_id for one folder or account_id for all of an account's.' It also warns not to interrupt the operation, but does not provide alternatives or explicit when-not-to-use scenarios.

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?

Description adds 'leaving the original,' confirming non-destructive behavior, which aligns with annotations. However, no details on conflict resolution, recursion depth, or permissions needed beyond what annotations provide.

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

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

One sentence, 12 words, front-loaded with verb and resource. 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?

Given 3 parameters, no param descriptions, and an output schema, the description is insufficient. Missing details on confirm parameter, prerequisites, and edge cases.

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% with no parameter descriptions. The description does not explain folder_id, destination_id, or confirm. It adds no value over the parameter names.

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?

Description clearly states 'Copy a folder and its contents under another parent, leaving the original.' It specifies the action (copy), resource (folder), and distinguishes from siblings like folder_move (which moves) or folder_create (creates new).

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 (use when you want a copy under a different parent), but no explicit when-to-use or when-not-to-use guidance. No mention of alternatives or conditions.

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 indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral insight. It does not mention permissions, whether the operation is reversible, or any side effects. For a mutation tool, this is insufficient.

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, which is concise. It front-loads the core purpose and scope. However, it could be more structured by including parameter hints without becoming verbose.

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

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

Given the existence of an output schema (not detailed), the description should still cover usage context like error conditions, uniqueness constraints, or account limits. It only states where creation occurs, leaving many gaps for a multi-parameter creation 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?

Input schema has 0% description coverage, and the tool description does not explain any parameters. The 'name' parameter is required but lacks format, uniqueness, or length constraints. 'parent_id', 'account_id', and 'confirm' have no guidance. The description adds no value over the schema.

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

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

The tool name 'folder_create' and title 'Create a folder' clearly indicate the action. The description adds the scope: 'inside another folder, or at the top of an account', making it unambiguous. It distinguishes from sibling tools like folder_copy or folder_delete by stating creation specifically.

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 does not provide any guidance on when to use this tool compared to alternatives (e.g., folder_copy for duplication). No mention of prerequisites or context. It only states where the folder can be created, not when to use it.

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

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

Goes beyond annotations: explains recursive deletion, Trash behavior (moves to Trash unless already in Trash), and that removal cannot be undone. Does not mention the confirm or dry_run_only parameters, which are relevant to 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 concise sentences. No fluff. The first sentence states the action, the second adds essential behavioral notes.

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?

Explains destructive behavior well, but fails to document the confirm and dry_run_only parameters. Given the tool has an output schema, return values are not required, but parameter guidance is missing for a destructive 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?

Schema description coverage is 0%, but the description adds no parameter details beyond implying folder_id. The confirm and dry_run_only parameters are important for safety but are not explained.

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 what the tool does: delete a folder, its subfolders, and all messages. It distinguishes from folder manipulation siblings (e.g., folder_rename, folder_copy).

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

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

Provides advice to check folder_get first if count matters and warns about irreversibility in Trash. Does not explicitly mention when to use alternatives like mail_delete for message-level deletion, but the 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 include destructiveHint: true. The description adds that subfolders are emptied but kept and that the action is not recoverable, providing context beyond annotations.

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

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

The description is two sentences, front-loaded with the primary action. It is concise but could be more structured to include parameter 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 purpose and key behavioral notes but omits parameter details. With 4 parameters, no schema descriptions, and an output schema not described, it leaves significant gaps for a destructive 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% and the description does not explain any parameters (confirm, folder_id, account_id, dry_run_only). The agent gains no guidance on parameter usage.

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 permanently deletes everything in one account's Junk folder. It specifies the scope (one account) and action (permanently delete), distinguishing it from siblings like folder_empty_trash.

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

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

The description implies usage when the goal is to empty the Junk folder. It does not explicitly mention when not to use or alternatives, but the context of sibling tools like folder_empty_trash provides differentiation.

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 mark destructiveHint=true. The description adds that deletions are permanent and not recoverable, and explains subfolder behavior. No contradictions.

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 concise sentences. Purpose is stated first, followed by parameter guidance and a note on subfolders. No unnecessary 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?

Main behavior is explained, and parameter guidance is given for three of five parameters. Missing explanation for confirm (a safety guard) and dry_run_only. Output schema exists but not shown.

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%, but description explains account_id, folder_id, and remove_subfolders. However, confirm and dry_run_only are not explained, leaving gaps for a destructive 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 clearly states 'Permanently delete everything in one account's Trash,' which is a specific verb-resource combination. It distinguishes from sibling tool 'folder_empty_junk' by targeting trash specifically.

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 explains how to use account_id vs folder_id and notes that subfolders are removed unless remove_subfolders=false. It does not explicitly state when not to use, but the 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 already indicate read-only and idempotent behavior. The description adds specific context about return data (counts, flags, quota) beyond annotations.

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

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

Two succinct sentences, no filler. Front-loaded with purpose, followed by usage guidance. 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?

Given output schema exists and description mentions return content, it's mostly complete. Minor gap: no mention of whether include_subfolders affects output, but assumption is reasonable.

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?

No parameter descriptions in the schema or description. folder_id and include_subfolders are undocumented, leaving the agent to infer meaning from context. With 0% schema coverage, description should compensate.

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 it retrieves a single folder including counts, special use, flags, and IMAP quota. It distinguishes from folder_list, which is for finding IDs cheaply.

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 advises when to use (re-check after move/delete) and when not (for initial ID lookup, use folder_list). Provides clear 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe read behavior. The description adds important behavioral context that the returned folder id works anywhere a folder id is accepted (e.g., in mail_list), which is beyond annotations. No contradictions; description complements annotations.

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

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

The description is extremely concise: two sentences that front-load the core purpose and then provide a useful example. Every sentence adds value without redundancy. Perfect structure for quick understanding.

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 simplicity, presence of output schema, and thorough annotations, the description is nearly complete. It explains the unified concept and id reusability. Minor gaps: no mention of what happens if folder_type is invalid (though enum constrains it), and no details on response structure (covered by output schema). Overall, adequate for a getter 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%, meaning no parameter descriptions exist. The tool description does not explain the parameters (folder_type enum, include_subfolders). While enum values are somewhat self-explanatory, the include_subfolders parameter is completely undocumented. The description fails to compensate for the lack of schema descriptions.

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

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

The description clearly states that the tool gets a 'unified folder that spans every account' and provides a concrete example with the unified inbox. It distinguishes from sibling tools like folder_get (specific folder) and mail_list (can use unified id). The verb 'get' and resource 'unified folder' are specific and 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 description does not explicitly state when to use this tool versus alternatives like folder_get or mail_list. It implies use for cross-account operations via the example, but lacks explicit 'when-not-to-use' or comparison with siblings. Some guidance is provided through the example, but it's not directive.

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 indicate readOnlyHint=true and idempotentHint=true. Description adds critical detail that counts come from Thunderbird's folder database and may lag on IMAP until folder is selected. This goes beyond annotation scope and is highly valuable.

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?

Description is well-structured and front-loaded with the main purpose. Uses plain English and section breaks for readability. Could be slightly shorter but remains focused and no wasted sentences.

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 14 parameters and no schema descriptions, the description covers core functionality (default browsing, depth, name filter, tree structure, count accuracy) but omits explanations for most filtering options. Adequate for basic use but incomplete for advanced filtering 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 0% but description only explains three parameters (name, depth, tree) out of fourteen. Many filtering parameters (limit, is_tag, special_use, etc.) are not described at all, forcing the agent to rely on parameter names and defaults.

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?

Clearly states the tool lists mail folders with IDs and message counts. The title 'List folders' is unambiguous. Description distinguishes from similar tools by explaining default browsing behavior and filter options.

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

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

Provides explicit guidance on default behavior (browse root+1 level), how to increase depth, or use name filter for case-insensitive substring search. Mentions tree=true for nested output. Lacks explicit when-not-to-use comparisons but covers major usage patterns.

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

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

Discloses important behaviors beyond annotations: no per-message undo, confirmation required, and IMAP server sync. Complements the annotations (idempotentHint=true, destructiveHint=false) well.

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

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

Very concise: two sentences with front-loaded purpose. 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?

Covers key aspects (undo, confirmation, server sync) but is brief for a tool with 3 params and an output schema. Agent would need to infer return values from output 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 0% schema coverage, description only hints at the confirm parameter through 'asks first'. Does not explain folder_id or include_subfolders, leaving the agent to infer from schema 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?

Description clearly states verb 'Mark' and resource 'every message in a folder as read', which is specific and distinguishes from sibling tools like mail_mark (individual messages) or folder_delete.

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?

Mentions the need for confirmation due to no per-message undo, implicitly guiding when to use with confirm=true. However, does not explicitly compare to alternatives or state when not to use.

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

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

The description adds important behavioral context beyond annotations: cross-account moves copy then delete, which is destructive, and warns about IMAP slowness. Annotations are neutral (all false), but description contradicts destructiveHint by explicitly describing deletion.

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 that are front-loaded and efficient. Every sentence provides essential information without waste.

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

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

The description covers the main purpose and important cross-account behavior but fails to document non-obvious parameters like confirm and dry_run_only. With an output schema present, lack of return value explanation is acceptable, but parameter gaps reduce completeness.

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%, but the description only explains destination_id. It does not describe the other three parameters (folder_id, confirm, dry_run_only), leaving their semantics unclear.

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 'Move a folder under a different parent, with its subfolders', specifying the action and resource. It distinguishes from siblings like folder_copy and folder_delete by its purpose and notes cross-account behavior.

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 when to use (to relocate a folder) but lacks explicit guidance on when not to use or alternatives. It mentions cross-account slowness but no prerequisites or exclusion criteria.

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

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

The description adds the behavioral detail that messages and subfolders are kept, which is beyond the annotations (all false). However, it does not disclose potential side effects like changes to links or constraints, so it is only moderately transparent.

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 that front-loads the action. It is appropriately sized for a simple tool, though it could be slightly more structured with additional explicit sections.

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 operation and mentions preservation of content, but given the tool has 3 parameters and an output schema, it lacks completeness in usage guidelines and parameter details. Suitable for a simple tool but with clear gaps.

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

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

With 0% schema description coverage, the tool description does not explain any parameters. While parameter names are self-explanatory, the description adds no additional meaning, and the optional 'confirm' parameter's purpose remains unclear.

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

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

The description clearly states the verb ('Rename') and resource ('a folder'), and adds the detail that messages and subfolders are preserved, distinguishing it from sibling tools like folder_move or folder_copy.

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 use this tool versus alternatives, nor any prerequisites or restrictions (e.g., permissions, folder not in use). This omission increases ambiguity for the agent.

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 idempotentHint=true and destructiveHint=false are supplemented by the description's statement that the operation is cosmetic and reversible, and not gated. This adds valuable context about impact and side effects.

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

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

Two sentences, front-loaded with the main action, and no unnecessary words. Every sentence 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?

While the description covers purpose, usage, and behavioral aspects, it omits parameter details. Given the existence of an output schema and simple tool, it is adequate 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?

Schema description coverage is 0%, yet the description does not explain the parameters. The 'favorite' boolean defaulting to true and 'folder_id' are not clarified, leaving ambiguity about their meaning.

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

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

The title 'Favourite a folder' and description explicitly state the action (add/remove) and resource (folder). It clearly distinguishes from sibling tools like folder_create or folder_rename which handle different operations.

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 explains that the tool is cosmetic and reversible, affecting only the folder pane's Favourites view, and that it is not gated. This provides clear context on when to use it, but does not explicitly list alternatives or when not to use it.

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?

Description adds behavioral context: fetches message bodies, requires network traffic, can be long. Annotations are non-contradictory (destructiveHint=false, readOnlyHint=false). No annotation contradiction.

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

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

Two sentences plus a note, concise and front-loaded. Could be more structured but generally efficient.

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

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

Despite output schema existence, description lacks parameter explanations, which are essential for correct invocation with 3 parameters. Behavioral context is good but incomplete for agent to use correctly without parameter guidance.

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

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

Schema coverage is 0% (no parameter descriptions). Description does not explain any of the three parameters (confirm, folder_id, include_subfolders). Agent has no guidance on how to use them.

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?

Title and description clearly state downloading folder for offline use, specifically fetching IMAP message bodies for mail_get_source. Distinguishes from siblings by linking to mail_get_source.

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 states it's needed before mail_get_source for offline source. Warns about large folders causing long download and network traffic. No explicit when-not-to-use, but 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 provide non-destructive hint; description adds 'configured archive layout' detail but doesn't clarify if archiving moves, marks, or changes visibility. Behavioral traits beyond annotations are minimal.

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?

Single, front-loaded sentence with no wasted words. Efficiently conveys core purpose.

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 2 parameters and an output schema, the description is minimal but adequate for a simple action. Lacks details on permissions, irreversibility, or return value behavior, but output schema reduces burden.

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%, but the description does not explain the 'confirm' boolean or clarify 'message_ids'. Parameter names are self-explanatory, but description adds no additional 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?

Description clearly states action (archive) and resource (messages), with added context about account-specific archive layout. Distinguishes from sibling tools like mail_delete or mail_move.

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 for archiving messages, but no explicit guidance on when to use vs alternatives. Siblings include mail_move and mail_delete, but no rationale for choosing archive over them.

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, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value by specifying the return fields (part names, sizes, content types) beyond what annotations provide, but does not elaborate on potential edge cases (e.g., messages with no attachments). No contradictions.

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 that is concise and front-loaded with the key action and result. It contains no unnecessary words. However, it could be slightly more structured by adding a separate sentence for usage context, but overall it is efficient.

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

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

Given that the tool has only one required parameter and an output schema, the description is nearly adequate. It explains what the tool lists but lacks guidance on usage context (e.g., when to retrieve a message's attachments) or parameter clarification. The output schema covers return values, so that gap is mitigated.

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%, meaning the description adds no information about the sole parameter (message_id). The schema only provides type and title. The description should compensate by clarifying the parameter's meaning (e.g., 'ID of the message to list attachments for'), but it does not.

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 ('List a message's attachments with part names, sizes and content types.') clearly specifies the action ('list'), the resource ('attachments of a message'), and the output details ('part names, sizes and content types'). It distinguishes from sibling tools like mail_save_attachment or mail_get.

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 guidance on when to use this tool versus alternatives (e.g., mail_save_attachment to download). It does not mention prerequisites like needing a message_id or the context in which the tool is useful. The input schema indicates required message_id but no contextual hints.

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

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

The description adds context beyond annotations: it reveals that the tool opens a UI window, does not send or save, and is not gated. Given annotations only show readOnlyHint=false, etc., the description meaningfully informs behavior without contradicting annotations.

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

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

The description is relatively concise at 4 sentences, front-loading key info. However, some phrasing like 'the right answer whenever...' is slightly verbose, and 'so this is not gated' may not be universally clear.

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 having 12 parameters and no parameter descriptions in the tool description, the description fails to explain parameter usage. The output schema exists but isn't referenced. Completeness is low for a tool with this many parameters.

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 tool description provides NO information about any of the 12 parameters (to, cc, subject, etc.). It only says 'populated compose window' without explaining what each parameter does. This is a critical 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 clearly states it opens a populated compose window for manual finishing, distinguishing it from send/save tools. It explicitly says 'nothing is sent or saved' and 'user sees window appear', differentiating it from siblings like mail_send and mail_draft_save.

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 explicit guidance on when to use: 'when the wording matters more than the automation, or when the user declined a send'. It also clarifies what the tool does not do: 'nothing is sent or saved' and that it is 'not gated'.

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

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

The description reinforces the non-destructive nature hinted by destructiveHint=false with 'leaving the originals in place', but adds no further behavioral details like permissions or limitations.

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, efficient but lacks detail on parameters and usage, making it under-informative.

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

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

Despite having an output schema, the description is too minimal for a tool with three parameters and no schema descriptions. Missing parameter guidance reduces completeness.

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%. The description does not explain the parameters (message_ids, destination_folder_id, confirm), leaving the agent without guidance on their use.

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 (copy) and resource (messages) and distinguishes from siblings like mail_move by specifying 'leaving the originals in place'.

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 use this tool versus alternatives such as mail_move or mail_archive. The description lacks context for selection.

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

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

Beyond the destructiveHint annotation, the description adds that messages are moved to Trash unless permanent=true, and that permanent deletes are irreversible in Thunderbird. This provides valuable behavioral context beyond the annotation's binary hint.

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 with two sentences: the first states the action and behavior, the second provides a usage guideline. It is front-loaded with the key information and contains no unnecessary 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?

While the description covers the core behavior and gives a warning, it lacks explanation for parameters like 'confirm' and 'dry_run_only', and does not mention that multiple messages can be deleted. Given the existence of an output schema, return value details are not required, but the parameter gap makes it only adequate.

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 0% schema description coverage, the description should explain all parameters. It only mentions the 'permanent' parameter. The 'message_ids', 'confirm', and 'dry_run_only' parameters are left unexplained, leaving the agent to infer their purpose from the tool name or context, which is insufficient.

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 'Delete messages' with the specific verb and resource. It distinguishes the behavior from siblings by noting the default move to trash and the permanent delete option, making the tool's purpose 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 description advises preferring the default trash behavior over permanent delete because it cannot be undone, providing clear context. However, it does not explicitly compare to sibling tools like mail_archive or mail_move, but the guidance is sufficient for most use cases.

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

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

The description goes beyond annotations by stating 'Nothing leaves the machine, so this is not gated,' revealing that the operation is local and safe. It also explains the difference between draft (user review) and template (reusable, opened as copy). This adds valuable context not present in annotations.

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

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

The description is concise (5 sentences), front-loaded with the primary purpose, and each sentence adds value. There is no redundancy or fluff.

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 9 parameters and two modes (draft/template), the description provides reasonable context: it explains the two use cases, the optionality of recipients, and the local nature. However, it omits details about attachments and identity_id. The presence of an output schema partially offsets the need to describe 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?

With schema description coverage at 0%, the description primarily explains the 'kind' parameter (draft vs. template) and notes that recipients are optional. However, there is no explanation for other parameters (cc, bcc, body, subject, attachments, identity_id, is_html), leaving the agent without sufficient guidance for the 9 parameters.

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

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

The description clearly states 'Save a message without sending it, as a draft or a template.' It specifies the verb (save) and resource (message), distinguishes between draft and template, and contrasts with sending. This effectively differentiates from sibling tools like `mail_send`.

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 explains when to use this tool: 'when you want the user to review before anything is sent,' and clarifies that recipients are optional. It implies not to use for sending by mentioning 'unlike a send.' However, it does not explicitly 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?

The description adds context about saving a draft unless mode='send' and explains forward_as options, which goes beyond annotations. However, it does not clarify the destructiveHint=true (e.g., what is destroyed) or mention auth or rate limits.

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

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

The description is brief (three sentences) and front-loaded with the primary purpose, then details. It is efficient and well-organized, though some parameter explanations could be more concise.

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

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

Given the tool's complexity (12 parameters, output schema present), the description covers the core function and key options but omits details on return values, destructive behavior, and many parameters. It is adequate 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?

With 0% schema description coverage, the description compensates by explaining 'body', 'forward_as', and 'mode' parameters. But most parameters (cc, bcc, confirm, etc.) are left unexplained, limiting its value for correct invocation.

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 identifies the tool as forwarding a message and explains the draft vs send behavior. However, it does not explicitly differentiate from siblings like mail_reply, though the tool name and action are distinct 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 description lacks explicit guidance on when to use this tool versus alternatives (e.g., mail_reply, mail_send). It states what the tool does but not the conditions or prerequisites for using it.

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. The description adds value by explaining detail level behaviors (MIME tree in full, no body in summary) and decryption context, which are not covered by annotations.

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

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

Three concise sentences with front-loaded purpose. No wasted words; every sentence provides distinct 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?

Given the presence of an output schema and clear annotations, the description covers key behavioral aspects (detail modes, decryption). It could mention prerequisites or edge cases, but for a simple read tool it is sufficiently 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 0%; description explains the `detail` enum well (summary/text/full behaviors) but does not document the `decrypt` or `message_id` parameters. Partial compensation leaves a gap for two of three parameters.

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

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

The description clearly states 'Read one message' with a specific verb and resource. It distinguishes detail levels (summary, text, full) and even mentions decryption, which sets it apart from sibling tools like mail_get_many or mail_get_source.

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 guidance on when to use each detail mode (text, summary, full) and decryption behavior. However, it does not explicitly compare to alternatives or state when not to use this tool, leaving some ambiguity for the agent.

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

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

The description adds the behavioral constraint of 'up to 50 messages', which is not evident from annotations. Annotations already indicate read-only, idempotent, and non-destructive nature, and the description aligns without contradiction.

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 14 words, front-loading the action and constraint. Every word is necessary and no space 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?

Given the output schema exists and tool complexity is low, the description covers core behavior. Missing parameter details are the only gap, but the schema partially addresses 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?

The description provides no information about the 'message_ids' or 'detail' parameters. With 0% schema description coverage, the description should compensate but fails to explain parameter meaning or usage.

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 it reads up to 50 messages in one round trip, with a specific use case of triaging search results. It uses a specific verb ('Read') and resource ('messages'), and implies differentiation from single-message or search tools.

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

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

The description explicitly mentions the context 'for triaging a search result', indicating when to use it. While it does not list alternatives or when not to use, the purpose is clear enough to guide selection among sibling tools.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds a key behavioral detail: on IMAP, the message must be available offline or the tool will error rather than return partial data. This goes beyond annotations but could still benefit from mentioning authentication requirements or rate limits.

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

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

Two concise sentences, front-loaded with purpose and followed by an essential behavioral note. No filler or redundant 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?

Given the output schema exists, the description covers the core functionality and key constraint (IMAP offline requirement). It is sufficient for the tool's complexity but could mention the return format or edge cases for completeness.

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 provides no explanation of the two parameters (message_id, decrypt). It does not clarify the meaning of decrypt or the format of message_id, leaving the agent to rely solely on the schema which lacks descriptions.

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 ('Fetch') and resource ('raw RFC 5322 source'), clearly distinguishing it from siblings like mail_get (which returns parsed message). The phrase 'for header forensics' further clarifies its specialized use case.

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 clear context ('for header forensics') and a practical constraint on IMAP ('needs the message to be available offline'). It implicitly guides the agent to use this when raw source is needed, avoiding alternatives like mail_get. However, it lacks explicit when-not-to-use or alternative tool names.

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 and destructiveHint=false, so the agent knows it's safe. The description adds value by stating the default ordering ('newest first'), but it does not disclose other behavioral traits like pagination via cursor or limit behavior. With strong annotations, the description is adequate but not exceptional.

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, front-loading the purpose and then adding guidance. Every sentence is necessary and contributes to understanding. There is no fluff or 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 description covers the core functionality and provides sibling guidance, but it lacks details about parameters like pagination (cursor), limit, and sorting options. Given there are 5 parameters and an output schema, the description is minimally adequate but could be more helpful, especially around pagination and limit behavior.

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

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

Schema description coverage is 0%, meaning the description doesn't explain any parameter meaning. While the schema provides defaults and enums, the description fails to add context beyond what is in the schema. For example, it doesn't mention that 'cursor' is for pagination or that 'sort_by' can be used to change ordering. The description should compensate for low schema coverage but does not.

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's purpose: 'List messages in one folder, newest first by default.' It specifies the verb (List), resource (messages in one folder), and default ordering. It also distinguishes from siblings by mentioning folder_list for discovering folder ids and mail_search for selective queries.

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 explicit guidance: 'Use `folder_list` to discover folder ids. For anything selective, prefer `mail_search`.' This tells the agent when to use this tool and when to use alternatives, making the decision 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?

Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds that the operation is 'cheap and reversible,' which clarifies its benign nature. This provides useful context not present in structured fields, though it does not cover all possible behaviors (e.g., no rate limits 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?

The description is two sentences, front-loaded with the purpose, and every word earns its place. No redundant or vague phrasing, making it highly efficient.

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

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

Given 6 parameters, 1 required, and an output schema (handling return values), the description covers the main operations and a key constraint. It could elaborate on multiple message handling or interactions between parameters, but it is sufficiently complete for a marking 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?

With 0% schema coverage, the description compensates by listing the actions (read, flagged, junk, add_tags, remove_tags) and directing to `mail_tags` for tag values. This adds meaning beyond the schema's types and defaults, though it could explain the effect of null defaults (no change) more explicitly.

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 sets read/flagged/junk state or adjusts tags on messages, specifying the verb 'set' and the resource 'messages'. It distinguishes from siblings like folder_mark_read, mail_delete, and mail_tags by focusing on per-message marking operations.

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 notes that the operation is 'cheap and reversible, so no confirmation is required,' providing guidance on when it is safe to use. It also references `mail_tags` for valid tag keys, implying a prerequisite. However, it does not explicitly compare to alternatives or 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.

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

Adds value beyond annotations by describing IMAP asynchronous behavior and confirmation wait. Annotations already indicate non-destructive, so this is additive context.

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

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

Extremely concise: two sentences front-loading purpose and adding a key behavioral note. 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?

While output schema exists, the lack of parameter descriptions is a major gap. The tool's behavior (e.g., cross-account moves, failure conditions) is not addressed.

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?

Description provides no parameter details. With 0% schema coverage, the burden is on the description, but it fails to explain any of the 4 parameters (confirm, dry_run_only, message_ids, destination_folder_id).

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

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

The description clearly states the tool moves messages into another folder, distinguishing it from copy or delete operations. However, it doesn't specify if the move is restricted to the same account or possible across accounts.

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

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

No guidance on when to use this tool over alternatives like mail_copy or mail_delete. The description only mentions IMAP behavior, not usage context.

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

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

The description adds behavioral context beyond annotations: it indicates that the tool creates a draft or sends depending on mode, that Thunderbird derives recipients/subject/quote, and that setting cc replaces derived addresses. This aligns with destructiveHint=true and provides nuance not captured by annotations.

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

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

The description is four sentences with no extraneous words. The first sentence gives the core purpose and default behavior. Subsequent sentences logically detail derivation, variants, and warnings. It is front-loaded and earns each sentence.

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

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

With 13 parameters and an output schema, the description covers the main workflow but omits many parameter details. It explains the essential behavior (draft/send, derivation, reply variants) but lacks specifics on parameters like confirm, is_html, attachments, identity_id, and quote_original. The output schema presumably covers return values, so the missing param details limit completeness.

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 mentions message_id, body, mode, reply_all, reply_to_list, and cc but does not explain bcc, confirm, is_html, subject, attachments, identity_id, or quote_original. Many important parameters are left undocumented, forcing the agent to infer from the schema 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 clearly states 'Reply to a message' and specifies that it saves a draft unless mode='send'. It distinguishes between reply_all and reply_to_list, and implies how it differs from new mail or forward tools. The verb and resource are specific and 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 description explains when to use the tool (to reply) and provides guidance on mode, reply_all, reply_to_list, and the implication of setting cc. It implicitly warns about overriding derived addresses. It does not explicitly mention alternatives like mail_send but the context is clear enough for an agent to infer.

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 indicate readOnlyHint=false, so write is expected. The description adds valuable behavioral detail: it refuses to overwrite existing files unless overwrite=true. This is beyond annotations and informs the agent of side-effect conditions.

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 wasted words. Critical information front-loaded (main action) followed by specific constraints. Efficient and clear.

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 existence of an output schema (not shown) and low parameter count, the description covers the core behavior: saving one attachment with overwrite avoidance. It could mention potential permissions or directory creation, but it's adequate for the complexity.

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

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

Schema coverage is 0%, so description must compensate. It explains part_name (from mail_attachments) and overwrite (controls clobbering), but does not describe message_id, directory, or filename. The schema provides basic types, but the description leaves gaps for half the parameters.

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

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

The description clearly states the tool's action: 'Write one attachment to a directory on this machine.' It specifies the resource (attachment) and the scope (directory on machine). It distinguishes from siblings as the only tool for saving attachments, without confusion.

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 clear context for use: saving an attachment, with note that part_name comes from mail_attachments. It doesn't explicitly state when not to use or list alternatives, but the purpose is straightforward and the sibling context shows no competing 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?

Beyond annotations (readOnly, idempotent, non-destructive), the description explains that full_text uses Thunderbird's global index on indexed messages, while other fields are substring per-folder. It also specifies ISO-8601 dates and that results are summaries. This adds meaningful context without contradicting 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?

Four sentences, front-loaded with purpose, followed by critical behavioral details and pagination. No redundant information; every sentence 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?

Given the presence of an output schema, the description covers the essential: search behavior, filter combination, pagination, and when to use mail_get. It lacks explicit mention of folder or account scoping (though schema has account_id and folder_id), but overall is fairly complete for a complex search 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?

With 22 parameters and 0% schema description coverage, the description only mentions full_text, subject, author, body, cursor, and dates implicitly. It does not explain the many other parameters like junk, tags, to_me, folder_id, etc., leaving the agent 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 clearly states 'Search the user's mail' with specific verb and resource. It distinguishes itself from sibling tools like mail_get (retrieve body) and mail_list (list all) by focusing on search with filters. The differentiation from other search tools is implicit through context.

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 explicit guidance on combining full_text with filters, notes that subject/author/body are substring matches, and advises using mail_get for full body. It also explains pagination with cursor. However, it does not explicitly state when to use this tool over alternatives like search_global or mail_list.

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 indicate this is a write operation with potential destructiveness. The description adds valuable context about the draft confirmation behavior, the 'send' and 'later' modes, and the fact that attachments are local file paths. No contradiction with annotations.

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

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

The description is concise at 6 sentences, front-loading the key behavior before diving into details. Every sentence adds value, though some could be more efficient. No fluff.

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?

While the description covers the core workflow and highlights the most important parameters, it omits many details about optional parameters and does not describe the output schema or error conditions. Given the tool's complexity (16 params) and the existence of an output schema, the description is moderately 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 description explains only 4 of 16 parameters ('to', 'attachments', 'mode', 'reply_to_message_id'), leaving the remaining 12 (including 'cc', 'bcc', 'priority', 'is_html', etc.) entirely unexplained. Given 0% schema description coverage, the description should compensate more thoroughly.

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 'Write a message' and explains the three modes (draft, send, later), explicitly distinguishing from the sibling tool 'mail_reply' which is recommended for replying with quoting. The verb+resource is specific and the scope is well-defined.

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 explicit guidance for when to use 'mail_reply' instead for replying with quoting. It also explains the default draft behavior and the 'later' mode. While it doesn't exhaustively cover all alternatives, it gives clear context for the primary use case and one key sibling distinction.

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. The description adds context that an empty list is normal and how messages get there, consistent with a safe read operation.

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

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

The description is two sentences long, front-loaded with the main purpose, and contains no redundant information. Every sentence 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?

Given the tool's simplicity, an existing output schema, and clear annotations, the description sufficiently explains the tool's behavior and return value 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?

The only parameter 'limit' has a default of 25, but the description does not mention it or explain its purpose. With 0% schema description coverage, the description should compensate but fails to add meaning beyond the schema's property name.

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 'List messages sitting in the Outbox, unsent,' which is a specific verb and resource. It distinguishes from sibling tools like mail_search or mail_list by focusing on outbox 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 description explains when messages appear (queued with mode='later' or while offline) and that an empty list is normal. It provides context but does not explicitly exclude alternatives or mention when not to use it.

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 flag destructiveHint=true. The description adds valuable behavioral context: messages keep the raw keyword but lose the label, which is beyond what annotations provide. However, it does not mention the confirm parameter or irreversibility.

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, concise and front-loaded. The primary action is stated first, followed by a clarifying consequence. No unnecessary words or repetition.

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 simplicity and the presence of an output schema, the description covers the core behavior. However, it omits the role of the 'confirm' parameter and does not clarify that the operation is destructive, though annotations hint at it. Overall, adequate but with minor gaps.

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

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

Schema description coverage is 0%, so the description must explain parameters, but it does not. Neither 'key' nor 'confirm' are described, leaving agents to guess their meaning and purpose.

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 ('Remove a tag definition') and the resource. The second sentence explains the effect on messages, which adds specificity. It does not explicitly distinguish from sibling mail_tag_upsert, but the verb 'Remove' implies deletion.

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 guidance on when to use this tool versus alternatives like mail_tag_upsert or mail_mark. It does not mention prerequisites, contexts, 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 and idempotentHint. The description adds value by stating the return structure (keys, labels, colours). No contradictions or gaps beyond what annotations cover.

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. Every element contributes to understanding the tool's purpose and output.

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 list tool with no parameters, a rich output schema, and comprehensive annotations, the description is fully adequate. It explains what the tool does and what it returns.

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?

No parameters exist, and the input schema is empty with 100% description coverage. Per guidelines, 0 parameters earns a baseline of 4. The description does not need to add parameter details.

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 ('List the tags') and the scope ('defined in Thunderbird'), and specifies the returned fields ('keys, labels and colours'). It distinguishes from sibling tools like mail_tag_upsert and mail_tag_delete.

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 on when to use this tool versus alternatives. While the purpose is clear, the description does not mention that this is a read-only operation or suggest using it before modifying tags.

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

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

Discloses color format (#RRGGBB) and behavior regarding key usage. Annotations indicate idempotent and non-destructive nature, which description does not contradict. No mention of side effects 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?

Extremely concise; two sentences plus code block. Front-loaded with purpose, no filler. Every sentence 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 4-parameter tool with output schema, description covers creation vs update and color format but omits explanation of 'confirm' and potential side effects. Output schema exists, so return values need not be explained.

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?

Description explains 'key' (omit/create vs pass/update) and 'color' (format) but does not describe 'label' or 'confirm'. With 0% schema coverage, description compensates partially.

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?

Title and description clearly state the tool creates or updates a tag. It distinguishes from siblings like mail_tags (list) and mail_tag_delete (delete).

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 instructs to omit 'key' for creation and pass an existing key for update, providing clear usage guidance. Lacks explicit when-not-to-use, but sufficient for the role.

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?

Beyond annotations, describes sorting order and multi-folder scope. Does not mention behavior for limit parameter or when both IDs are provided, which are minor gaps.

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?

Concise two-sentence description with no unnecessary words. Each sentence conveys 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?

Covers the core functionality well given the existence of an output schema. Missing details on limit parameter and edge cases (e.g., missing ID) are minor but notable gaps.

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

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

With 0% schema coverage, description adds meaning for message_id and header_message_id by clarifying their sources. However, limit parameter is not explained, and behavior when both IDs are given is omitted.

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?

Clearly states it retrieves all messages in a single thread, sorted oldest first, across folders and accounts. Differentiates from mail_search by specifying how to reference 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?

Provides explicit guidance on how to provide input (message_id from mail_search or RFC header_message_id). Indicates use case for reconstructing discussions spanning folders, but lacks explicit when-not-to-use instructions.

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 indicate read-only and idempotent. The description adds that results include a relevance score and conversation id, and that the indexer may be disabled or catching up. This contextualizes the tool's behavior beyond 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?

The description is three sentences: first states core purpose, second provides usage and output context, third gives troubleshooting. Every sentence is valuable and front-loaded, with 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?

The description covers purpose, when to use vs alternatives, output structure, and error handling. It lacks parameter explanations, but the output schema exists and parameters are common. For a tool with 4 parameters and many siblings, this is nearly 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 0%, so the description must compensate. It does not explain any of the 4 parameters (query, limit, offset, folder_id) beyond their schema names and defaults. The parameter names are self-explanatory but the description offers no additional guidance.

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 'Ranked full-corpus search across every indexed folder and account,' specifying the verb (search), resource (full-corpus), and scope. It distinguishes from siblings like mail_search and search_conversation, making the purpose unmistakable.

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

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

Explicitly says 'Best for open questions' and provides examples. It also tells when not to use it: 'For precise filters... use mail_search instead.' Additionally, it advises calling search_index_status if results are empty, giving a complete usage roadmap.

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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it reports status (enabled/progress), but doesn't disclose additional behavioral traits. Adequate but not outstanding.

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 wasted words, front-loaded with purpose. Efficient and clear.

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 zero parameters, output schema exists, and rich annotations, the description fully covers the tool's purpose and usage context. No gaps.

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

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

No parameters, schema coverage 100%. Baseline for zero params is 4. Description adds no param info, but none needed.

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 reports whether the global index is enabled and progress. It distinguishes from siblings like search_global by saying it explains empty search_global results.

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 to call when search_global returns empty, and notes that mail_search still works without indexing. Provides concrete when-to-use 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?

Beyond annotations (which show no destructive or readOnly hints), the description discloses that nothing is copied or moved—just a stored query. It also explains online_search behavior (IMAP vs local), adding useful behavioral context that annotations lack.

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 with three paragraphs: purpose, parameter specifics, and a clarifying statement. Each sentence adds value, but the parameter explanation could be more compactly integrated.

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 8 parameters (3 required) and an output schema, the description covers the core functionality and key parameters. It lacks detail on some optional parameters, but overall it provides sufficient context for an agent to use the tool 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. It explains search_folder_ids, terms, match_all, and online_search in detail, but omits confirm, dry_run_only, and parent_folder_id. This partial coverage justifies a 3.

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

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

The description clearly states the tool creates a saved search that appears in the folder pane, distinguishing it from other search tools like mail_search or search_global. It specifies that it's a stored query, not a copy/move, which helps an agent understand the unique function.

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 usage context, such as search_folder_ids from folder_list and terms syntax with attributes/operators. It explains when to use it (persistent search) but does not explicitly state when not to use it or mention alternatives; however, the context of sibling tools and the term 'saved search' implicitly differentiates.

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