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?

Adds valuable context beyond annotations: 'atomic batch update' implies all-or-nothing execution, and the workflow warns about index calculation errors, which helps the agent reason about failure modes. However, it does not describe authentication needs or the exact side effects of destructive operations beyond what destructiveHint already signals.

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

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

The description is well-structured with clear phases, a code example, and purposeful recommendations. Every sentence earns its place: it routes to alternatives, explains a best practice, and illustrates a full batch. The example is compact yet informative, and the front-loaded purpose statement makes the tool's role immediately clear.

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

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

Given the tool's high complexity (many operation types), the description provides a sufficient conceptual framework: atomic batch, phases, end_of_segment usage, and a concrete example. The output schema and input schema cover the remaining details, so the agent has what it needs to call the tool correctly for common document-building workflows.

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 high (>80%), so baseline is 3. The description enhances semantics by showing a concrete operations array with end_of_segment=true and omitted index, demonstrating how to use parameters correctly. It also explains why phases matter, adding meaning to the operations parameter beyond the schema's field descriptions.

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

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

The description clearly states a specific verb ('Executes'), resource ('multiple low-level document operations'), and qualifier ('single atomic batch update'). It explicitly distinguishes itself from sibling tools by naming update_doc_headers_footers for normal header/footer text and reserving create_header_footer for advanced section-break layouts, making selection 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?

Provides concrete when-to-use guidance: prefer update_doc_headers_footers for normal headers/footers, and only use create_header_footer here for advanced section-break layouts. The phased workflow explicitly recommends end_of_segment=true to avoid index calculation errors and gives a complete example, so the agent knows exactly when and how to invoke this tool.

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

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

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, so the safety profile is covered. The description adds that it searches by name and checks public sharing, but does not disclose edge cases like behavior when the file is not found, whether it returns a boolean, or how it handles files in shared drives without drive_id (the schema partially addresses this). This is 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, tightly written sentence that states the action and the check. No wasted words, and the purpose is front-loaded. This is exemplary conciseness.

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

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

The tool is simple, has a clear description, full schema documentation, and an output schema (not shown but indicated). The description covers the essential purpose, and the schema fills in parameter details. Given the sibling ambiguity, a note about when to choose this over get_drive_file_permissions would improve completeness, but as is it is sufficient for a straightforward check tool.

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

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

Schema description coverage is 100%, so the schema already fully documents all three parameters, including the drive_id scoping behavior. The description adds no extra parameter 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 states a specific verb+resource: it searches for a file by name and checks if public link sharing is enabled. This clearly distinguishes it from sibling tools like search_drive_files (which just searches) or get_drive_file_permissions (which fetches all permissions). It is unambiguous about the tool's core function.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_drive_file_permissions or get_drive_shareable_link. It does not mention any conditions or prerequisites, leaving the agent to infer that this is the right tool for a simple public-access check. Given the large sibling list with overlapping permission-related tools, explicit differentiation would help.

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

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

Annotations already carry the read-only, destructive, and idempotence signals, so the description only needs to add behavioral context. It adds useful specifics: the file is copied to a new location, may be renamed, and retains all formatting and content. It 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 compact and front-loaded: the core action is stated in the first sentence, followed by two short sentences that expand on destination, name, and outcome. Every sentence earns its place 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?

Combined with the fully documented schema, the description gives enough information for a correct call: what is copied, where it goes, whether a new name can be set, and that content is preserved. It stops short of a 5 because it does not address what happens to permissions or sharing on the copied file, a common ambiguity when duplicating Drive files.

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's references to a 'new location' and 'optional new name' loosely map to parent_folder_id and new_name, but it adds little beyond what the schema already states with defaults and 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 'Creates a copy of an existing Google Drive file,' which names a specific action and resource. It clarifies the operation by adding that the copy goes to a new location and preserves formatting/content, making it easy to distinguish from sibling tools like create_drive_file or update_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?

The description clearly implies this tool is for duplicating existing files, but it never explicitly states when to prefer it over alternatives such as create_drive_file or import_to_google_doc. There are no exclusions or prerequisite conditions, so usage guidance remains implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation nature is known. The description adds the 'secondary' scoping constraint, which is useful behavioral context, but it does not disclose side effects, permission requirements, or output characteristics beyond what annotations and the 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 a single six-word sentence that is front-loaded and contains zero filler. Every word adds meaning, making it an ideal example of conciseness.

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

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

The tool is simple (4 params, 2 required), the schema fully documents parameters, and an output schema exists, so the return value is covered. The description plus structured data is sufficient for correct invocation. A slight gap is the lack of guidance on when the 'secondary' distinction matters, but this is not critical for a straightforward create operation.

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

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

Input schema coverage is 100%, so all four parameters are already fully described. The description itself adds no parameter-specific meaning, so the baseline score of 3 is appropriate—it neither helps nor hurts beyond the schema.

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

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

The description clearly states the action ('Creates') and the resource ('a new secondary Google Calendar'). The term 'secondary' differentiates it from tools that manage the primary calendar or list calendars, so an agent can distinguish it from siblings without opening the schema.

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

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

There is no guidance about when to use this tool versus alternatives like list_calendars or manage_event. No prerequisites, exclusions, or sibling comparisons are provided, leaving the agent to infer usage solely from the tool 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?

Annotations only indicate readOnlyHint=false, openWorldHint=true, etc., offering little safety context. The description adds valuable behavioral details—document body starts at index 1, empty doc length is 2, and the recommended workflow for building content—which goes beyond annotations and enriches the agent's understanding of the tool's effects 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 organized into three clear paragraphs: purpose, structural details, and workflow. It is front-loaded with the core purpose and each sentence serves a function. While not extremely concise, the structure is logical and free of fluff, earning a 4.

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

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

Given the output schema exists and the description covers creation behavior and explicitly links to sibling tools for subsequent steps, it is fairly complete. It doesn't mention error handling or permissions, but those are not necessarily required for a creation tool when output schema is present. The guidance on using batch_update_doc and inspect_doc_structure fills practical gaps, making it adequate.

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

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

Schema description coverage is 100%, so all parameters (title, content, folder_id, user_google_email) are already documented. The description does add that content is 'optional initial plain text' and that folder_id defaults to 'root', but these are also present in the schema. It adds no new meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb ('Creates'), a resource ('a new Google Doc'), and an optional capability ('inserts initial content'). It clearly distinguishes from siblings by explicitly directing to use batch_update_doc for rich content and inspect_doc_structure for positions, making the tool's role 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 explicitly provides when-to-use guidance: 'To build a rich document after creation, use batch_update_doc...' and 'Then call inspect_doc_structure...'. This tells the agent exactly when to use this tool versus alternatives and what steps follow, eliminating 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 establish readOnlyHint=false and destructiveHint=false Fibonacci, so the write-but-not-destructive safety profile is covered. The description adds meaningful behavioral context: it stores bytes without converting to Google native formats, and it supports shared drives. It does not dive into auth or side effects, but given annotation coverage, this is sufficient.

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 sentences with no fluff: purpose first, then input modes, then the conversion caveat and alternative. Every sentence carries distinct information and the structure front-loads the core definition.

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

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

For a tool with 9 parameters and an output schema, the description covers the main use cases, the shared-drive capability, and the critical non-conversion behavior. It does not mention potential error conditions or parameter interactions, but the 100% schema coverage and output schema reduce the need. It is complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of 'direct text content, inline base64 bytes, or a fileUrl' maps to existing schema parameters (content, base64_content, fileUrl) without adding new semantics like mutual exclusivity or precedence. It adds marginal grouping value but does not compensate 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?

States a specific verb ('Creates') and resource ('a new file in Google Drive'), and explicitly scopes to shared drives. It distinguishes itself from the import_to_google_* siblings by clarifying it stores bytes without converting, making the tool's role 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?

Explicitly tells the agent when not to use this tool: 'Use the matching import_to_google_* tool for Google-native conversion.' It also lists the three supported content input modes (text, base64, fileUrl), giving clear contextual guidance for choosing this tool over siblings.

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

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

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 indicate this is a non-read-only, non-idempotent operation, and the description reinforces that by saying it creates a new form. That adds a small amount of context beyond the annotations, but the description does not disclose side effects, authorization requirements, or response behavior. There is 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 a single concise sentence with no filler. It is slightly awkward due to the 'provided form message in the request' phrasing, but it remains short and front-loads the primary action.

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 schemaahan, full schema coverage, and annotations, so the description does not need to document return values or safety. However, the vague reference to 'form message' and the lack of usage guidance leave some ambiguity about how the request supplies the title and when this tool is appropriate.

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 parameters are already fully documented in the schema. The description mentions the title but adds no meaning beyond the schema descriptions. It does not clarify how 'description' or 'document_title' are used or how user_google_email affects execution.

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 and resource: 'Create a new form'. It is semantically distinct from sibling tools like get_form, batch_update_form, and set_publish_settings. However, the phrase 'using the title given in the provided form message in the request' is somewhat vague and could be interpreted ambiguously.

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 alternatives, nor any conditions or exclusions. The only hint is the verb 'Create', which implies it is for creating a new form rather than retrieving or updating one, but this is left entirely to 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 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 signal that this is a mutating, non-destructive, non-idempotent operation. The description adds the dual create-vs-duplicate behavior, but it does not disclose what happens on duplicate, name conflicts, copying scope, or required authorization context.

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

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

The opening clause is short and front-loaded, but the inline signature is redundant with the input schema and adds clutter. The description is not overly long, yet not every part 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 five parameters and zero parameter descriptions in the schema, a single functional line is insufficient. The mode-selection logic between sheet_name and source_sheet_name is absent, so an agent could invoke the tool with conflicting or misunderstood options.

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 parameters. It only restates the Python-style signature, which largely duplicates the input schema's types and defaults, and gives no actual meaning for fields like source_sheet_name or insert_sheet_index.

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 action ('Creates a new sheet or duplicates an existing sheet') and the resource, so an agent can tell what the tool does. However, it does not differentiate from close siblings such as manage_sheet_tab or create_spreadsheet, so it stops short of a 5.

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

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

The description offers no guidance about when to use this tool versus related tools like manage_sheet_tab, create_spreadsheet, or copy_drive_file. It states what the tool does but not the conditions that should lead an agent to select it.

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

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

The description only restates the creation action and adds no behavioral context beyond the annotations. It does not disclose where the spreadsheet is created by default, authentication or permission requirements, or resulting runtime behavior. This is not a contradiction, but it adds no value beyond the structured signals.

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, short sentence with no redundancy. However, it is under-specified: it essentially repeats the tool name and does not structure any key decision-relevant facts such as defaults or related tool choices.

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

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

Given four parameters, two required fields, an output schema, and a large sibling tool set, a one-sentence description is insufficient. It lacks usage boundaries against create_sheet/import_to_google_sheets and does not explain behavior beyond 'create', leaving the agent under-informed for correct 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?

The schema already provides 100% parameter coverage with descriptions, including required user_google_email and title, the default for folder_id, and the behavior of sheet_names. The description itself adds no parameter information, but the high schema coverage justifies a baseline score of 3.

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

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

The description clearly states the action and resource: 'Creates a new Google Spreadsheet.' This is not a tautology and conveys the core operation accurately. However, it does not explicitly differentiate from sibling tools like create_sheet or import_to_google_sheets, so it lacks 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 provides no guidance on when to use this tool versus alternatives such as create_sheet, import_to_google_sheets, or create_drive_file. An agent must infer the right choice from the tool name rather than from explicit 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 establish read-only false and non-destructive, so the description need not restate that. It adds real behavioral constraints: the index must come from inspect_doc_structure, rows must be uniform, and debug_table_structure should be used after creation to verify. It does not explain failure modes, but the bar is lower because annotations cover the safety profile.

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 and uses numbered sections, but it is repetitive: the CRITICAL index requirement is stated three times, and the workflow repeats the data-format details already in the schema. It earns its place mostly, but 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 is very complete for an agent: it supplies the mandatory upstream call, the index source, data format rules, and post-creation verification via debug_table_structure. It stops short of discussing output/return shape or failure handling, but the presence of an output schema reduces that burden.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the exact 2D array shape, the no-None rule, uniform column counts, and the mandatory relationship between index and inspect_doc_structure.total_length.

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 sentence names the exact operation ('Creates a table and populates it with data') and highlights the one-call atomicity. This distinguishes it from append_table_rows and insert_doc_elements in the sibling list.

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

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

The description gives a mandatory step-by-step workflow: call inspect_doc_structure first, derive the index from total_length, then call this function. It lacks explicit when-not-to-use or alternative tool routing, but the precondition and order are unambiguous.

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?

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?

Beyond the annotations, the description discloses critical runtime behavior: scheduling is impossible through the REST API, the Scheduled folder cannot be populated, and future delivery requires retaining the data and later calling send_gmail_message or users.drafts.send. It also references the draft ID returned by the tool, which is valuable for follow-up calls.

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 and the scheduling caveat is clearly separated, making the long block scannable. The scheduled-send paragraph is slightly repetitive and could be tightened, but every sentence contributes safety-relevant guidance.

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

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

For a tool with 15 parameters, an output schema, and annotations, the description is complete: it covers behavior, the API scheduling limitation, Send As support, and the follow-up path for deferred delivery. Detailed parameter semantics and return expectations are already in the schema and output schema, so the description does not need to repeat them.

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

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

All 15 parameters already have descriptions in the schema (100% coverage), so the baseline applies. The description's 'Send As' mention largely restates the from_email schema text rather than adding per-parameter detail. There is no extra semantic meaning beyond what the schema 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 opens with a specific verb+resource ('Creates a draft email in the user's Gmail account') and immediately narrows scope to new drafts, reply drafts, attachments, and Send As aliases. The 'draft' wording clearly separates it from send_gmail_message before the scheduling note names that sibling.

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

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

It names the relevant sending sibling (send_gmail_message) as part of the scheduling workaround and explicitly states that Gmail's API cannot place a message in the Scheduled folder. However, it lacks a direct 'use this for drafts, use send_gmail_message for immediate sends' boundary, leaving that distinction mostly implied by the word 'draft'.

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 signal mutation/destructiveness; the description adds behavioral context by explaining this is a no-index, targeted-replacement operation and frames it as the 'safest' update path because it avoids index errors. It could have explicitly said the edit is applied directly/irreversibly, but the destructiveHint is already 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 main point is front-loaded in the first sentence and the usage scenarios are scannable bullets. It is still slightly redundant, repeating the no-indexes idea three times ('No index calculation required', 'does not require knowing any indices', 'without risk of index errors').

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 an output schema, the description covers what it does, when to use it, and which sibling to reach for when building documents from scratch. It does not elaborate on tab_id/match_case semantics, but the schema already describes those and the use cases suffice.

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 and the description carries no per-parameter burden. The 'No index calculation required' note is a useful high-level hint, but it does not add meaning to any specific parameter 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?

Opens with a specific verb+resource ('Finds and replaces text throughout a Google Doc') and immediately adds a distinguishing constraint ('No index calculation required'). The listed use cases make the tool's scope concrete and separate it from sibling tools like modify_doc_text or batch_update_doc.

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

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

Explicitly enumerates three when-to-use scenarios and provides an alternative path for document construction ('consider inserting text with unique placeholders via batch_update_doc'). This gives an agent both inclusion and exclusion guidance.

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

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

Annotations already convey that this is a non-read-only, non-destructive, non-idempotent operation. The description adds useful behavioral context beyond annotations: colors must be hex strings, number formats follow Sheets types, and the first sheet is used when no sheet name is given. However, it does not disclose whether unspecified formatting properties are preserved, cleared, or merged with existing formatting.

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. The core purpose is front-loaded, and the constraint notes about colors, number formats, and default sheet are each meaningful and separated cleanly.

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

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

For a 13-parameter tool, the fully described schema plus the added constraints on color, number-format values, and default sheet cover most invocation needs, and an output schema exists so return values need no explanation. The main missing piece is a statement about how formatting interacts with existing cell styles.

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 value by constraining color values to hex strings, listing Sheets number-format types such as NUMBER and CURRENCY, and clarifying the sheet-selection default. This goes beyond the schema's individual parameter descriptions without duplicating them.

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

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

The description states a specific operation—'Applies formatting to a range'—and enumerates the style categories involved: colors, number formats, text wrapping, alignment, and text styling. It is clear and resource-specific, though it does not explicitly call out spreadsheet siblings such as manage_conditional_formatting or modify_sheet_values to reinforce the 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?

There is no guidance about when to choose this tool instead of related siblings like modify_sheet_values or manage_conditional_formatting. The only operational note is the first-sheet default, which clarifies behavior but does not help with tool selection.

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

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

Annotations already indicate readOnly and idempotent behavior. The description adds crucial context beyond those hints: this tool does not create triggers directly, it only generates the code the user must run inside Apps Script. This effectively communicates that calling the tool has no trigger-creation side effect.

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

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

The description is compact and front-loaded with the core purpose. The API limitation and sibling routing each earn their place without 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?

The description covers the tool's purpose, its API constraint, the generation behavior, and the appropriate sibling for list/delete operations. With detailed schema coverage and a present output schema, nothing essential is missing for an agent to invoke it correctly.

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

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

The input schema has 100% parameter description coverage, including allowed values for trigger_type and schedule semantics. The description itself does not add parameter-level meaning beyond what the schema already provides, so the baseline score applies.

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

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

States a specific verb and resource: 'Generates Apps Script code for creating triggers.' This clearly distinguishes the tool from direct trigger management and from manage_script_trigger, which is called out by name.

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

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

Explicitly explains the constraint that triggers cannot be created via the Apps Script API and must be created from within Apps Script itself. It then names the sibling alternative for listing/removing triggers, giving clear when-to-use versus 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, 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 this tool read-only, non-destructive, and idempotent. The description adds context beyond the annotations by specifying the output is clean Markdown, that comments are included by default, and that comment anchor text is preserved for context. This is sufficient given the annotation coverage.

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 focused paragraphs with no wasted words. It front-loads the core purpose, immediately distinguishes the tool from its sibling, and then explains the comment behavior. Every sentence contributes useful 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 is complete for a read-only retrieval tool: it names the key sibling alternative, clarifies output format, explains comment behavior, and the output schema handles return value details. An agent has enough information to select and invoke 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?

The input schema provides complete descriptions for all 7 parameters, including enums-like options for comment_mode and suggestions_view_mode, so the schema carries the parameter documentation burden. The description adds some useful semantic context about comment anchoring and default behavior, but does not need to compensate for any schema gaps.

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: it reads a Google Doc and returns it as Markdown. It also explicitly differentiates itself from get_doc_content, which returns plain text, making the tool's purpose unmistakable.

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

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

The description clearly names get_doc_content as the alternative and explains the distinguishing factor: this tool preserves formatting as Markdown while get_doc_content returns plain text. It implies when to choose this tool, though it does not explicitly state 'use get_doc_content when plain text is sufficient'.

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 substantial behavioral context beyond annotations: index alignment with U+FFFC placeholders, body starts at index 1, offset mapping (n+1), table/tab separator interleaving, preserve_context behavior, and exclusions (comments, revision history, exact visual layout, chip details hidden by API). This is rich, non-obvious behavior that an agent needs to know before calling.

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

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

The description is well-structured with clear sections and front-loaded purpose. It is longer than average, but every sentence earns its place by explaining non-obvious behavior (index alignment, preserve_context semantics, exclusions). The only minor deduction is that the index-alignment explanation is dense and could be slightly tightened, but it is not redundant.

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

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

Given the tool's complexity (5 params, output schema present, multiple file types, index-alignment behavior), the description is complete. It covers what is returned, how alignment works, when to use preserve_context, what is excluded, and how to route to get_doc_as_markdown. The output schema exists, so return values need not be described in prose. Nothing an agent needs to call this 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 the schema already documents all 5 parameters. The description adds meaning beyond the schema by explaining the behavioral implications of preserve_context (readable semantic annotations, plain text not Markdown, offsets not usable as editing indices) and tab_id (index-aligned with that tab, no tab separator). It also clarifies document_id accepts full URL. This goes beyond the baseline 3 for full 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 retrieves content of a Google Doc or Drive file (like .docx) identified by document_id, and distinguishes between native Docs (via Docs API) and Office files (via Drive API). It also differentiates from sibling get_doc_as_markdown by noting that tool is for formatting/comments. The verb 'retrieves' plus resource and scope is specific and unambiguous.

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

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

The description explicitly explains when to use this tool vs alternatives: 'Use get_doc_as_markdown for formatting or comments.' It also provides detailed guidance on when to set preserve_context=True and warns that offsets in that mode must not be used as editing indices. It explains the default index-aligned behavior and how to use tab_id for single-tab reads, giving clear context for choosing this tool over siblings.

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

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

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: it saves to local disk (a side effect not implied by read-only), returns a temporary URL in HTTP mode with a 1-hour validity, and explains export conversions for native files. This goes beyond what annotations provide and helps the agent understand the tool's actual 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 moderately long but well-structured: it opens with the core purpose, then explains mode differences, then uses a bullet list for export formats. It avoids redundancy and every section adds value. It could be slightly more concise by trimming the repeated 'default' mentions, but it remains efficient and front-loaded with the main action.

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

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

Given the tool has an output schema (not shown but indicated), the description doesn't need to detail return values. It covers the essential behavioral aspects: local saving, mode differences, and export formats. Potential gaps like file size limits or error handling are not mentioned, but for a download tool with a clear output schema, the description is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds extra meaning to export_format by detailing the exact mapping for each native file type (e.g., Sheets supports CSV, PDF, XLSX) and the default behavior when not specified. This is beyond what the schema states and helps the agent choose the right format. The other parameters are already well-described in the schema.

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

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

The description clearly states the tool's purpose: 'Downloads a Google Drive file and saves it to local disk.' It then explains the different output modes (stdio vs HTTP) and export behavior for native files, which distinguishes it from siblings like get_drive_file_content (which likely returns content without saving) and export_doc_to_pdf (which specifically exports Docs to PDF). The purpose is specific and unambiguous.

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

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

The description provides clear context on when to use the tool: for downloading a Drive file to local disk. It also explains the difference between stdio and HTTP modes, and how export_format affects native files. However, it does not explicitly name alternative tools or state conditions for not using this tool, such as 'use get_drive_file_content when you need the content in memory.' Still, the usage 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 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds scoping behavior (single vs. range vs. keyword), but does not disclose pagination behavior, recurring-event expansion nuances, or behavior when no events match. 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 short sentences with the primary action front-loaded, followed by the key retrieval variants. There is no filler, no restating of the tool name, and every sentence earns its place.

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

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

Given the rich 100%-covered schema, strong annotations, and the presence of an output schema, the high-level description is sufficient for an agent to recognize and begin invoking the tool. It could additionally orient agents toward pagination or recurring-series behavior, but those details are already documented in the schema, so the gap is 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%, and the schema already provides detailed semantics for parameters like query, time_min, single_events, page_token, and detailed. The description only restates that query enables keyword search, adding no meaningful semantic information beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource ('Retrieves events from a specified Google Calendar') and then enumerates the retrieval modes: single event by ID, multiple events in a time range, and keyword search. This makes the tool's purpose immediately clear and distinguishes it from calendar metadata tools like list_calendars and mutation tools like 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 implies when to use the tool (whenever calendar events need to be read), but it does not explicitly contrast it with sibling tools such as query_freebusy, list_calendars, or manage_event. There is no when-not-to-use guidance or explicit alternative routing, so usage context is only implied.

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

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

Annotations already 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?

Annotations provide little behavioral detail, so the description adds valuable context: the tool writes to local disk, returns a temporary URL in HTTP mode, and may re-fetch message metadata. These are meaningful side-effect and timing details beyond what the annotations convey.

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

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

The description is front-loaded with the core action and then provides mode-specific return behavior in three concise sentences. Every sentence adds useful information, 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?

The description covers the side effect, both output modes, the temporary URL lifetime, and a potential metadata re-fetch. Combined with a 100%-covered input schema and an output schema, the agent has enough context to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the parameters are already well documented, including detailed descriptions for return_base64 and attachment_index. The tool description itself adds no additional parameter semantics beyond what the schema already provides, so it appropriately 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 action ('Downloads an email attachment'), a clear resource, and the resulting artifact ('saves it to local disk'). It distinguishes itself from siblings like get_gmail_message_content and download_chat_attachment by explicitly targeting Gmail email attachments.

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

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

The intended use is implied by the name and first sentence, and the stdio/HTTP return-mode distinction provides useful context. However, the description never explicitly says when to choose this tool over alternatives like get_gmail_message_content or download_chat_attachment, nor does it mention any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral detail beyond these: it discloses the 20,000-character inline truncation, the export-to-disk behavior for full=True, the transport-specific response (download URL for HTTP, file path for stdio), and the stateless fallback that inlines the untruncated body. This goes well beyond the annotations and paints a complete picture of side effects and response characteristics.

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 and a short paragraph, with no filler. It front-loads the core purpose, then explains the truncation and full=True behavior in a structured, efficient way. Every sentence contributes critical information about when and how to use the tool, and the structure guides the reader from basic behavior to edge cases.

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 tool with a full output schema, the description covers the essential behavioral nuances: truncation, full=True transport, and stateless handling. It does not detail error conditions or how to obtain message_id, but these are typically handled elsewhere. Given the output schema and annotations, the description is sufficient for an agent to call the tool correctly and interpret the response, with only minor omissions around edge-case error handling.

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 a baseline of 3 applies. The description adds value by explaining the implications of the full parameter: it clarifies the transport-specific behavior and stateless mode, which are not in the schema. It also ties full=True to body_format='raw' for .eml export. This adds meaningful context beyond the schema's own parameter descriptions, justifying a 4.

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

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

The description opens with a precise statement of the operation: 'Retrieves the full content (subject, sender, recipients, body) of a specific Gmail message.' This clearly identifies the resource (a specific Gmail message) and the verb (retrieves). It distinguishes the tool from batch and thread siblings by the singular scope, and from attachment tools by listing body content explicitly.

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

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

The description does not explicitly state when to prefer this tool over its siblings (e.g., get_gmail_messages_content_batch for multiple messages, get_gmail_thread_content for threads). However, it provides guidance on the full=True parameter, explaining when it should be used (large messages, byte-exact fidelity). The absence of alternative routing means an agent must infer single-message usage from the tool name and schema, making the guidance implied rather than explicit.

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

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

Annotations already declare 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds only the space-scope context and does not disclose pagination, filtering, ordering, or the role of user_google_email, but it 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 one direct sentence with no filler, and the main action is front-loaded. It is under-specified for the tool's complexity, but its structure is 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?

For a 5-parameter tool with a required user_google_email and a sibling search_messages tool, this description is too thin. It lacks parameter semantics and usage guidance, though the output schema and annotations cover return values and safety.

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

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

With schema description coverage at only 20%, the description needed to compensate for the undocumented parameters such as user_google_email, space_id, order_by, and page_size. It does not mention any of them and adds no meaning beyond the schema property names.

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

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

The description states the operation (Retrieves messages) and the resource scope (from a Google Chat space), which separates it from the Gmail message tools. It does not explicitly distinguish it from the sibling search_messages tool, so it falls just short of a top score.

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

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

There is no guidance on when to use get_messages versus search_messages, nor any context about when this tool is the right choice. No preconditions, 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 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.

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 the dual-mode behavior (processes vs. metrics) which is useful, but it does not disclose details like pagination behavior or authentication requirements. The description is consistent with annotations and adds some value beyond 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 a single, efficient sentence that immediately conveys the tool's purpose and the two key modes. There is no unnecessary verbosity, 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?

Given the high schema coverage, presence of an output schema, and annotations that establish safety, the description is nearly complete. It lacks only minor context such as explicit clarification that script_id is required for metrics (though the schema covers this). The tool is a read-only operation with clear modes, 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?

The input schema has 100% description coverage, so all five parameters are documented in the schema itself. The description does not add any additional semantic detail beyond what the schema provides. Baseline 3 is appropriate when the schema carries the explanatory 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 clearly states the verb 'Read' and the resource 'execution activity for scripts', and further specifies two modes: 'recent processes' and 'aggregate metrics'. This distinguishes it from sibling tools like get_script_project or run_script_function, which serve different purposes. The purpose is unambiguous.

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

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

The description implies usage for reading execution activity but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. The context is clear enough for an agent to infer, but there is no explicit guidance on selection.

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

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

Annotations already cover safety: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description simply restates the read nature and adds the 'source files' scope, but it does not add contextual behavior such as mode differences (list vs get) or pagination; this is acceptable because annotations carry the safety 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 operation without filler. Every word contributes to selection.

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 100% schema coverage, robust annotations, and presence of an output schema, the description is largely sufficient. It is brief but would benefit from explicitly noting the list-versus-get action modes or pointing to manage_script_content for edits; still, it provides enough context to select 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 every parameter including action, script_id, file_name, page_size, and page_token is already documented. The description adds no parameter-level meaning beyond the schema, which meets the high-coverage 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 the specific verb 'Read' with a clear resource scope, 'Apps Script projects and their source files.' This directly differentiates it from sibling tools like manage_script_project, get_script_version, and get_script_activity, which concern different resources or operations.

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

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

The read-oriented wording implies it should be used when an agent needs to inspect Apps Script projects or files, but the description offers no explicit when-to-use/when-not-to-use guidance or named alternatives such as manage_script_content or get_script_activity.

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

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

The description adds 'immutable version snapshots' and notes that 'get' requires version_number, which are useful behavioral details. Annotations already declare readOnlyHint=true and destructiveHint=false, covering the read-only safety profile. However, it does not explain operational behaviors like authentication context or error responses, though these are partially mitigated by 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 compact and well-structured: a single opening sentence stating purpose followed by a bulleted list of the two actions. Every sentence contributes value and there is no redundant wording.

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