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

Annotations already mark the tool as non-read-only and non-idempotent. The description adds that rows are added to the end and the table range automatically extends, which is useful behavioral context beyond what annotations provide. 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?

Two succinct sentences, front-loaded with the primary action, no redundant information. Each sentence earns its place by stating what the tool does and a key prerequisite.

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

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

With an output schema present and annotations covering the mutation and side-effect profile, the description is sufficiently complete. It explains the core behavior and the necessary preliminary step, without needing to detail return values or error handling for this level of complexity.

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

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

Schema description coverage is 100%, with all four parameters described. The description only reinforces the relationship between table_id and list_sheet_tables, which is already in the schema, and does not add meaningful extra semantics for parameters like values or spreadsheet_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?

Description clearly states the tool 'Appends rows to a structured table in a Google Sheet', specifying the verb and resource. This distinguishes it from sibling tools like create_table_with_data and modify_sheet_values by focusing on appending to existing structured tables, and mentions the automatic extension of the table range.

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 advises 'Use list_sheet_tables first to find the table ID', providing a concrete prerequisite. It does not enumerate alternatives or exclusions, but the context within the Sheets toolset makes when-to-use clear enough.

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 behavior not visible in annotations: the batch endpoint silently ignores unrecognized ids, returns no per-message result, and defaults to reading messages back to verify which ids changed. This significantly strengthens the agent's understanding of the mutation's real-world behavior.

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

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

The description is compact and front-loaded with the main action, then delivers the critical caveats in clear, economical sentences. Every sentence contributes actionable information.

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

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

The description covers the most important operational quirks and the verify behavior, and an output schema exists so return values need not be spelled out. Minor gaps remain, such as not explicitly requiring at least one of add_label_ids or remove_label_ids and not naming the singular alternative for redirection.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by clarifying that message_ids must be MESSAGE ids rather than thread ids, and by explaining the verify parameter's purpose in relation to the endpoint's silent-id behavior.

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 specific action ('adds or removes labels'), the resource ('multiple Gmail messages'), and the batching scope ('single batch request'). This distinguishes it from sibling message-label tools like modify_gmail_message_labels.

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

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

The description implies use for batch label modifications and warns that it takes MESSAGE ids, not thread ids, which is useful guidance. However, it never explicitly names the singular sibling tool or states when to prefer this batch version over alternatives, leaving some selection inference to 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 already declare readOnlyHint=false and destructiveHint=true, so the description doesn't need to restate safety. It adds value by disclosing atomicity ('single atomic batch update') and warning about 'index calculation errors' with a phased workflow mitigation. This goes beyond the annotations without contradicting them.

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 longer than average but well-structured with a core statement, a clear alternative reference, and a WORKFLOW section with headings. The example batch is illustrative and earned its place given the tool's complexity. It could be slightly tighter, but overall every section contributes to usability.

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 extensive operation schema and the presence of an output schema (per context signals), the description is reasonably complete. It covers key decision points (when to use this vs. update_doc_headers_footers, how to avoid index pitfalls) without repeating schema details. It doesn't enumerate all operation types, but the schema handles 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?

Schema description coverage is 100% for the three top-level parameters, so the baseline is 3. The description adds semantic guidance through concrete examples (e.g., using end_of_segment=true to avoid index math) and clarifies when operation types like create_header_footer should be used. This supplements the schema meaningfully.

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+resource: 'Executes multiple low-level document operations in a single atomic batch update.' It clearly distinguishes this from sibling tools by explicitly stating 'For normal header/footer text, prefer update_doc_headers_footers' and scoping create_header_footer to advanced section-break layouts.

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

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

It provides explicit when-to-use guidance with a named alternative: 'prefer update_doc_headers_footers' for normal headers/footers, and 'Only use create_header_footer here for advanced section-break layouts.' The recommended two-phase workflow (insert content with end_of_segment=true, then create headers/footers) gives clear operational 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds context about the primary use but does not disclose additional behavioral traits such as side effects, error handling, or atomicity. It does not contradict annotations, but adds limited transparency beyond what annotations and schema 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?

The description is two sentences, front-loaded with the core action, and every sentence adds value. It avoids verbosity and presents the scope of the tool efficiently.

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

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

Given the tool's complexity and rich schema, the description provides sufficient orientation: it names operations, states it is the primary update method, and aligns with annotations. It does not explain atomicity or failure modes, but the output schema and annotations cover much of the necessary context, making it reasonably 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 100%, with the 'requests' parameter listing supported request types in detail. The description mentions updating metadata and settings, but adds no extra meaning beyond the schema. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the tool's function: 'Apply batch updates to a Google Form.' It enumerates supported operations (adding, updating, deleting form items, metadata and settings) and explicitly distinguishes it as 'the primary method for modifying form content after creation,' differentiating it from sibling tools like create_form and get_form.

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 by stating this is the primary method for modifying an existing form, implying it should be used after creation. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

The annotations already indicate destructiveHint=true and readOnlyHint=false, and the description adds no additional behavioral context beyond 'apply batch updates.' It does not disclose effects, required permissions, or any implications of the destructive nature.

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 core purpose. There is no filler or repetition, making it efficient and appropriately sized.

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?

This is a complex tool with a free-form 'requests' array, yet the description provides no context on what constitutes a valid batch update request or how to construct one. The output schema exists, but the description still needs to explain the input domain sufficiently, which it does not.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema provides. The 'requests' parameter is described generically as 'List of update requests to apply', but no detail is given about valid request types or structure.

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 applies batch updates to a Google Slides presentation, using a specific verb and resource. It is distinct from sibling tools like get_presentation or create_presentation, though it doesn't explicitly differentiate itself from potential single-update alternatives.

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

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

No guidance is given about when to use this tool versus alternatives. The description merely states what it does, without mentioning prerequisites, exclusions, or contexts where other tools (e.g., batch_update_doc, import_to_google_slides) would be more appropriate.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the non-mutating nature is clear. The description adds the specific check behavior but does not disclose how it handles multiple files with the same name, whether it returns partial matches, or what 'public link sharing' precisely entails (e.g., 'Anyone with link'). This is some added context but not rich behavioral detail.

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

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

The description is a single concise sentence, front-loading the key action and result. No filler or redundant content. It is appropriately sized for a simple lookup tool.

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

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

The tool has an output schema (not shown) and high schema/annotation coverage, so describing return values is not obligatory. The description covers the primary scenario, but leaves minor ambiguities around search behavior (e.g., exact match, case sensitivity, multiple matches). Given the low complexity, 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 100%: each parameter has a description. The tool description does not add meaning beyond the schema; it simply echoes 'file name'. The drive_id parameter is well-documented in the schema, but the description doesn't clarify how it affects search results. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: it searches for a file by name and checks if public link sharing is enabled. This uses a specific verb ('searches', 'checks') and resource ('Drive file'), and is distinct from sibling tools like get_drive_file_permissions or get_drive_shareable_link.

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: use when you need to verify public link sharing on a named file. However, it does not provide explicit when-to-use vs alternatives, such as noting that get_drive_file_permissions provides broader permission details or that get_drive_shareable_link returns a link. No exclusions are mentioned.

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

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

Annotations already indicate a non-destructive write operation, and the description adds that the copy maintains all formatting and content. This provides useful behavioral context beyond annotations, though it does not discuss permissions or ownership.

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

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

The description is concise and front-loaded, with two sentences that state the core function and then add valuable context. No redundant or unnecessary wording.

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 tool's purpose, behavior, and result, complemented by a full schema and output schema. It is sufficient for understanding the tool, though it could mention prerequisites or side effects like permission inheritance.

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

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

Schema coverage is 100% with detailed parameter descriptions. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline but does not exceed it.

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 copy of an existing Google Drive file with an optional new name and location, using specific verbs and resources. It distinguishes itself from sibling tools like create_drive_file or update_drive_file by focusing on duplication.

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 for copying template documents but does not explicitly contrast with alternatives or state when not to use it. It lacks direct guidance on choosing this tool over siblings like create_drive_file.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds the 'secondary' scope, which offers some behavioral context. However, it does not disclose potential side effects, auth requirements, or error conditions, so the added value is modest.

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 conveying the essential purpose. There is no fluff or redundancy. It is well-structured and front-loaded.

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

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

For a simple create operation with a full input schema and an output schema, the description is adequate. It clarifies the calendar type ('secondary'), which is key contextual information. It does not explain the return value, but the output schema covers 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?

Schema coverage is 100%; every parameter has a clear description in the schema. The tool description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states the action ('Creates') and the resource ('a new secondary Google Calendar'). It distinguishes itself from sibling tools like list_calendars or manage_event by specifying 'secondary', 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or alternative tools. The context is completely absent beyond the basic action.

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?

Although annotations already indicate this is a write operation (readOnlyHint false), the description adds valuable behavioral context about the document body starting at index 1 and total length 2, which helps the agent understand the internal structure. It also mentions the optional content insertion but does not disclose side effects like authentication or rate limits, though these are less critical for a creation tool.

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

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

The description is well-structured with a clear topic sentence followed by technical details and a recommended workflow. It is slightly verbose due to the explicit indices and workflow steps, but every sentence contributes useful information, and the main purpose appears first. No redundant phrasing.

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

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

The description is highly complete for a creation tool: it states the primary function, optional content insertion, initial document structure, and a robust follow-up workflow (batch_update_doc + inspect_doc_structure). With an output schema present, it does not need to explain return values. The description covers both immediate constraints and recommended next steps, making it self-sufficient.

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

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

The input schema covers all parameters with descriptions (100% coverage), so the description does not need to elaborate on them. However, the description adds some context by explaining that content is 'optional initial plain text content' and gives structural details about how the document is initialized, but this is more about behavior than parameter semantics. Thus, a baseline of 3 is appropriate.

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

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

The description clearly states 'Creates a new Google Doc and optionally inserts initial content,' which is a specific verb+resource. It distinguishes from sibling tools like batch_update_doc, inspect_doc_structure, and get_doc_content by focusing on the creation action and its unique initial-state details.

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 provides a workflow: use create_doc for creation, then use batch_update_doc with insert_text and end_of_segment=true to append content, and finally inspect_doc_structure before formatting. This clearly guides the agent on when to use this tool versus alternatives and how to chain subsequent steps.

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 mutating, non-idempotent operation. The description adds valuable behavior beyond that: it stores the exact bytes without converting formats, and it may fetch content from a URL. It does not discuss failure modes, size limits, or parameter precedence, but the core behavioral traits are well disclosed.

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

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

Three efficient sentences, front-loaded with the primary action and scope, followed by input modes and the key non-conversion caveat plus routing to the sibling tool. 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 the rich 100%-covered schema and an output schema, the description provides enough high-level context for an agent to understand the tool's purpose and boundaries. A minor gap is that it does not specify what happens if multiple content sources (content, base64_content, fileUrl) are provided simultaneously.

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

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

Schema coverage is 100%, so the baseline is 3. The description groups content parameters into three modes ('direct text content, inline base64 bytes, or a fileUrl') but mostly restates what the schema already documents. It adds little parameter-specific detail beyond that conceptual grouping.

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

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

The description names a specific verb ('Creates') and resource ('a new file in Google Drive'), and adds clarifying scope: creation within shared drives and non-conversion to Google-native formats. It clearly distinguishes the tool from sibling import_to_google_* and Google-native creation 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 states that for Google-native conversion the agent should use the matching import_to_google_* tool, giving a clear when-not-to-use signal. It does not, however, give guidance on how to choose among the three content input methods (text, base64, fileUrl) for different 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds the shared drive support context, which is a useful behavioral nuance not captured by annotations. However, it does not disclose other potential traits such as permission requirements, error behavior, or whether the operation is reversible, so it offers limited additional transparency.

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 immediately conveys the action and object. It avoids redundancy and is appropriately front-loaded.

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

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

Given the simple create operation, the schema (which documents all parameters, including the parent_folder_id default and shared drive usage), and the presence of an output schema, the description is fairly complete. It adds the key contextual detail of shared drive support. A slight gap is the lack of explicit mention of default behavior in My Drive, but that is covered by the parent_folder_id default, so a 4 is justified.

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

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

Schema description coverage is 100%, so all three parameters (folder_name, parent_folder_id, user_google_email) are already documented. The tool description does not add any parameter-level detail beyond what the schema provides. Per the baseline for high schema coverage, a score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Creates a new folder in Google Drive.' The verb 'Creates' and resource 'folder' distinguish it from sibling tools like create_drive_file or create_doc. The added detail about supporting shared drives further specifies its scope.

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

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

No guidance is given on when to use this tool versus alternatives. The description does not mention any exclusions or alternative tools for creating files or documents. The only hint is 'supporting creation within shared drives,' but this does not constitute explicit usage direction.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the tool's mutation profile is known. The description adds that it creates a new form, which is more specific, but does not disclose side effects, required permissions, or any other behavioral nuance.

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

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

The description is one concise sentence with no unnecessary words, front-loaded with the core action and resource.

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 tool with full schema coverage and an output schema, the description is adequately complete. It could mention that the form is created in the user's Google account, but the required user_google_email parameter implies that without needing explicit explanation.

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

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

The input schema provides full descriptions for all four parameters, so the baseline is 3. The description adds a small note about the title being sourced from the request message, but does not meaningfully expand on the parameters beyond the schema.

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

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

The description clearly states the action ('Create') and resource ('a new form'), making it distinct from sibling tools like get_form or batch_update_form. However, the phrase 'using the title given in the provided form message in the request' is slightly ambiguous about the source of the title.

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 context such as authentication or ownership. The description only states what the tool does, not when or why to choose 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 convey that this is a write operation (readOnlyHint=false, idempotentHint=false). The description adds no extra behavioral context such as where the presentation is created, whether it creates a file in Google Drive, or any side effects. With no additional context, it does not go beyond what annotations already 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?

The description is a single, concise sentence that directly states the action and target. There is no unnecessary fluff or repetition. Every word adds value, 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?

For a simple tool with just two parameters, a complete schema, and an output schema, the description is largely sufficient. It could mention that created presentations are empty or saved to the user's Drive, but the current information combined with schema and annotations provides enough context for this straightforward 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?

The input schema fully describes both parameters (title and user_google_email) with 100% coverage. The description itself adds no parameter-specific meaning beyond the schema. This aligns with the baseline of 3 when the schema carries the load.

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

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

The description clearly states the verb 'Create' and the specific resource 'a new Google Slides presentation.' This distinguishes it from sibling tools like import_to_google_slides (which imports) and create_drive_file (which creates generic files). The purpose is unambiguous.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention when not to use it, prerequisites, or how it differs from related tools like import_to_google_slides. The description is purely definitional and offers no 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?

The description confirms the mutation ('Adds') and matches the readOnlyHint=false annotation. It adds some context by specifying the action's target, but does not disclose behavior such as duplicate handling, authentication requirements, or side-effect scope implied by openWorldHint=true.

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, direct sentence with no redundant words. It is appropriately front-loaded and easy to parse.

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

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

The tool is simple with three required parameters and an output schema, but the description lacks usage context and fails to explain user_google_email. This is adequate for basic selection but leaves gaps for correct invocation in all scenarios.

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

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

The schema documents message_id and emoji_unicode, but user_google_email has no description. The tool description adds no parameter information and does not compensate for the undocumented parameter, leaving a gap in the 67% 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 uses a specific verb ('Adds') and identifies the exact resource ('emoji reaction to a Google Chat message'). This clearly distinguishes the tool from sibling tools like send_message or search_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?

No guidance is provided on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer usage solely from the name and schema.

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

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

Annotations already indicate a write operation (readOnlyHint=false), and the description adds no new behavioral context beyond that. It does not disclose side effects, permission requirements, or what happens to existing resources, so it carries minimal additional value.

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

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

The description is a single, clear sentence with no wasted words. It is appropriately front-loaded and serves its purpose without unnecessary detail.

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

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

For a simple create operation with well-documented parameters and an output schema, the description is minimally viable. However, it lacks guidance on when to use it and any context about project creation behavior, such as where projects are stored or the significance of parent_id, making it incomplete for richer decision-making.

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?

All three parameters have descriptions in the schema (100% coverage), so the description adds no extra meaning. The baseline of 3 applies because the schema does the heavy lifting, and the description does not introduce any parameter-specific 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 'Creates a new Apps Script project' uses a specific verb and resource, clearly distinguishing it from sibling tools like delete_script_project, get_script_project, and list_script_projects. It leaves no ambiguity about the tool's core 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?

No guidance is provided on when to use this tool versus alternatives, nor any mention of prerequisites like authentication or choosing between Drive folder or bound container via parent_id. The description only states what it does, not when or how 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?

The description does not add significant behavioral context beyond what annotations already convey. It mentions the dual behavior (create vs duplicate) but does not disclose side effects, error conditions, or details about duplication (e.g., whether formatting is copied). The annotations already indicate a non-read-only operation, but the description fails to elaborate on important behavioral nuances.

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, but it is cluttered with an inline Python-style signature that disrupts readability. The action is front-loaded, but the parameter list is not well-integrated. It lacks clear structure and could be improved by separating the high-level behavior from parameter details.

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 has 5 parameters and no schema descriptions, the description is insufficiently complete. It does not explain how to use the parameters in practice, what happens when creating versus duplicating, or what the expected outcome is beyond the basic operation. The presence of an output schema does not compensate for the lack of behavioral and parameter context.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only lists parameter names and types inline (e.g., 'user_google_email: str'), without explaining their meaning or relationships. For instance, the roles of 'sheet_name' and 'source_sheet_name' are not explicitly defined, leaving the agent to infer their purposes from the tool description.

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

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

The description clearly states the tool's primary function: 'Creates a new sheet or duplicates an existing sheet.' This uses a specific verb and resource, and it distinguishes the tool from siblings like create_spreadsheet (which creates a new spreadsheet) by focusing on sheets within an existing spreadsheet.

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

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

No guidance is provided about when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions. The description is purely functional and lacks any contextual direction for an agent deciding between this and similar 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?

The description adds no behavioral information beyond what annotations already provide. It does not disclose any side effects, auth requirements, or details about what the created spreadsheet entails. Annotations indicate a write operation, which the description merely confirms.

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

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

The description is a single concise sentence with no fluff, but it is highly redundant with the tool name and title. It is structurally fine but lacks informative content.

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

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

For a simple create operation, the combination of schema, annotations, and output schema covers most needs. However, the description does not clarify how this differs from 'create_sheet' or what happens to the created spreadsheet (e.g., where it is stored).

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

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

The input schema provides 100% coverage with clear descriptions for all parameters. The description does not add any parameter-specific meaning, so the baseline of 3 applies.

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

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

The description clearly states the action (creates) and the resource (a new Google Spreadsheet). It is specific but does not distinguish from sibling tools like 'create_sheet' or 'import_to_google_sheets', so it lacks sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives. Sibling tools like 'create_sheet' and 'import_to_google_sheets' exist, but the description does not mention them or any 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 discloses critical behavioral constraints: index must come from inspect_doc_structure, table_data must be a 2D list of strings with uniform rows, use empty strings not None, and verify with debug_table_structure. These go beyond annotations (readOnlyHint false, etc.) and add context for correct invocation.

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 lengthy but structured with sections and headers. It front-loads the purpose and then gives essential steps. However, there is redundancy in repeating the inspect_doc_structure requirement multiple times, so it is not maximally concise, but still efficient for a complex tool.

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

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

For a 7-parameter tool with a mandatory prerequisite, the description covers the workflow, data format, and verification thoroughly. It does not need to explain return values as an output schema exists. This is essentially complete for a tool of this complexity.

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

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

Schema covers all parameters with descriptions, but the description enriches table_data with an explicit example and explains the index requirement in detail. It also clarifies empty cell handling. This adds value beyond the schema, so a 4 is appropriate.

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

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

The description opens with 'Creates a table and populates it with data in one reliable operation,' which clearly states the action (creates), resource (table), and scope (populates with data). This distinguishes it from sibling tools like append_table_rows or insert_doc_elements by focusing on table creation with data.

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 a mandatory workflow: always call inspect_doc_structure first, use total_length as index, format data as 2D list, then call this function. It also recommends debug_table_structure after creation. However, it does not explicitly state when not to use this tool versus alternatives, so it falls just short of a 5.

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

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

The description adds important behavioral nuance beyond the annotations: versions are immutable and cannot be modified after creation. This is disclosed clearly and complements the readOnlyHint=false annotation 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 only two sentences, front-loaded with the primary action, and each sentence adds value. No redundant or filler content.

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

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

With annotations indicating a non-read-only, non-destructive operation and an output schema present, the description fully conveys the core purpose and key immutable-snapshot constraint. It is sufficient for an agent to select and invoke 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 coverage is 100% with clear descriptions for script_id and user_google_email, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema.

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

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

The description states a specific action ('Creates a new immutable version') and resource ('script project'), clearly distinguishing it from sibling tools like get_version or list_versions. It also explains what a version is (a snapshot of current script code).

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 makes the use case clear: create an immutable snapshot of current script code. However, it does not explicitly mention alternatives or when not to use it, though the verb 'creates' naturally differentiates from get_version/list_versions.

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 safety profile is clear. The description adds that it is temporary and diagnostic, but doesn't detail what 'runtime/source information' includes or any constraints beyond that.

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

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

Two concise sentences with the verb and purpose front-loaded. Every word adds value, no repetition of schema data, and the structure 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?

The tool is simple (one param, output schema exists), and annotations cover safety. However, the unexplained parameter and lack of detail about the returned information make this minimally adequate rather than complete. The description does not fully compensate for the 0% schema coverage.

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

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

Schema description coverage is 0%, and the description does not mention the 'user_google_email' parameter at all. The agent is given no hint about why this email is needed or how it affects results, leaving a significant 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 returns runtime/source information with a specific diagnostic purpose (verifying code checkout for stale MCP instances). This distinguishes it from sibling tools, which are mostly about document, Gmail, or Drive 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?

Provides clear context: use for diagnosing stale MCP server instances. It doesn't mention exclusions or alternatives, but for a temporary diagnostic tool, the intended use case is sufficiently specific.

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. The description adds substantial context about what the tool reveals: exact dimensions, cell coordinates, current content, and insertion indices. It also explains how to read the output, going well beyond the structured annotation data.

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 long but well-structured with clear sections and bullet lists. It is front-loaded with the 'ESSENTIAL' tag and immediate use cases. While somewhat verbose, every section provides value for debugging scenarios.

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 moderate complexity, the description covers when to use it, what to expect in the output, and how to interpret that output. It also aligns with the output schema, making it a complete guide for the agent.

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

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

The input schema provides complete descriptions for all three parameters (100% coverage), including the meaning of table_index and user_google_email. The tool description does not add new parameter-level semantics beyond the schema, but the schema alone is sufficient.

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 this is a debugging tool for table structure, with concrete use cases like 'table not found' errors and mispopulated cells. It distinguishes itself from general inspection tools by focusing on table dimensions, positions, and insertion indices.

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 when-to-use scenarios ('USE THIS IMMEDIATELY WHEN:') and workflow integration steps. However, it does not mention when not to use it or explicitly compare against sibling tools like inspect_doc_structure, so it falls short of the highest score.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false. The description adds value by stating 'This permanently deletes the script project. The action cannot be undone,' reinforcing the irreversible nature beyond what annotations convey.

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

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

The description is concise and front-loaded: two sentences that state the action and add the critical permanence warning. Every word earns its place with no 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?

For a destructive tool with an output schema and annotations, the description covers the essential irreversible nature. It lacks usage guidance but is otherwise complete for a simple delete operation; a stronger description might explicitly warn to confirm the script ID.

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

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

Schema description coverage is 100%, with both parameters documented. The description adds no extra meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states 'Deletes an Apps Script project' with a specific verb and resource. It is unambiguous and distinguishes from sibling tools like get_script_project or update_script_content, as deletion is unique.

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

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

The description implies this tool is for permanently removing a script project, but provides no explicit guidance on when to use it versus alternatives, nor any caveats or prerequisites. It is adequate but lacks explicit contextual direction.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral details: it saves to local disk and returns either a file path (stdio) or a temporary URL valid for 1 hour (HTTP). This goes beyond the annotation defaults and clarifies the tool's side effects and result format.

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 main purpose, and then a concise breakdown of mode-specific returns. Every sentence adds value, and there is no extraneous 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 low complexity of the tool and the presence of an output schema, the description is complete: it explains the core action, mode-specific output, and the temporary URL validity. No further context is needed for an agent to invoke it correctly.

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

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

Schema description coverage is 67% (message_id and attachment_index are described, user_google_email is not). The description does not add details about parameter semantics beyond what the schema provides, so it doesn't compensate for the missing description of user_google_email. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Downloads an attachment from a Google Chat message and saves it to local disk.' This is a specific verb+resource+action, and it distinguishes this tool from siblings like get_gmail_attachment_content (Gmail) and get_drive_file_download_url (Drive) by explicitly mentioning Google Chat.

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 use (Google Chat attachments) and even explains mode-specific behavior (stdio vs HTTP). It doesn't explicitly name alternatives or exclusion criteria, but the context is sufficiently clear given the many sibling workspace 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 readOnlyHint=false, so the mutating nature is known. The description adds useful behavioral context: drafts can be new or replies, attachments are supported, and alias addresses can be used via Send As. 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 two sentences with no filler. It front-loads the core purpose and then covers the two most important behavioral variants: reply drafts and Send As support.

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

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

For a tool with 15 parameters, the description is brief but the schema and output schema carry most of the detail. It could explicitly mention that the message is not sent and that send_gmail_message should be used for sending, but the current description is still sufficient for an agent to understand the tool's role.

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

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

Schema description coverage is 100%, and the schema already contains rich detail for parameters like attachments, from_email, thread_id, and in_reply_to. The tool description itself adds little per-parameter meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool creates a draft email in the user's Gmail account, which is a specific verb and resource. It also distinguishes itself from the sibling send_gmail_message by emphasizing 'draft' and explicitly mentions new drafts, reply drafts, and attachments.

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 usage context: it is for drafts, supports replies, and supports Send As aliases. It does not explicitly name send_gmail_message as the alternative for sending immediately, but the draft-vs-send distinction is strongly implied.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true. The description adds valuable context by specifying that the tool saves the PDF to Google Drive, clarifying the side effect location. It does not mention overwrite behavior or auth limitations, but the core side effect is disclosed.

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

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

The description is a single, well-structured sentence that immediately conveys the tool's function. No wasted words 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 tool is simple, the schema covers all four parameters with descriptions, and an output schema exists. The description adequately explains the core operation without needing to detail optional parameters or return values.

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

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

Schema description coverage is 100%, so the schema already fully documents each parameter. The description does not add extra semantics beyond what the schema provides, which is acceptable given the high 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 a specific verb and resource: 'Exports a Google Doc to PDF format and saves it to Google Drive.' This distinguishes it from sibling tools that read or create docs, as it uniquely mentions PDF conversion and Drive 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?

No guidance is provided on when to use this tool versus alternatives like get_drive_file_download_url or other export methods. There is no mention of prerequisites, exclusions, or preferred 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutating nature is known. The description adds useful context by explaining that it requires no index calculation, making it the 'safest way' for targeted updates. It also indicates the replacement happens 'throughout' the document, implying all occurrences. It does not explicitly mention side effects like replacement counts, but this is not required given the output schema exists.

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

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

The description is well-structured: a lead sentence states the core function, followed by a bulleted list of use cases, and a closing note about an alternative tool. Every sentence earns its place and the length is appropriate for the tool's clarity. It could be slightly tighter, but it remains concise and scannable.

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 the 100% param coverage, the description provides sufficient context for a Google Doc find-and-replace operation. It covers the core behavior, when to use it, and an alternative for building documents from scratch. It does not mention edge cases like what happens if find_text is absent, but the output schema likely conveys that, making the description reasonably 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 100% schema description coverage, the baseline is 3. The description adds semantic value by providing a concrete example: replacing placeholder text like '{{TITLE}}'. This helps an agent understand that find_text can be a template variable and replace_text its substitution, enriching the parameter meaning beyond the schema's simple 'Text to search for' and 'Text to replace with'.

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

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

The description opens with 'Finds and replaces text throughout a Google Doc,' which clearly states the verb, resource, and scope. It further distinguishes itself from siblings by highlighting 'No index calculation required' and explicitly contrasts with batch_update_doc for building documents. This makes the purpose unmistakable and differentiated.

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 use cases: replacing placeholders, updating specific words/phrases, and making targeted changes without index errors. It also states when not to use it (building documents from scratch) and recommends an alternative approach involving batch_update_doc. This is exactly the kind of when-to-use guidance expected.

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 some behavior details beyond annotations, such as hex color format and Sheets number format types, and the default sheet selection. However, it does not disclose whether formatting merges with existing formatting or replaces it, nor any side effects or error behavior. The annotations already indicate non-readonly and non-destructive, and the description does not contradict them.

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 concise sentences, front-loaded with the primary purpose, then elaborating with relevant parameter constraints. No redundant content, filler, or unnecessary details. Every sentence earns its place.

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

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

For a tool with 13 parameters and annotations, the description covers the main purpose, key value format constraints, and default behavior. It does not need to explain return values due to the presence of an output schema. A minor gap is not stating the effect on existing formatting, but overall it provides adequate context for selection and usage.

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

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

With 100% schema coverage, the schema already documents each parameter. The description enriches understanding by clarifying acceptable color formats (#RRGGBB), providing examples of number format types, and explaining the default sheet behavior for ranges without a sheet name. This adds value beyond the schema's brief 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 identifies the tool's function with a specific verb ('Applies formatting') and enumerates the types of formatting (colors, number formats, wrapping, alignment, styling), distinguishing it from sibling tools like modify_sheet_values or read_sheet_values. It also adds a useful default behavior note, making the tool's scope 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 implies usage for formatting ranges but does not explicitly state when to use it over alternatives, mention exclusions, or reference sibling tools. The only contextual note is the default first-sheet behavior, which is more of a parameter detail than usage guidance. It provides some operational context but lacks explicit when/when-not guidance.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable context about the Apps Script API limitation, enhancing transparency beyond the structured hints. 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 two concise sentences, front-loaded with the core purpose and no unnecessary words. It efficiently conveys the tool's function and important contextual constraint.

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

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

The description covers the key limitation and purpose, and the output schema exists to explain return values. It could be slightly more complete by hinting at next steps or code format, but it is sufficient given the available structured metadata.

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

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

Schema description coverage is 100%, with detailed parameter descriptions for trigger_type, schedule, and function_name. The tool description itself adds no parameter-level detail, but the schema fully compensates, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool 'Generates Apps Script code for creating triggers' with a specific verb and resource. It also explains the API limitation, which helps distinguish it from other script management tools.

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

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

The description provides clear context on when to use this tool (when you need trigger creation code) by explaining that the API cannot create triggers directly. However, it does not explicitly name alternative tools or state 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context beyond stating it gets information, which aligns with annotations but does not provide additional details like potential errors or required 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?

The description is a single, concise sentence that delivers the core purpose without any filler or redundancy. It is well-structured and front-loaded.

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

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

For a simple read-only getter with a full output schema and 100% parameter coverage, the description is sufficiently complete. It might benefit from mentioning that the contact must be retrieved via a prior list/search, but that is not essential given the tool's straightforward nature.

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

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

Schema description coverage is 100%, with both parameters (contact_id and user_google_email) having explicit descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description 'Get detailed information about a specific contact' clearly states the tool's verb and resource, and distinguishes it from list/search siblings by emphasizing 'specific contact.' However, it does not explicitly mention that the contact is identified by an ID, leaving a minor gap in precision.

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 you have a specific contact in mind, which is a clear context, but it does not provide explicit when-to-use vs. alternatives like search_contacts or list_contacts. No exclusions or alternative suggestions are given.

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

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

The description is consistent with the readOnlyHint and idempotentHint annotations, and adds that members are included in the result. However, it does not describe error behavior (e.g., unknown group_id) or any other operational details beyond the annotations and schema, so it offers minimal additional transparency.

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 is front-loaded with the verb and clearly states the tool's scope. There is no redundant or filler content, 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 the rich annotations (readOnly, idempotent, non-destructive), a fully described input schema, and the presence of an output schema, the description adequately covers what is needed for a simple read operation. The only missing element is explicit usage differentiation from siblings, but this is a minor gap for such a straightforward 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?

All three parameters are fully described in the input schema with explicit descriptions (e.g., group_id: 'The contact group ID.', max_members: 'Maximum number of members to return (default: 100, max: 1000).', user_google_email: 'The user's Google email address. Required.'). The tool description adds no parameter-specific meaning beyond the schema, so it meets the baseline but does not exceed it.

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

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

The description states the tool's verb and resource specifically: 'Get details of a specific contact group including its members.' It clearly distinguishes from siblings like list_contact_groups, which likely only lists groups without member details, and manage_contact_group for modifications.

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 you need details of a single contact group, but it does not explicitly contrast with alternatives such as list_contact_groups for enumeration or search_contacts. No when-to-use or when-not-to-use guidance is provided beyond the verb 'Get'.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context about how comments are handled (default included, anchor text preserved, comment_mode options) and which formatting elements are preserved. It does not contradict 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 well-structured into three concise paragraphs: purpose, differentiation, and comment behavior. Each sentence earns its place with no redundancy, making it easy to parse.

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 read-only nature confirmed by annotations and the presence of an output schema, the description is complete. It covers the tool's core behavior, differentiation from similar tools, and comment handling. There are no significant 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 100% schema description coverage, the baseline is 3. The description adds meaning by explaining the effect of comment-related parameters, such as the default behavior of including comments and preserving anchor text. This helps the agent understand the purpose of include_comments and comment_mode beyond their 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 the tool's function: 'Reads a Google Doc and returns it as clean Markdown with optional comment context.' It uses a specific verb and resource, and explicitly differentiates from sibling get_doc_content by noting it returns plain text while this preserves formatting.

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 usage guidance by contrasting with get_doc_content: 'Unlike get_doc_content which returns plain text, this tool preserves document formatting as Markdown.' This tells the agent when to choose this tool over the alternative, and the comment context section clarifies behavior around comments.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds limited extra behavioral context. It explains the use of Docs API vs Drive API for different file types, which is useful, but does not disclose other important behaviors like output format or potential 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 concise and well-structured, with a clear opening statement followed by two bullet points that efficiently summarize the two retrieval paths. There is no redundant wording or unnecessary detail.

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

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

For a read-only tool with output schema and rich annotations, the description is mostly complete. It adequately explains the two file-type scenarios, though it could mention limitations or explicitly guide users to alternatives, which is a minor gap.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal meaning beyond the schema, mainly mentioning the document_id role, but does not elaborate on parameter formats or usage nuances.

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 retrieves content from Google Docs or Drive files, using specific verbs and resources. It distinguishes between native Google Docs and Office files, but does not explicitly differentiate from sibling tools like get_drive_file_content or get_doc_as_markdown.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions. The handling of different file types is implied by the description, but no direct comparison to sibling tools is given.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses meaningful behavioral traits: native docs are exported as text/CSV, Office files are unzipped, PDFs may fall back to a download hint for scanned images, images return base64 with MIME metadata, and other binaries are handled with UTF-8 detection. This adds significant context.

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

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

The description is concise and well-structured: a single purpose sentence followed by bullet points for each file-type behavior. Each bullet contributes unique information with no redundancy or filler, making it easy to scan.

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

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

Given the read-only annotations and the presence of an output schema, the description covers the necessary context: shared drives, format-specific extraction, fallbacks, and binary handling. It does not explain errors or auth, but those are already covered by annotations and the user_google_email parameter. The coverage is strong, though not exhaustive.

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

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

The input schema already provides clear descriptions for both params (file_id and user_google_email) with 100% coverage. The description adds no additional parameter semantics beyond the phrase 'by ID', which duplicates schema information. Baseline 3 is appropriate.

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

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

The description clearly states 'Retrieves the content of a specific Google Drive file by ID' and then details format-specific behaviors, making the purpose unambiguous. It distinguishes itself from download-URL or search siblings by focusing on content extraction.

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

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

Usage is implied by the description (i.e., use when you need file content), but no explicit alternatives or when-not-to-use guidance is provided. For example, it does not mention get_drive_file_download_url as the alternative for when a URL is sufficient. This falls into 'implied usage' rather than clear, explicit 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 (readOnly, idempotent, non-destructive), the description discloses key behaviors: saving to local disk, temporary URL validity in HTTP mode, and format conversion rules for Google native files. This exceeds what annotations provide and sets clear expectations for side effects and return values.

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 well-structured with a clear main statement, mode-specific details, and a bulleted list for format conversions. Every sentence serves a purpose without redundancy, making it concise yet 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?

The description fully covers the tool's behavior across modes, file types, and export formats. It explains return values (local path vs URL) and edge cases like native file conversion, making it complete for an agent to select and invoke the tool correctly without needing additional context.

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

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

Schema coverage is 100%, but the description adds value by explaining export format mappings per file type (e.g., Docs to PDF/DOCX, Sheets to XLSX/PDF/CSV). This enriches the parameter semantics beyond the schema's plain option list.

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 downloads a Google Drive file and saves it to local disk, using a specific verb and resource. It distinguishes from siblings like get_drive_file_content or get_drive_shareable_link by focusing on the download behavior and local file access.

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 usage context, explaining mode-specific behavior (stdio vs HTTP) and export format options. It does not explicitly name alternatives or exclusions, but the context makes it obvious when to use this tool for downloading files rather than just reading or sharing 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 the tool as read-only, idempotent, and non-destructive. The description adds value by specifying exactly what metadata categories are returned (permissions, parent folder IDs, ownership, lifecycle timestamps), which goes beyond the annotation flags.

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, information-dense sentence that lists the key metadata categories without any filler. It is efficiently front-loaded with the action and resource.

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

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

For a read-only metadata lookup with a rich output schema and comprehensive annotations, the description sufficiently communicates the tool's purpose and return scope. It could mention error conditions or permission requirements, but these are not critical given the output schema and safety annotations.

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

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

Both parameters are fully described in the input schema with clear purposes (file_id and user_google_email). The description itself does not add any parameter-specific details, so it relies on the schema's complete 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 uses a specific verb ('Gets') and resource ('Google Drive file'), and enumerates concrete metadata categories: sharing permissions, parent folder IDs, ownership, and lifecycle timestamps. This clearly differentiates it from sibling tools like get_drive_file_content or get_drive_file_download_url.

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 a caller needs comprehensive file metadata, but it does not explicitly state when to prefer this tool over related siblings such as check_drive_file_public_access or get_drive_shareable_link. No exclusions or alternative guidance is provided.

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

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

The description is consistent with the annotations (readOnlyHint, idempotentHint, destructiveHint) and does not contradict them. However, it adds no additional behavioral context beyond the annotations, such as authentication requirements or error conditions, which are not critical given the simple read-only nature.

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 clearly conveys the tool's purpose with no unnecessary words. It is appropriately front-loaded and every word earns its place.

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

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

For a simple read-only tool with fully documented parameters and an output schema, the description is sufficient. It covers the resource type (file or folder) and the action, and the existing structured data handles the remaining details.

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

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

The input schema has 100% coverage with both parameters (file_id and user_google_email) already described in detail. The tool description adds no new semantic information about the parameters, so it does not enhance what the schema already provides.

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

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

The description clearly states the tool 'Gets the shareable link for a Google Drive file or folder.' It uses a specific verb ('gets') and resource ('shareable link'), distinguishing it from sibling tools like get_drive_file_download_url or get_drive_file_content that serve different purposes.

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 use when a shareable link is needed, but provides no explicit guidance on when to use this tool versus alternatives such as get_drive_file_download_url or get_drive_file_permissions. It lacks exclusions or references to alternative tools, making the usage context clear but not differentiated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate those. The description adds useful behavioral context about the three major retrieval modes. It does not disclose details like rate limits or default response shape, but those gaps are minor given the strong annotations and output schema.

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

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

Three short sentences with no filler. The main purpose is front-loaded, and each sentence adds a distinct retrieval mode. It is concise without sacrificing the key decision points for an agent.

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

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

For a tool with 10 parameters, the description is appropriately high-level, with the heavy detail carried by the input schema and output schema. It covers all major entry points: ID lookup, time range, and keyword search. It does not explicitly mention defaults like 'primary' calendar or the detailed flag, but those are fully documented in the schema, so no critical context is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions the optional query parameter and the ID/time-range distinction, but all parameter-level meaning is already thoroughly documented in the input schema. The description adds little beyond a high-level framing of the parameters.

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

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

States a specific verb and resource: 'Retrieves events from a specified Google Calendar.' It then clearly enumerates the three retrieval modes—by ID, by time range, and by keyword—which distinguishes this read tool from siblings like manage_event or list_calendars. An agent can understand what the tool does without opening the schema.

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

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

Provides clear context by describing the supported use cases: single event retrieval, time-range retrieval, and keyword search. It does not explicitly name alternatives or state when not to use it, but the read-only semantics and retrieval modes make intended usage obvious relative to sibling write tools like manage_event.

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

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

The annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already establish the safety profile, but the description adds no additional behavioral context such as what exactly is returned, potential errors, or authorization requirements beyond what the schema states. The description is neutral but does not enhance transparency.

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, but it is under-specified rather than concise. It fails to provide necessary context or details, making it inadequate for an AI agent to understand the tool's purpose and usage.

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 rich annotations, a fully described schema, and an output schema, the description is minimally adequate. However, it lacks any contextual details about what 'form' refers to or how it fits with related tools, so it is 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 100%, with both form_id and user_google_email having descriptions. The tool description adds no parameter-related information, but since the schema fully documents the parameters, the baseline of 3 is appropriate.

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

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

The description 'Get a form.' simply restates the tool name without adding any specific detail about what the form retrieval entails. It lacks information on what a 'form' is in this context (e.g., Google Form structure, settings) and does not explicitly distinguish from sibling tools like get_form_response, making it nearly tautological.

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 or how it compares to alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent without information about appropriate usage 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?

Annotations already declare readOnlyHint, destructiveHint=false, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds no extra behavioral context, such as error behavior or return format, but it also does not contradict 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 a single, concise sentence: 'Get one response from the form.' It is front-loaded, immediately conveys the purpose, and contains 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?

For a simple read-only getter with a full output schema and rich annotations, the description is adequate but not fully complete. It does not mention the necessity of a response_id (though the schema covers it) or provide any context about what a response contains, but given the tool's simplicity, the missing details are minor.

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

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

Schema description coverage is 100%, so the parameters are well-documented in the schema. The description does not add any additional parameter-level information, so it meets the baseline but does not exceed it.

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 'Get one response from the form' clearly identifies the action (get) and resource (form response), with the scope 'one' distinguishing it from listing all responses (e.g., list_form_responses). It is 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention that it requires a response_id or that list_form_responses should be used for multiple responses. The usage context is left entirely to inference from the schema.

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

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

The description adds meaningful behavioral context beyond the annotations: it saves to disk, returns a temporary URL valid for 1 hour in HTTP mode, and may re-fetch message metadata. Annotations provide limited safety info (readOnlyHint=false), so the description carries the burden of explaining side effects and output behavior, which it does effectively.

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

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

The description is concise and well-structured: it opens with the main action, then breaks down output modes in two clear sentences, and ends with a relevant behavioral caveat. Every sentence adds distinct value, with no redundancy or filler.

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

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

Given that an output schema exists and the input schema is thorough, the description provides the essential extra context: mode-specific outputs, time validity, and side effects. It does not explain error cases or prerequisites, but these are not critical given the tool's moderate complexity and the schema richness.

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

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

Schema description coverage is 100%, with detailed descriptions for all four parameters including return_base64. The tool description itself does not add parameter-level information, but since the schema fully documents each parameter, the baseline of 3 is appropriate—the schema does the heavy lifting.

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

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

The description clearly states the tool's action with a specific verb ('Downloads') and resource ('email attachment'), and further specifies it saves to local disk. This distinguishes it from siblings like get_gmail_message_content by focusing on attachment content, and the mode-specific output details reinforce its unique purpose.

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

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

The description gives clear context on when to use the tool by explaining its behavior in stdio and HTTP modes, which helps select it for attachment downloads. It does not explicitly name alternatives or exclusions, but the context is sufficient for most scenarios without needing explicit 'when-not-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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds substantial behavioral detail: 20,000-character truncation, export-to-disk with a short-lived download URL or file path, and stateless inline fallback. These details help the agent anticipate response size and transport behavior, going well 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 tightly written paragraphs: a one-sentence purpose statement, a concise explanation of truncation and full=True behavior, and a short note on stateless deployments. Every sentence contributes new information and is front-loaded with the most important details.

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 strong annotations, complete input schema with 100% parameter coverage, and presence of an output schema, the description covers all key operational edge cases: truncation, full=True behavior, transport differences, and stateless mode. It is fully sufficient for reliable tool invocation.

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

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

Schema description coverage is 100%, and the schema itself has rich parameter descriptions. The tool description adds extra value by explaining the 20,000-character truncation threshold and the rationale that large messages never stream through model context, which complements the schema's full=True description.

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

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

The description opens with 'Retrieves the full content (subject, sender, recipients, body) of a specific Gmail message,' using a specific verb and clearly identifying the resource and scope. The 'specific' qualifier distinguishes it from sibling batch/thread/attachment 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 gives clear context on when to use full=True (large messages, byte-exact fidelity) and when the default truncated inline body is used. It does not explicitly name sibling alternatives or state when not to use this tool, so it lacks explicit exclusion guidance but is otherwise clear.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the 25-message limit and the rationale ('to prevent SSL connection exhaustion'), which is behavioral context beyond the annotations and schema.

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

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

Two sentences, front-loaded with the core purpose, and every word earns its place. The second sentence explains a practical constraint without verbosity.

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

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

The tool is straightforward, with full schema coverage and an output schema available. The description covers batch size and rationale, and the sibling list includes the singular variant, making the context clear. It doesn't discuss error handling or partial failures, but that's not critical for a read-only batch retriever.

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

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

Schema description coverage is 100%, with clear descriptions for all four parameters. The description does not add any parameter-specific detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the tool retrieves content of multiple Gmail messages in a single batch request. The verb 'retrieves' with the resource 'Gmail messages' and the scope 'batch' distinctly differentiate it from the singular get_gmail_message_content sibling.

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

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

It provides the key context of batching up to 25 messages per request, which guides when to use this tool over the singular version. However, it does not explicitly say 'use this for multiple messages instead of single fetch' or name the alternative, so it falls short of explicit exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context about return shape (string by default, dict when include_analysis=True) and clarifies that the default preserves the existing string return shape, which is beyond annotation data.

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: the first clearly states the core purpose, the second explains an optional feature and its benefit. No redundant wording, well-front-loaded, every sentence earns its place.

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

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

Given that an output schema exists and annotations are rich, the description covers the essential aspects: thread retrieval, all messages, optional analysis, and default return shape. It is sufficiently complete for an agent to understand the tool's functionality without ambiguity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description enriches the include_analysis parameter by explaining the structured ownership analysis (last sender, ball-in-court verdict), which is not fully captured in the schema. It also clarifies body_format behavior via the schema, and the description adds value by describing the default return shape.

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

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

The description states the tool retrieves complete Gmail thread content including all messages, using a specific verb and resource. It distinguishes from sibling tools like get_gmail_message_content by focusing on the whole thread, and mentions optional structured ownership analysis as an added feature.

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 when to use this tool (to retrieve full thread content) and hints at a reason to prefer it over alternatives: by enabling include_analysis, callers avoid re-parsing or making a second call. It does not explicitly name sibling alternatives, but the guidance is useful.

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

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

With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds valuable context beyond these: the batch limit of 25 threads and the rationale (SSL connection exhaustion). The parameter description also notes automatic batching in chunks of 25, which is additional behavioral detail. 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 exactly two sentences, both front-loaded and free of filler. The first sentence delivers the core purpose, the second provides a key constraint. Every word earns its place, making it an exemplary concise description.

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

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

Given the output schema exists, annotations cover safety, and schema descriptions cover all parameters, the description only needs to convey the tool's unique value and constraints. It does that well by highlighting batch retrieval and the 25-thread limit. It could mention alternatives for full completeness, but the existing information is sufficient for an agent to select and invoke 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 100%, so the baseline is 3. The description itself does not add parameter-level semantics beyond what the schema provides. The schema already contains detailed explanations for thread_ids (batching) and body_format (text/html/raw), so no compensation is needed. The description adds no extra value here.

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

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

The description clearly states the specific verb and resource: 'Retrieves the content of multiple Gmail threads in a single batch request.' This distinguishes it from sibling tools like get_gmail_thread_content (single thread) and get_gmail_messages_content_batch (messages, not threads) by focusing on 'multiple threads' and 'batch'. The addition of the 25-thread limit further clarifies its scope.

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

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

The description implies usage for fetching multiple threads at once and provides a rationale ('to prevent SSL connection exhaustion'). However, it does not explicitly name alternatives or state when not to use this tool, though the name and context make batch usage clear. Given the existence of a sibling for single threads, a brief 'for a single thread, use get_gmail_thread_content' would have made it a 5.

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

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

The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds no behavioral context beyond the basic retrieval action. It does not mention filtering, ordering, pagination, or any limits, nor does it contradict 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 a single, efficient sentence with no filler or repetition. It front-loads the verb and object.

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

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

For a tool with 5 parameters and a sibling search_messages, this description is too sparse to support selection and correct invocation. The presence of an output schema helps with return values, but the description fails to explain filtering capabilities, pagination defaults, or how this differs from related message retrieval tools.

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