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

Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds useful behavioral context by specifying that rows are appended to the end of the table body and that the table range automatically extends. This clarifies the exact side effect without contradicting 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 short, front-loaded with the core action, and every sentence contributes: one defines the operation and behavior, the other provides the essential prerequisite. There is no redundant or filler content.

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

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

For a simple append operation, the description is complete: it covers what the tool does, the side effect on the table range, and the required discovery step for table_id. The output schema handles return-value expectations, and annotations handle the safety profile, so no critical guidance 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 schema fully documents all four parameters. The description only reinforces that table_id comes from list_sheet_tables, which is already stated in the schema's table_id description, so it adds no significant new meaning.

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

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

The description states a specific verb and resource: 'Appends rows to a structured table in a Google Sheet.' It also explains the distinctive behavior—rows are added to the end of the table body and the range is automatically extended—which clearly separates it from plain spreadsheet writers like modify_sheet_values or table 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 gives a concrete prerequisite: 'Use list_sheet_tables first to find the table ID,' which tells the agent the required preceding step. It does not explicitly discuss when not to use this tool or name alternatives, so it stops short of full 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?

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 cover destructiveness and read-only status, so the bar is lower. The description adds valuable behavioral context: the update is atomic, and building documents in phases with end_of_segment=true avoids index-calculation errors. It does not over-explain side effects beyond what the annotations already signal.

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-organized with a front-loaded core statement, a clear alternative callout, and a structured two-phase workflow. It is slightly redundant by repeating the update_doc_headers_footers guidance in both the opening and Phase 2, but the extra context about auto-creation and advanced layouts 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 complex tool with a large operation schema and an output schema, the description covers the high-risk workflow decisions—atomicity, phase ordering, and header/footer routing. It does not enumerate all operation types, but the schema handles those details. It is complete enough for an agent to select the tool and invoke it correctly in the most common 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful operational guidance on the operations parameter: a concrete example batch, the recommendation to use end_of_segment=true during content insertion, and the warning about index math. This clarifies how to structure the array beyond the raw 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 verb and resource: 'Executes multiple low-level document operations in a single atomic batch update.' It clearly identifies the tool's role and distinguishes it from alternatives like update_doc_headers_footers by telling agents when that sibling is preferred.

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

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

The description gives explicit when-to-use guidance: prefer update_doc_headers_footers for normal header/footer text, and only use create_header_footer here for advanced section-break layouts. It also provides a phased workflow with concrete instructions to avoid index calculation errors, which goes well beyond vague 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 mark this tool as destructive and non-read-only; the description adds useful context by specifying that deleting form items, updating metadata, and changing settings are all possible. It does not contradict the annotations and gives the agent a clearer picture of side effects.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence adds value. The supported-operation summary is compact and avoids redundant detail already present in the schema.

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

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

For a mutation tool with destructive annotations and a 100%-covered schema, the description is largely complete. It could mention execution semantics such as request ordering, atomicity, or auth prerequisites, but the existing annotations and schema cover the main safety and parameter needs.

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

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

Schema coverage is 100%, so the input schema already documents form_id, user_google_email, and the supported request types inside the requests parameter. The description summarizes the same operations but does not add meaning beyond what the schema already provides.

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

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

The description states a specific verb and resource: 'Apply batch updates to a Google Form.' It enumerates the supported operations and adds 'primary method for modifying form content after creation,' which clearly separates it from create_form, get_form, and set_publish_settings among the siblings.

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

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

The description provides clear context: use this tool after form creation to modify content, metadata, or settings. It does not explicitly name alternatives or state when not to use it, but the 'primary method' phrasing and scope are enough to orient an agent.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. However, the description adds no behavioral detail beyond that: it does not mention atomicity, partial failure, irreversible changes, or what kinds of modifications can be applied.

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

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

The description is a single front-loaded sentence with no filler. It is efficient and clear, though slightly under-specified for the complexity of the operation.

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

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

This is a destructive, open-ended batch operation with an unstructured requests array, but the description is only one generic sentence. It leaves out valid request categories, failure semantics, and usage context. The presence of an output schema covers return values, not operational guidance.

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

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

The schema already provides 100% parameter coverage, so the bar for the description is lower. The description adds no parameter-level context beyond the schema, and the open-ended 'requests' array in particular would benefit from an example or explanation of the expected 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 clearly states the action ('apply batch updates') and the resource ('Google Slides presentation'), which is enough to differentiate it from read/create tools like get_presentation and create_presentation, and from the Docs/Forms batch update siblings by resource. It does not enumerate update types or scope, so it falls just short of a 5.

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

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

No guidance is given about when to use this tool versus alternatives such as create_presentation, get_presentation, or batch_update_doc. An agent must infer from the name and sibling list that this is the choice for batch-mutating an existing Slides presentation.

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 the safety profile. The description adds that the search is performed by file name rather than ID, but it does not disclose additional behavioral nuance such as what counts as 'public link sharing', how the user email is used, or whether only the first match is evaluated. No contradiction with annotations 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 a single, front-loaded sentence with no filler. It communicates the essential action and outcome immediately, and every word contributes to the tool's purpose.

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

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

Given the strong annotations, 100% schema coverage, and the presence of an output schema, the description covers the core intent well. The only notable gap is the potential ambiguity around what exactly qualifies as 'public link sharing' and whether the tool returns a simple boolean or detailed sharing information, but the output schema likely addresses the return format.

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%, including a notably detailed explanation of the drive_id parameter and its effect on the underlying files.list call. The description itself adds no new parameter-level meaning beyond restating that the tool searches by file name and inspects public link sharing, so 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 states a specific verb and resource: 'Searches for a file by name and checks if it has public link sharing enabled.' This clearly distinguishes it from siblings like get_drive_file_permissions or get_drive_shareable_link, since the focus is specifically on detecting public link sharing rather than listing permissions or retrieving links.

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

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

The description implies the usage context: use this tool when you need to verify whether a file is publicly shareable via link. However, it does not explicitly state when not to use it or name alternatives such as get_drive_file_permissions or get_drive_shareable_link, leaving the routing decision to the agent's inference.

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

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

Annotations already cover the safety profile (non-read-only, non-idempotent, non-destructive), so the bar is lower. The description adds useful context — the copy 'maintains all formatting and content from the original' and can be placed in a new location — but omits copy-specific behavioral caveats such as whether sharing settings or permissions are inherited by the copy, which agents often need for Drive operations. 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?

Three compact sentences with the core purpose front-loaded in the first. The third sentence earns its place by adding the fidelity guarantee (formatting and content preserved), while the second is largely redundant with the first plus the schema — a minor flaw, not a structural problem.

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

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

The output schema and 100% parameter coverage give the agent a complete input contract, and annotations cover mutability and safety, so return values need no explanation. What is missing are copy-specific caveats that matter for correct invocation: whether permissions are inherited by the copy, whether a copied native Google file stays in its original format, and the access required on the source file.

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 schema already documents file_id, new_name including the 'Copy of [original name]' default, parent_folder_id defaulting to root, and user_google_email. The description restates 'new location' and 'optional new name' at a high level but adds no meaning beyond what the schema's parameter descriptions already provide.

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 first sentence names a specific verb+resource: 'Creates a copy of an existing Google Drive file,' which clearly separates it from creation tools like create_drive_file. However, it never explicitly names a sibling it is NOT, and the second sentence's reference to 'the template document' slightly muddies whether this operates on one specific template or on any arbitrary Drive file.

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 sentence tells an agent when to choose this tool versus alternatives such as create_drive_file (blank new file), import_to_google_doc (converting imports), update_drive_file (editing an existing file), or get_drive_file_content (reading). Among roughly 100 sibling tools, the only routing signal is the word 'copy' itself, which is definitional rather than actual usage 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 this as a non-read-only, non-idempotent, non-destructive external write, and the description aligns with those hints. The description adds no extra behavioral context such as duplicate-calendar side effects or permission requirements, but the structured annotations carry enough of that burden to make the gap moderate rather than severe.

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 short sentence with no filler, starts with the operative verb, and states the core resource and scope immediately. Every word earns its place, and nothing is redundant with the tool name or title.

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

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

For a simple scalar-parameter create operation with full schema coverage and an output schema, this description is nearly sufficient for correct invocation. The main missing elements are usage context and side-effect nuance, but those are partly addressed by annotations and do not block an agent from calling 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?

The schema documents all four parameters with descriptions and defaults, so the 100% schema coverage means the description does not need to compensate. The description adds no parameter-specific nuance, so the schema-driven 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 names a specific action ('Creates') and a specific resource ('a new secondary Google Calendar'), which clearly distinguishes it from list_calendars or event-management tools. The word 'secondary' adds important scope by indicating this tool does not create or modify the primary calendar.

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

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

The description gives no guidance on when to use this tool versus alternatives such as list_calendars or manage_event. It also does not mention prerequisites like Google authentication or any exclusions beyond the word 'secondary', leaving the agent to infer usage context from the tool name and sibling list.

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

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

The description goes beyond annotations by revealing important internal details: the body starts at index 1, a new empty doc has total length 2 with a section break at index 0 and newline at index 1. This is exactly the kind of behavioral context that helps an agent understand side effects and subsequent index calculations. 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 mostly concise and front-loaded with the primary purpose. It includes useful operational details, though the inner-document index explanation could be tightened slightly. Overall, every sentence earns its place and no filler exists.

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

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

Given that the tool has an output schema, fully described parameters, and annotations, the description provides complete context for correct invocation. It covers creation behavior, initial content limitations, and a clear follow-up workflow. Nothing critical is missing for an agent to use the tool effectively.

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 does not add significant parameter-specific semantics beyond what the schema already documents. It does clarify that the content parameter is for initial plain text and that rich content should be built with batch_update_doc, but this is contextual rather than parameter-specific.

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

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

The description opens with a specific verb and resource: 'Creates a new Google Doc and optionally inserts initial content.' This clearly states the tool's function and differentiates it from siblings like import_to_google_doc and create_drive_file by explicitly focusing on creating a Google Doc from scratch.

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 workflow guidance: after creation, use batch_update_doc with insert_text operations and end_of_segment=true, then inspect_doc_structure before formatting. It does not explicitly compare create_doc with alternative creation tools like import_to_google_doc, but the post-creation workflow is strong enough to guide an agent on when and how to proceed.

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 convey the key behavioral traits: non-read-only, non-idempotent, non-destructive, open-world. The description confirms the mutating creation behavior and adds shared-drive support as extra context. It does not detail auth requirements or side effects, but the annotation coverage lowers the burden.

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

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

The description is a single, front-loaded sentence that states the core action first and adds the shared-drive qualifier without redundancy. It contains no filler and does not repeat schema or annotation 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 straightforward create operation, the description, schema, and annotations together give an agent enough to invoke the tool correctly: required parameters are documented, safety traits are annotated, and an output schema exists. Minor details like permission prerequisites are unstated but are not essential for basic selection and 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%, so the schema already documents all parameters. The description's shared-drive mention aligns with and echoes the existing parent_folder_id schema note rather than adding materially new parameter meaning.

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

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

The description states a specific verb and resource: 'Creates a new folder in Google Drive.' It clearly distinguishes from siblings like create_drive_file by limiting the action to folders, and it adds the meaningful shared-drive capability without ambiguity.

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 the tool: creating folders in Google Drive, including within shared drives. It does not explicitly name alternatives or exclusions, but the resource type is unambiguous enough that an agent can route to this tool for folder creation versus file creation.

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

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

Annotations already establish that this is a mutating, non-idempotent operation, so the bar is lower. The description adds a small behavioral detail about the title coming from 'the provided form message,' but it doesn't clarify side effects, authentication needs, or the created form's lifecycle.

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

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

The description is a single, front-loaded sentence with no filler. However, the phrasing 'using the title given in the provided form message in the request' is roundabout and slightly hurts clarity, preventing a top score.

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 creation tool, the full schema, annotations, and output schema carry much of the burden. The description is mostly sufficient, but it leaves a gap around when to use create_form versus form-update tools, and it never clarifies what 'provided form message' means.

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 input schema already fully documents the parameters. The description adds no meaningful parameter semantics beyond the schema, and the phrase 'title given in the provided form message' could even create confusion about the source of the title parameter.

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

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

The description states a specific action and resource ('Create a new form'), and the word 'new' distinguishes it from update/get form siblings. The tail clause about 'provided form message' is ambiguous, but the core purpose is still clear.

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

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

The description gives no guidance about when to use this tool versus alternatives like batch_update_form, get_form, or set_publish_settings. It also doesn't mention prerequisites such as completing authentication or requiring an authenticated Google account.

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, so the description does not need to cover those basics. It adds only 'new' to indicate a fresh resource is created, but provides no details on return values, side effects, or relationship to Google Drive. However, since an output schema exists and there is no contradiction with annotations, a mid-range score is appropriate.

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

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

The description is a single sentence that conveys the essential action without filler. Every word earns its place, and the key verb and resource are 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 two-parameter create tool with full schema coverage, an output schema, and meaningful annotations, the one-sentence description is largely sufficient. It lacks only occasional context such as that the resulting presentation will be stored in Google Drive, but this is not critical given the schema and annotations.

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

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

Schema description coverage is 100%: both user_google_email and title have adequate schema descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is correct.

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

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

The description states a specific verb ('Create') and resource ('a new Google Slides presentation'), making the core purpose clear. It does not explicitly differentiate from the sibling import_to_google_slides, which also results in a Slides presentation, so it falls short of full sibling distinction.

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

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

The description gives no guidance on when to use this tool versus alternatives such as import_to_google_slides or create_drive_file. There is no mention of prerequisites, when a new blank presentation is appropriate, or when another sibling would be a better choice.

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

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation, and the description aligns with that. However, the description adds no extra behavioral context beyond the core action, such as the reaction being publicly visible to space members, duplicate-reaction behavior, or any authorization requirements. It is adequate but not informative 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 a single sentence that immediately states the action and target. Every word contributes value and there is no filler or repetition of the title.

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

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

The tool is simple and an output schema exists, so the description does not need to cover return values. However, the required user_google_email parameter is left ambiguous in both the schema and the description, and no usage context (e.g., acting as a specific user or needing space membership) is provided. The description is minimally viable but has clear gaps.

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

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

The schema describes message_id and emoji_unicode, but user_google_email has no schema description. The tool description does not explain any parameters or compensate for the undocumented required field. Since schema coverage is only 67% and the description adds no param-level meaning, the agent is left to guess the role of user_google_email.

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

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

The description states a specific verb ('Adds') with a specific resource ('emoji reaction') and target ('Google Chat message'). It is immediately clear what the tool does and it distinguishes itself from all sibling tools, none of which mention reactions.

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: the tool is for adding an emoji reaction to a Chat message. No sibling tool performs this action, so no exclusions or alternatives need to be named. It falls short of a 5 only because it does not explicitly state when not to use it or mention related Chat 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 this is a mutating, non-idempotent operation, so the safety profile is covered. The description adds that this creates a new project rather than modifying an existing one, which is useful but minimal. It does not disclose details such as whether the project is created in Drive, what happens if a project with the same title exists, or whether any additional resources are implicitly created. No contradiction with annotations 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 a single sentence with no wasted words, making it easy to parse and front-loaded with the key verb and noun. It is appropriately concise for a simple creation tool, though it could have used the brief format to add a bit more context without becoming verbose.

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

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

Given the output schema and annotations, the description covers the basic action but lacks context about the project lifecycle, the role of parent_id, and the need for prior Google authentication. The sibling list hints at a script-project management workflow, but the description does not explicitly connect this tool to that workflow. It is minimally viable but leaves the agent to discover important surrounding context elsewhere.

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

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

Schema description coverage is 100%, so the schema already documents all parameters, including title, parent_id, and user_google_email. The description adds no additional meaning about these parameters or their relationships. This is the expected baseline case where the schema carries the parameter documentation burden.

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

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

The description uses a specific verb and resource: 'Creates a new Apps Script project.' It clearly distinguishes this from sibling tools like list_script_projects, get_script_project, update_script_content, and delete_script_project by focusing on creation. It does not state the broader context of what an Apps Script project is, but the core purpose is unambiguous.

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

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

There is no guidance about when to use this tool versus alternatives, such as when to use create_script_project instead of create_drive_file or update_script_content. The description does not mention prerequisites like prior authentication or the relationship to other script-management tools. Agents are left to infer usage from the tool name and sibling list.

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

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds the key behavioral fact that it can either create a blank sheet or duplicate an existing sheet, which goes beyond the annotations. It does not describe side effects, copy behavior, naming conflicts, or permission requirements.

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

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

The description is one dense, front-loaded sentence followed by a compact signature. There is no filler, though the signature partially duplicates information already present in the schema.

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

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

For a tool with five parameters and zero schema descriptions, the description is adequate but lean: it states the core operation and lists all parameters, and an output schema exists so return values need not be described. Missing context includes when each optional parameter applies, how duplication differs from creating a blank sheet, and how this tool differs from create_spreadsheet.

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

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

The description includes the full function signature, which helps identify all five parameters and their optionality, and the phrase 'duplicates an existing sheet' gives meaning to source_sheet_name. This partially compensates for the 0% schema description coverage, but there are no per-parameter explanations such as how insert_sheet_index behaves or the relationship between sheet_name and source_sheet_name.

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

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

The description states a clear action and resource: it creates a new sheet or duplicates an existing one, which is specific and not a tautology. It does not explicitly distinguish itself from the sibling create_spreadsheet, but the use of 'sheet' and the spreadsheet_id parameter make the target resource reasonably clear.

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

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

The intended use case is implied by the phrasing: use this tool when a new sheet tab or a duplicate of an existing sheet is needed. However, there is no explicit guidance about when to prefer create_spreadsheet instead, nor any exclusions or alternative routing.

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

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

Annotations already indicate that this is a mutating operation (readOnlyHint=false) and non-destructive (destructiveHint=false), and the description does not contradict them. The description adds the domain context that the created resource is a Google Spreadsheet, but it does not disclose side effects like Drive file creation, default sharing, or permission implications. This is acceptable given the annotations but lacks deeper 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 one short, direct sentence that front-loads the core action and resource. Every word earns its place, and there is no redundant or filler content. For a simple creation tool, this is appropriately concise.

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

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

The input schema and output schema cover the technical details, so the description does not need to explain return values or parameter formats. However, given the large sibling toolset, the description lacks enough context to help an agent decide between 'create_spreadsheet' and related tools like 'create_sheet' or 'import_to_google_sheets'. It is minimally viable but incomplete for tool selection.

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

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

Schema description coverage is 100%, so the parameters 'title', 'sheet_names', and 'user_google_email' are already well documented in the schema. The description adds no additional parameter-level meaning, which is acceptable because the schema carries the full burden. This aligns with the baseline 3 for fully documented schemas.

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

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

The description clearly states the action ('Creates') and the resource ('a new Google Spreadsheet'), so an agent can understand the core purpose. However, it does not differentiate from the sibling tool 'create_sheet', which could be confused as creating a spreadsheet rather than a worksheet within one. A more explicit distinction would earn a 5.

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

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

There is no guidance about when to use this tool versus alternatives such as 'create_sheet', 'create_drive_file', or 'import_to_google_sheets'. The description gives no context about prerequisites, ownership implications, or which sibling tools are more appropriate in specific 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 mark readOnlyHint=false and destructiveHint=false, so the mutation behavior is established. The description adds valuable behavioral context: it creates and populates a table in one operation, requires an index from inspect_doc_structure, enforces a 2D string-only format, and recommends debug_table_structure for verification. 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 well-organized into sections and clearly front-loads the critical inspect_doc_structure call, but it is repetitive: the same index requirement is emphasized in the workflow, the critical requirements, and the schema parameter description. The all-caps warnings add urgency but also length without adding much 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 tool with 7 parameters and an output schema, the description covers the essential invocation context: the mandatory prior call, how to derive the index, the exact table_data structure, and a post-verification step. It does not need to explain return values because an output schema exists, and the remaining schema fields like tab_id, header_rows, and bold_headers are already described in the input schema.

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

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

Schema coverage is 100%, so the schema already documents every parameter. The description adds meaningful semantics beyond the schema by showing the exact 2D array format with a header row example, requiring equal-length rows, and explicitly stating that empty strings should be used instead of None. This compensates for any ambiguity in the bare schema types.

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 opening line states a specific verb and resource: 'Creates a table and populates it with data in one reliable operation.' This is clear and distinct from the generic tool name, though it does not explicitly contrast with sibling tools like insert_doc_elements or create_sheet.

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 an explicit mandatory workflow: call inspect_doc_structure first, use the returned total_length as the index, format data as a 2D list, and verify with debug_table_structure. It clearly states when to invoke this tool and the required precondition, though it does not discuss when not to use it or name an alternative.

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

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

Annotations already establish this is a mutating (readOnlyHint=false), non-idempotent operation. The description adds genuinely useful behavioral context beyond annotations: versions are immutable snapshots, and 'Once created, versions cannot be modified' warns the agent of a permanent consequence. This is consistent with idempotentHint=false and destructiveHint=false, with no 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?

Three tight sentences with zero waste: the core action is front-loaded, the second sentence explains what a version is, and the third states the critical constraint. Every sentence earns its place and no information is repeated from the schema or annotations.

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 an output schema exists (so return values need no explanation) and annotations cover the safety profile, the description adequately conveys the semantics and the immutable nature of the created artifact. A minor gap is the absence of guidance on prerequisites or sequencing relative to update_script_content, but nothing essential blocks correct invocation.

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

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

Schema description coverage is 100%, so all three parameters (script_id, description, user_google_email) are already documented structurally. The description adds minimal param-specific meaning beyond reinforcing that the snapshot captures 'current script code' for the given script project. Baseline 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 opens with a specific verb-resource pair ('Creates a new immutable version of a script project') and adds the key attribute 'immutable'. This clearly distinguishes it from siblings like list_versions, get_version, create_script_project, and update_script_content, so an agent can tell them apart without inspecting schemas.

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

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

The description implies the use case — 'Versions capture a snapshot of the current script code' suggests you call this when you want to freeze the current code state. However, it never explicitly names alternatives or states when not to use it (e.g., when you need to modify code first via update_script_content, or when you simply want to view versions via 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 establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat that. It adds useful context beyond annotations by marking the tool as temporary and diagnostic, clarifying that it inspects runtime/source state rather than user 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 tightly written sentences with no filler. The main action and diagnostic purpose are front-loaded, and the temporary nature is stated concisely in the second sentence.

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

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

For a simple one-parameter tool with a rich output schema and strong annotations, the description covers what the tool does and when to use it. The only notable gap is the unexplained parameter semantics, which is partially mitigated by the clear parameter name.

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

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

Schema description coverage is 0%, so the description needed to explain the required `user_google_email` parameter but does not. The parameter name is somewhat self-explanatory, but the description does not clarify whose email is expected or how it is used for diagnosis.

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

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

The description states a specific verb and resource: 'Return runtime/source information' and 'verify which code checkout the running MCP server has loaded.' It clearly distinguishes itself as a temporary diagnostic tool among the many operational Google Workspace sibling tools.

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

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

The description explicitly identifies the use case: 'diagnosing stale MCP server instances' and verifies which code checkout is loaded. It gives clear context for when to use the tool, though it does not name alternatives or exclusions, which are largely unnecessary given its unique diagnostic role.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive; the description adds valuable behavioral detail by specifying exactly what the output contains and how to interpret fields like dimensions, position, current_content, and insertion_index. It also makes clear the tool inspects rather than mutates, with no contradiction to 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 long but well-structured with bolded trigger conditions, output explanations, and workflow steps that are easy to scan. Each section conveys actionable guidance, though some repetition of the tool's core purpose could be trimmed.

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 when to use the tool, how to read its output, and how it fits into a workflow, while the output schema handles the return structure. One minor gap: it references 'populate_existing_table' as a scenario, but that tool does not appear in the sibling tool list, creating slight routing 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?

The input schema already documents all three parameters with helpful descriptions and a default for table_index. The description does not add parameter-specific guidance beyond what the schema provides, so the baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool debugs table structure and enumerates what it reveals: dimensions, cell positions, current content, insertion indices, and boundaries. It is unambiguous about the resource and purpose, though it does not explicitly contrast with sibling inspection tools like inspect_doc_structure or create_table_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 an explicit 'USE THIS IMMEDIATELY WHEN' list and a workflow integration section covering after creation, before population, and after failures. It lacks an explicit when-not-to-use section or named alternative tools, so it stops short of a 5.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds valuable behavioral context by stating 'This permanently deletes the script project. The action cannot be undone.' This reinforces the irreversibility in a way the annotations do not fully convey. No contradiction 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 two short sentences, with the core action first and the critical permanent-deletion warning second. Every sentence earns its place, and there is no filler or redundant 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 two-parameter destructive tool with output schema, annotations, and full schema coverage, the description covers the essential irreversible nature of the operation. It is slightly incomplete because it does not mention when deletion should be used or what happens to related resources, but these are largely covered by the annotations and clear purpose.

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 script_id and user_google_email already documented in the input schema. The description adds no additional parameter-level meaning, but it does not need to because the schema covers the parameters adequately. 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 states a specific verb and resource: 'Deletes an Apps Script project.' It further clarifies that the deletion is permanent, which clearly distinguishes this destructive tool from sibling tools like list_script_projects, get_script_project, create_script_project, and update_script_content.

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

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

The description gives no guidance about when to use this tool versus alternatives, when deletion is appropriate, or what prerequisites apply. It only restates the action itself and its irreversibility. There is no explicit or implicit comparison to sibling tools.

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

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

Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) are consistent with the description, so no contradiction. The description adds genuine value beyond annotations: it discloses the side effect of writing to local disk and the mode-dependent return semantics (local path in stdio vs temporary URL with a 1-hour expiry in HTTP), which the annotations do not 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?

Two compact sentences carry all essential information with no filler. The core function is front-loaded in the first sentence, and the mode-specific details occupy the second. Every clause earns its place.

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

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

The output schema exists to cover return values, and annotations cover the safety profile, lowering the burden on the description. The mode-specific behavior disclosure is a meaningful addition. Remaining gaps are the undocumented required user_google_email parameter and lack of error-behavior guidance (e.g., out-of-range attachment_index or messages with no attachments), but these are minor given the structured 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 coverage is 67%, and the two documented parameters (message_id with a concrete example, attachment_index with default semantics) are well described. However, the required parameter user_google_email has zero documentation in both the schema and the description, and the description does nothing to compensate for this gap. With one required param unexplained, the agent cannot confidently construct valid calls.

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 first sentence states a specific verb ('Downloads'), resource ('attachment from a Google Chat message'), and outcome ('saves it to local disk'). It clearly distinguishes this from sibling tools like get_gmail_attachment_content (Gmail domain) and get_drive_file_download_url (URL only, not a download) by explicitly scoping to 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 operational context by explaining stdio vs HTTP mode return behavior, which helps the agent know what to do with the result. However, it never explicitly states when to use this tool versus similar alternatives such as get_gmail_attachment_content or get_drive_file_download_url; the routing is left to inference from the Chat domain in the name and description.

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 mark the tool as a non-destructive mutation (readOnlyHint=false, destructiveHint=false), and the description adds the critical behavioral caveat that no send-time parameter exists and drafts cannot be placed in the Scheduled folder. It also discloses Send As behavior and reply-draft capability, though it does not explicitly state that no email is sent until a separate send action.

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 purpose is front-loaded in the first sentence, and the scheduled-send warning is important enough to justify its length. However, the warning paragraph repeats the same limitation in several ways ('no send-time parameter', 'web-UI only', 'cannot be placed in the Scheduled folder'), so it is slightly less tight than it could be.

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 15-parameter tool, the schema and output schema carry the detailed semantics, and the description covers the non-obvious scheduling limitation and the correct alternate workflow. An agent selecting this tool has everything it needs to avoid the scheduled-send misconception.

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

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

Schema coverage is 100% and every parameter, including the attachment object shape and body_format enum, is documented there. The description only repeats the existence of attachments and Send As, adding little parameter-level meaning beyond the schema. 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 first sentence states a specific verb ('Creates'), a resource ('draft email in the user's Gmail account'), and the tool's core output. It also names reply drafts, attachments, and Send As, and the scheduling section explicitly points to send_gmail_message as the sending counterpart, so an agent can distinguish it from sibling tools.

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

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

It explicitly warns that scheduled send is not available and tells agents not to claim a message was scheduled. It then gives the correct workflow: draft now, then use an external scheduler with send_gmail_message or users.drafts.send, or let the user schedule in the Gmail UI. This is clear when-to-use and 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 signal a non-read-only, non-idempotent, non-destructive operation. The description adds that the result is saved to Google Drive, which clarifies the output location, but it does not disclose prerequisites, permission requirements, or duplicate/overwrite behavior. This is acceptable but not rich.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes: the action, the source format, the target format, and the destination are all included 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?

For a relatively simple conversion tool, the description, full parameter schema, annotations, and existing output schema provide enough information for an agent to call it correctly. It is slightly incomplete only in not addressing edge cases like file naming defaults or authorization context, but those are covered elsewhere or are non-essential.

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 describes all four parameters with 100% coverage. The description does not add parameter-level meaning beyond aligning document_id with the source doc and folder_id with the Drive destination, 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 states a specific verb ('Exports') and resource ('Google Doc to PDF format'), and also notes the output destination ('saves it to Google Drive'). This is distinguishable from siblings such as get_doc_as_markdown or copy_drive_file, none of which perform PDF conversion.

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

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

Usage is implied: use this when you need a PDF version of a Google Doc saved to Drive. However, the description provides no explicit when-to-use guidance, no exclusions, and does not name alternatives such as get_doc_as_markdown or get_drive_file_download_url.

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 destructiveHint=true and idempotentHint=false, so the safety burden is partially carried there. The description adds useful context that replacement happens 'throughout' the document and frames it as the 'safest way' to avoid index errors. It does not contradict the annotations, and no annotation contradiction is present.

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

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

The description is front-loaded with the core behavior and then provides a clear, scannable bullet list of use cases. It is slightly repetitive with 'safest way' and 'without risk of index errors,' but overall each section earns its place and the structure supports quick understanding.

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

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

Given that an output schema exists and parameter coverage is complete, the description provides enough context for an agent to select and invoke the tool correctly. It covers scope, use cases, and a relevant alternative workflow. It could be more complete by explicitly noting that all occurrences are replaced or by naming index-based sibling tools, but these are gaps rather than blockers.

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 input schema already documents all six parameters. The description adds context around placeholder replacement and content updating, which helps illustrate find_text and replace_text usage, but does not substantially deepen the meaning of individual 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 opens with a specific verb and resource: 'Finds and replaces text throughout a Google Doc.' It also adds a distinctive behavioral claim, 'No index calculation required,' which differentiates it from index-based document editing tools. The use-case bullets reinforce what the tool is for.

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

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

The description gives explicit when-to-use scenarios: replacing placeholders, updating words or phrases, and making targeted changes without index errors. It also names an alternative workflow using batch_update_doc for building documents from scratch. However, it does not explicitly contrast itself with sibling tools like modify_doc_text when index-based edits are needed.

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

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

Annotations establish that the tool mutates state but is not destructive. The description adds meaningful behavior beyond the schema: colors must be hex strings, number formats follow Sheets types, and an unspecified sheet means the first sheet is used. It does not mention whether existing formatting is overwritten, but the destructiveHint already frames the tool as non-destructive.

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

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

The description is three sentences with no filler. It front-loads the core purpose, then provides concrete syntax guidance and a default-behavior note, all of which earn their 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 13 parameters, complete schema coverage, an output schema, and annotations, the description provides the essential operating rules without needing to restate every parameter. It could be slightly more explicit about overriding existing formatting, but nothing critical is missing for an agent to call this 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, but the description adds cross-cutting value by explaining the accepted format for colors, the Sheets-specific number format types, and the fallback behavior when range_name omits a sheet name. These details are not fully captured by the schema's per-parameter 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 opens with a clear active verb and resource: 'Applies formatting to a range,' then enumerates the kinds of formatting covered. This makes it distinct from value-editing spreadsheet siblings like modify_sheet_values or read_sheet_values.

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 usage context is implied by the formatting-specific vocabulary, but the description never explicitly says when to choose this tool over alternatives such as modify_sheet_values or manage_conditional_formatting. It adds a useful default-sheet note but no 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about the API limitation and the code-generation nature of the tool, but does not go beyond that into further behavioral details such as output format or side effects.

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

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

The description is brief, front-loaded with the core purpose, and every sentence adds value. The constraint explanation is essential context and is presented in two compact sentences without redundancy.

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

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

Given the tool's moderate complexity, the rich input schema, and the presence of an output schema, the description is complete enough. It explains the key contextual constraint (API cannot directly create triggers) and the tool's role without needing to restate structured 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?

Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description does not add parameter-level meaning, meeting the baseline for a fully documented 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 uses a specific verb ('Generates') and identifies the exact resource ('Apps Script code for creating triggers'). It clearly distinguishes what the tool does from siblings by focusing on code generation rather than direct trigger creation or script management.

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

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

The description explains when this tool is needed: because the Apps Script API cannot create triggers directly and they must be created from within Apps Script itself. This provides clear context for when to use the tool, though it does not explicitly name alternative tools or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context, such as authentication needs or error behavior, 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 that immediately states the action and resource. Every word earns its place, and there is no redundant or filler content.

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

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

For a simple read tool, the combination of a complete input schema, a true output schema, and safety annotations covers most of what an agent needs. The description is minimal but sufficient, though it does not mention how to obtain the contact_id (e.g., via list_contacts).

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

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

Schema description coverage is 100%, so both parameters are already well-documented in the input schema. The description does not add additional semantic meaning beyond the implicit 'specific contact' reference, which aligns with contact_id.

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

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

The description 'Get detailed information about a specific contact' clearly identifies a read operation for a single contact, using a specific verb and resource. It is distinct from sibling tools like list_contacts or search_contacts because it targets a specific contact, though it does not explicitly name any sibling.

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

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

The phrase 'a specific contact' implies this tool should be used when a contact_id is already known, providing minimal usage context. However, it does not mention alternatives or conditions for choosing between get_contact, search_contacts, or list_contacts, so the guidance is only implied rather than explicit.

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

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

Annotations already disclose read-only, idempotent, and non-destructive behavior, so the description does not need to repeat safety traits. It adds the useful detail that members are returned, but it does not describe pagination limits or other behavioral nuances beyond what the schema already conveys.

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 filler. It is appropriately sized for a simple read operation and front-loads the key idea.

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

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

The tool is simple, has full schema coverage, a rich set of annotations, and an output schema, so the description is largely sufficient. The only minor gap is the absence of explicit guidance about how this differs from list_group_members.

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 description needs to add little about parameters. The description does not elaborate on group_id, max_members, or user_google_email, but the schema already documents these fully.

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 ('Get details') and the resource ('a specific contact group'), and it explicitly calls out that members are included. This distinguishes it from list_contact_groups and list_group_members in the sibling set, making the tool's purpose unambiguous.

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

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

The description implies that this tool is for retrieving a single group by ID, especially with required 'group_id', but it does not explicitly say when to choose this over list_contact_groups or list_group_members. No exclusions or alternatives are mentioned.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds valuable behavioral detail beyond that: Markdown constructs preserved, comments included by default, and anchor text retained for comment context. There is no contradiction with 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?

Three focused paragraphs: core function, sibling differentiation, and comment behavior. Each sentence earns its place and the most important information is front-loaded.

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

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

For a read-only tool with rich schema descriptions, an output schema, and safety annotations, the description supplies the missing high-level context: Markdown conversion, differentiation from get_doc_content, and comment anchoring. Nothing needed for correct invocation is missing.

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

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

The input schema already has 100% description coverage with detailed parameter docs, so the baseline is 3. The description adds meaningful context about comment anchoring and default comment inclusion, though it appropriately leaves tab/suggestion-mode specifics to the schema.

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

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

The description opens with a specific verb ('Reads'), a clear resource ('Google Doc'), and a concrete output ('clean Markdown'), and immediately distinguishes itself from get_doc_content's plain-text output. An agent can identify what this tool does and which sibling it complements 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?

It explicitly names get_doc_content as the alternative and contrasts plain text vs. Markdown, giving a clear selection criterion. The comment-context sentence further clarifies a distinctive use case for this tool over the plain-text sibling.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior, and the description adds substantial behavioral detail beyond that: API routing for native docs vs. Drive files, U+FFFC placeholders for non-text elements, the start-at-index-1 convention, and the table/tab alignment caveat. This gives an agent strong predictive knowledge about the output contract.

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 purpose is front-loaded, followed by structured bullets, and every sentence earns its place by documenting indexing, placeholders, offsets, and limitations. The length is proportionate to the genuine complexity of the tool's contract, with no filler.

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

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

For a read operation with strong annotations and an existing output schema, the description covers all non-obvious aspects: native vs. Office file handling, exact index mapping, tab and table separators, and the limitation that alignment holds only up to the first table or tab header. No essential calling information is missing.

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

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

The input schema covers all four parameters at 100% coverage, so the schema carries most parameter semantics. The description adds useful context that document_id can refer to either a native Google Doc or a Drive file, but it does not elaborate meaningfully on tab_id or suggestions_view_mode 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 opens with a precise verb-resource pair: 'Retrieves content of a Google Doc or a Drive file (like .docx) identified by document_id.' It further distinguishes native Docs content via the Docs API from Office files via the Drive API, making the tool's scope unambiguous even among many doc-related siblings.

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

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

The description gives clear usage context by explaining the index-aligned output and explicitly stating that offsets can be passed straight to format_text or delete_text. It does not explicitly name alternatives such as get_doc_as_markdown or get_drive_file_content, so it stops short of full when-to-use-versus-alternatives 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 provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral detail beyond them: per-format export/parsing strategies, PDF fallback behavior, base64/MIME for images, and a binary-note fallback for unknown file types. This is rich disclosure of how the tool behaves in various scenarios.

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 well-structured: a single lead sentence followed by a scannable bullet list where each item covers a distinct file category. No sentence is wasted, and the most important usage information (retrieves content by ID, supports shared drives) is front-loaded.

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

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

The tool has an output schema, so return-value details are already structured. The description covers all likely input file types, fallback behaviors, and edge cases such as binary files, making it sufficient for an agent to understand what will happen for any file. Combined with the annotations and schema, the description is contextually 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?

Input schema coverage is 100% and both parameters already have reasonable descriptions. The tool description adds little beyond the schema: it mentions 'by ID' and the fact that shared drives are supported, but it does not deepen the meaning of user_google_email or provide guidance on acquiring a file_id. This matches the baseline of 3 for high 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 opens with a precise verb+resource statement: 'Retrieves the content of a specific Google Drive file by ID,' which clearly defines what the tool does. The bulletized format-specific breakdown further distinguishes it from related siblings like get_drive_file_download_url or get_doc_content by showing it returns extracted text/content rather than a URL or a Docs-specific artifact.

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

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

The description clearly implies when to use the tool: whenever you need the content of a Google Drive file, including shared drives. However, it never explicitly names alternatives such as get_drive_file_download_url or get_doc_content, nor does it state when to prefer one over the other; the guidance is inferred from the format-handling bullets rather than stated.

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

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

Beyond the readOnly/idempotent annotations, the description discloses mode-dependent return behavior, the 1-hour URL validity, and the per-file-type export rules. It clearly explains what happens for Google native files versus other files, which is exactly the kind of context an agent needs.

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

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

The description is organized with a clear opening sentence followed by concise mode and format bullets. Every sentence adds necessary behavioral or usage detail, with no filler or repeated schema 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?

Given the tool's complexity, the description covers all essential call-time decisions: mode behavior, native-file export mapping, default formats, and the fact that original formats are used for non-native files. An output schema exists for return values, and annotations cover the safety profile, so nothing critical 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 coverage is 100%, so the baseline is 3. The description adds value by mapping export_format values to specific source file types (Docs, Sheets, Slides) and clarifying defaults per type, which the schema only partially conveys. This pushes it above baseline without fully re-explaining parameters like file_id and user_google_email.

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 immediately states a specific action and resource: 'Downloads a Google Drive file and saves it to local disk.' It then distinguishes its behavior by mode and file type, making it clearly different from siblings like get_drive_file_content 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 gives clear context for when different behaviors apply: stdio mode returns a local path, HTTP mode returns a temporary URL, and file type determines export formats. It does not explicitly name alternative tools or exclusion conditions, but the provided mode and format guidance is enough for an agent to decide when to use this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what metadata categories are returned, but it does not disclose any additional behavioral traits such as auth requirements or rate limits. No contradiction 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 a single, focused sentence that front-loads the action and resource, then lists relevant metadata categories. There is no filler or 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?

This is a low-complexity, read-only tool with only two documented parameters, rich annotations, and an output schema. The description sufficiently covers what the agent needs to know to select and invoke it correctly. Additional sibling differentiation would improve it, but that gap is already captured in the usage dimension.

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

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

Schema description coverage is 100% and both parameters (file_id, user_google_email) are already documented clearly in the schema. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Gets') with a clear resource ('detailed metadata about a Google Drive file') and enumerates concrete content categories: sharing permissions, parent folder IDs, ownership, and lifecycle timestamps. This distinguishes it from siblings like set_drive_file_permissions, which perform writes, and check_drive_file_public_access, which is narrowly scoped.

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

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

No explicit guidance is given about when to use this tool versus related siblings such as check_drive_file_public_access, get_drive_shareable_link, or manage_drive_access. The usage context is only implied by the description, with no exclusions or alternative routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds no extra behavioral context beyond the read-only nature already implied by 'Gets' and the annotations, such as whether an existing link is returned or whether additional sharing state is involved.

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

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

A single, front-loaded sentence states the exact operation and object with no filler. Every word earns its place, and it is appropriately short for a simple read tool.

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

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

Given the low complexity, two fully documented parameters, rich annotations, and an available output schema, nothing essential is missing. The description adequately orients an agent toward correct invocation without needing to restate structured information.

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 already fully documented. The description adds no additional meaning beyond what file_id and user_google_email already convey, so it meets but does not exceed the baseline.

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

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

The description uses a specific verb ('Gets') with a specific resource ('the shareable link') and explicitly scopes it to 'a Google Drive file or folder.' This distinguishes it from sibling tools like get_drive_file_download_url and get_drive_file_content without needing to open schemas.

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

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

The intended use is implied: use when you need the shareable link for a Drive item. However, there is no explicit guidance on when to choose this over alternatives such as get_drive_file_download_url or get_drive_file_permissions, and no mention of prerequisites or exclusions.

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

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

The annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description does not need to repeat that. The description adds useful behavioral context about the different retrieval modes, though it does not disclose pagination or response behavior beyond what the schema and output 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 three sentences with no filler, front-loads the core action, and then efficiently covers the main retrieval modes. 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 an 11-parameter tool, the description is concise but sufficient because the schema covers every parameter and an output schema exists. It does not need to enumerate all parameters or return details; the main decision-relevant information (single vs. range vs. keyword search) is present.

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

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

The input schema has 100% description coverage with rich per-parameter details, so the description's mention of the 'query' param adds little beyond the schema. The baseline of 3 applies because the schema carries the heavy lifting and the description does not contradict or meaningfully extend 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 a specific action ('Retrieves events') and a specific resource ('a specified Google Calendar'), and further clarifies the retrieval modes (single event by ID, multiple events by time range, keyword search). This makes it clearly distinguishable from sibling tools like query_freebusy or manage_event.

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 the tool is appropriate: retrieving a single event by ID, events within a time range, or events matching a keyword. It does not explicitly name alternatives or exclusions, but it implies the correct scope without being misleading.

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 disclose readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. However, it also adds no behavioral context such as authentication requirements, scope of the returned form, or relationship to Google user email.

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

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

The description is extremely short, but this reads as under-specification rather than effective conciseness. It contains only a restatement of the tool name and provides no useful elaboration.

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

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

The schema covers parameters completely, annotations cover safety semantics, and an output schema exists, so the tool is minimally callable. Still, the description omits any context about the form object versus form responses, which limits completeness for an agent navigating many form-related siblings.

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

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

The input schema fully documents both required parameters (user_google_email and form_id) with clear descriptions, so the description does not need to compensate. It also adds no extra 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 names a specific verb and resource: retrieve a form. It is clear about the core operation, but it does not differentiate from sibling tools like get_form_response or list_form_responses, which also involve forms.

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. There is no mention of prerequisites, when to prefer get_form_response, or what distinguishes retrieving a form definition from retrieving responses.

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 description's minimal 'Get one response' is consistent. However, it adds no behavioral context beyond the annotations—such as account-scoping requirements or the need for prior listing—but there is also no contradiction.

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

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

The description is a single compact sentence with no redundant words. It front-loads the essential action and object, making it easy to process quickly.

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

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

Given the simple tool with a fully described schema, clear annotations, and an output schema, the description is mostly adequate. However, it misses the practical context of how response_id is obtained and how this tool relates to list_form_responses, leaving a minor but notable gap for an agent deciding how to retrieve a response.

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 three parameters (form_id, response_id, user_google_email) individually described. The tool description adds no extra meaning to the parameters, so a baseline score of 3 is appropriate given the schema already documents them fully.

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

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

The description states a clear verb ('Get'), a specific resource ('one response'), and scope ('from the form'). It distinguishes itself from the sibling list_form_responses through the word 'one', but does not explicitly name the alternative or clarify that a specific response ID is required.

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 list_form_responses, nor does it mention that response_id must be obtained beforehand (e.g., via listing responses). An agent is left to infer usage entirely from the parameter 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 goes well beyond the annotations by disclosing that the attachment is written to local disk, that stdio versus HTTP returns different access mechanisms, that the HTTP URL is temporary and valid for one hour, and that metadata may be re-fetched to resolve filename and MIME type. This gives the agent meaningful behavioral expectations without contradicting any 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 compact, front-loaded with the core action, and every sentence earns its place: saving behavior, mode-specific return values, and metadata resolution are all covered in under 50 words. There is no filler 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?

Given the rich parameter schema, the presence of an output schema, and the annotations, the description covers the essential operational context: what happens to the file, how the agent accesses it in each mode, and the temporary nature of the HTTP URL. Nothing critical is missing for an agent to call 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?

The input schema already documents every parameter with 100% coverage, so the description does not need to repeat parameter details. The description adds general behavioral context about metadata re-fetching and delivery modes, but it does not specifically enrich the meaning of individual 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 states a specific action ('Downloads an email attachment') and a concrete resource outcome ('saves it to local disk'), clearly distinguishing this tool from message-content and thread-content siblings. It also immediately clarifies the two delivery modes, so an agent knows exactly what this tool returns.

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 tool's purpose makes its intended use reasonably evident, and the stdio/HTTP mode guidance helps the agent know what to expect. However, it does not explicitly say when to prefer this over siblings like get_gmail_message_content or download_chat_attachment, so the usage guidance is implied rather than stated.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the 20,000-character truncation, the disk-export/download-URL behavior for full=True, transport differences (HTTP vs stdio), and the stateless fallback. This is precisely the kind of behavioral context an agent needs to predict side effects and response shape.

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

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

The purpose is front-loaded in a single sentence, and the follow-up paragraph is dense but essential, covering truncation, export behavior, and stateless deployments without filler. Every sentence earns its place.

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

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

With a fully described schema, an output schema present, and annotations covering safety and idempotency, the description adds the remaining behavioral details needed for correct invocation. Nothing necessary 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 coverage is 100%, so the schema already documents each parameter. The description adds meaningful value by stating the default inline truncation limit and explaining why full=True matters—large messages never stream through the model context—which helps an agent reason about when to use 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 identifies the operation: retrieving the full content (subject, sender, recipients, body) of a specific Gmail message, with a concrete verb and resource. It does not explicitly contrast itself with sibling tools like the batch or thread variants, so it stops short of full 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?

The description explains when full=True is needed (large messages, byte-exact fidelity) and the default truncation behavior. It does not, however, give explicit guidance on when to choose this tool over search_gmail_messages, get_gmail_messages_content_batch, or get_gmail_thread_content; usage context is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: the batch limit and the reason for it, which helps the agent understand the tool's operational constraints.

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

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

Two sentences with no filler. The first sentence states the action and resource immediately; the second provides the key constraint and rationale. 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?

The output schema supplies return-shape details and the annotations cover safety, so the description only needs to convey scope and constraints, which it does. It could have explicitly pointed to get_gmail_message_content for single-message needs, but the clear naming and sibling list make that omission 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%: all four parameters have meaningful descriptions and enums. The tool description only reinforces the 25-message limit already present in message_ids, adding no significant new parameter-level meaning, so the baseline score 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 uses a specific verb ('Retrieves'), names the resource ('content of multiple Gmail messages'), and clearly marks the batch scope, distinguishing it from the singular get_gmail_message_content sibling. 'Single batch request' reinforces the 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 states the appropriate context: fetching multiple messages in one batch, with a 25-message cap and the rationale (preventing SSL connection exhaustion). It does not explicitly name alternatives like the singular get_gmail_message_content, but the context is clear enough for an agent to decide.

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

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so the bar for the description is lower. The description adds meaningful behavioral context beyond annotations: the tool returns ALL messages in the thread, and the include_analysis flag flips the return shape from a formatted string to a structured dict containing last sender, ball-in-court verdict, per-sender counts, and participants. This explains behavior the annotations cannot convey and 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?

Two sentences with zero waste: the first states the core function, the second explains the optional value-add and its benefit. The efficiency framing ('without re-parsing the formatted string or making a second tool call') earns its place by clarifying why the optional feature exists. Front-loaded, appropriately sized, no filler.

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

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

With an output schema present, return-value documentation is handled elsewhere; annotations cover the read-only/idempotent profile; and the schema covers all parameters at 100%. The description is complete for the core task. The only meaningful gap is explicit routing to sibling alternatives (batch vs. single vs. message-level), which would round out the contextual picture but is not critical given the clear thread-scoped purpose.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly, including defaults and enum semantics for body_format and include_analysis. Per the baseline rule, the description needn't repeat this. It adds marginal value by explaining the intent behind include_analysis ('who owes whom a response') but provides no additional meaning for thread_id, body_format, or user_google_email beyond what the schema already states.

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

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

The description opens with a specific verb+resource: 'Retrieves the complete content of a Gmail conversation thread, including all messages.' This clearly distinguishes it from siblings like get_gmail_message_content (single message) and search_gmail_messages (search), and the second sentence's ownership-analysis feature further differentiates it from get_gmail_threads_content_batch.

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

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

The description implies a use case — 'so a caller can determine who sent the last message and who owes whom a response... without making a second tool call' — which tells the agent when the optional analysis is valuable. However, it never explicitly addresses when NOT to use this tool or names alternatives (e.g., use get_gmail_threads_content_batch for multiple threads, get_gmail_message_content for one message). The guidance is implied, not stated.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context about the 25-thread batch limit and the underlying reason (preventing SSL connection exhaustion), which is not present in annotations and helps the agent respect rate/connection constraints.

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

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

Two short sentences: the first states the core purpose, the second states the key limit and rationale. Every word earns its place, 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?

With a full input schema, an output schema present, and annotations covering side-effect safety, the call context is largely complete. The only notable gap is explicit guidance on when to use this tool versus related single/batch thread or message tools.

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

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

Input schema coverage is 100%, including descriptions of thread_ids, body_format, and user_google_email. The description adds no parameter-level semantics beyond what the schema already provides, so it stays at the baseline.

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

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

The description states a specific verb ('Retrieves'), a specific resource ('multiple Gmail threads'), and the batching scope ('in a single batch request'). This clearly differentiates it from single-thread retrieval and message-batch retrieval by resource type and batch behavior.

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

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

The description gives a constraint (up to 25 threads per batch) but no explicit guidance on when to choose this tool over get_gmail_thread_content or get_gmail_messages_content_batch. It leaves usage selection to inference from the tool name rather than stating conditions or alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds little beyond the annotations; it says 'retrieves messages' but doesn't describe pagination behavior, default ordering, or that it may return only messages not yet deleted. No contradiction found.

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—one short sentence—and the parameter filter examples are helpful and well-structured. It is front-loaded with the core purpose. It could be slightly more informative, but it 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?

Given the presence of an output schema and rich annotations, the description doesn't need to explain return values. However, it lacks explicit guidance on how the message_filter syntax interacts with other parameters, pagination behavior, and required parameter semantics. It is minimally viable but not fully complete for an agent to call it with confidence in edge cases.

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

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

Schema description coverage is only 20%, so the description carries some burden, and it lists the main filter field and its supported syntax in detail (createTime and thread.name examples). However, it does not explain required parameters like user_google_email or space_id beyond their names, nor the order_by and page_size defaults. The filter details add real value over the schema, but gaps remain.

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 'Retrieves messages from a Google Chat space' uses a specific verb + resource and communicates the primary scope. It distinguishes itself from Gmail siblings by explicitly naming Google Chat, but does not differentiate from sibling tools like send_message, search_messages, or list_spaces, though the list verb is clear.

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

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

No guidance on when to use this tool vs alternatives such as search_messages or get_gmail_messages_content. It doesn't state exclusions, prerequisites, or conditions. The only context is that it is Chat-specific, which is implied but not explicitly routed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds useful behavioral context via include_geometry: it explains that geometry output is in EMU, that it is needed for discovering deck margins/gutters, and that defaulting to false keeps token cost unchanged—information not present in the annotations.

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

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

The entire description is one focused sentence that states the action and object with no filler. It is 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?

For a simple read-only tool, the definition is largely complete: annotations cover safety, the schema covers all parameters, and an output schema exists. The only gap is the lack of explicit guidance on when to choose get_page over get_presentation, though the description's 'specific page' phrasing implies it.

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 tool description itself says nothing about parameters; all meaningful semantics live in the input schema, particularly the rich include_geometry explanation.

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

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

Description clearly states a read operation on a specific page/slide within a presentation, with a direct object and scope. It differentiates from sibling get_presentation (whole deck) and get_page_thumbnail (thumbnail) by specifying details rather than thumbnail or full presentation.

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

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

The description does not name alternative tools or give exclusion conditions for when not to use it. The include_geometry parameter does offer conditional advice about when to enable geometry, but tool-selection guidance remains implied rather than explicit.

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

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

The annotations already supply the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds that the result is a URL and that it targets a single slide, but it does not disclose authentication prerequisites, URL lifetime, or other behavioral details. Adequate but not rich.

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

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

A single sentence with no filler. The action and target are front-loaded, and every word contributes meaning.

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, idempotent thumbnail-URL tool with full parameter documentation, strong annotations, and an output schema, the description is sufficient. Nothing critical for invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, so each parameter is already documented with a useful description. The tool description only reinforces that page_object_id refers to a slide and does not add meaningful parameter-level semantics 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 uses a specific verb ('Generate') and a precise resource ('thumbnail URL for a specific page (slide) in a presentation'). It clearly distinguishes this tool from siblings like get_page, which would return slide content rather than a thumbnail 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 intended purpose is clear from the description, but it does not explicitly state when to use this tool over alternatives such as get_page, nor does it mention prerequisites or exclusions. Usage context is implied by the resource targeted, not explicitly spelled out.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety and side-effect profile is well covered. The description itself adds no further behavioral context, such as what the response contains, how optional include_* flags alter behavior, or auth requirements.

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

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

The description is a single, direct sentence with no filler or redundant restatement of the title. It is appropriately sized for a simple retrieval tool, leaving detailed behavior to the schema and annotations.

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, complete schema descriptions, and the presence of an output schema, nothing essential is missing for an agent to call this tool correctly. The optional parameter behaviors are thoroughly explained in the schema, so the tool definition as a whole is 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%, so the baseline is 3 and the one-sentence tool description does not need to compensate for missing parameter documentation. The description itself adds no parameter-level meaning beyond what the input 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 states a concrete operation—get details about a Google Slides presentation—with a specific verb and resource type. It does not explicitly call out sibling tools, but the read-oriented verb and required presentation_id make its role clear versus creation/update tools.

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

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

There is no guidance about when to use this tool instead of create_presentation, batch_update_presentation, or other slides-related tools, and no exclusionary conditions are stated. The only usage signal is the verb 'get', which is implied rather than explicitly explained.

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