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 adds substantial behavior beyond the annotations: batchModify returns no per-message result, silently ignores unrecognized ids, and defaults to read-back verification with a stated cost. It also explains that thread_ids use a different endpoint and report per-thread outcomes.

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 information-dense, with each paragraph serving a clear purpose. It is somewhat long, but the examples and endpoint distinctions earn their space.

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

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

For a destructive batch mutation with full schema descriptions, annotations, and an output schema, the description is complete. It covers the critical endpoint quirks, verification behavior, and parameter interaction needed to call the tool correctly.

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

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

Schema coverage is 100%, so the parameters are already documented, but the description adds important semantics: the 1000-id batch limit, per-thread processing, and the requirement that at least one of message_ids or thread_ids and one of add_label_ids or remove_label_ids be supplied. It does not explain every parameter in detail, but it meaningfully supplements 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 gives a specific verb and resource: adding or removing labels on many Gmail messages or whole conversations. The batch scope is clear through 'many' and thread-level handling, though it never names the singular sibling modify_gmail_message_labels as the alternative.

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

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

It clearly distinguishes message_ids versus thread_ids and gives concrete examples such as archiving with remove_label_ids=["INBOX"]. It also states the minimum requirements, but does not explicitly say when to prefer the singular modify_gmail_message_labels tool.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds the valuable 'atomic' property and index-avoidance advice, but omits key batch semantics an agent needs: whether operations apply sequentially, whether indices are computed against the original or mutated document, and what happens on partial failure.

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?

Purpose is stated in the first sentence, then routing, then a clearly labelled two-phase workflow. It is longer than typical but front-loaded and the length is justified by the tool's complexity; the header separators aid scanning rather than adding noise.

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

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

For an extremely complex 29-variant operation tool, the description covers the dominant usage pattern (append-only document building), defers header/footer work to a sibling, and avoids duplicating return values since an output schema exists. Only minor gaps (non-append index sourcing via inspect_doc_structure) remain, and those are documented in the schema's segment_id/anchor params.

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 all 29 operation variants are documented in the schema, so the baseline is met by structured data alone. The description nonetheless adds real meaning over the schema by showing a literal example operations array and explaining the end_of_segment=true pattern that avoids index math.

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 ('Executes multiple low-level document operations in a single atomic batch update') and immediately distinguishes itself from the sibling update_doc_headers_footers by naming the case where the sibling should be preferred instead.

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 routes the agent: normal header/footer text goes to update_doc_headers_footers, while create_header_footer here is reserved for 'advanced section-break layouts'. It also supplies a concrete phased workflow for the primary use case (building documents), so when-to-use is 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 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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds that formatting and content are preserved in the copy, which is useful, but omits behaviors an agent would want: whether sharing permissions carry over to the copy, that comments are not copied by default, and that each invocation produces a new file (reinforcing non-idempotency).

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, front-loaded with the core action. There is mild redundancy between "Creates a copy of an existing Google Drive file" and "This tool copies the template document," but nothing extraneous enough to impede scanning.

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?

An output schema exists, so return values need not be explained, and annotations cover the mutation profile. However, for a 5-parameter write tool that creates a new artifact, the description says nothing about permission inheritance, storage/quota impact, or destination folder handling, leaving an agent to infer the side effects.

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 copy_comments, parent_folder_id and new_name is already documented. The description only echoes the optional new-name behavior and says nothing about parent folder placement or the Docs/Sheets/Slides limitation on comment copying, so the baseline 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?

States a specific verb and resource ("Creates a copy of an existing Google Drive file") and clarifies the copy preserves formatting and content. It never distinguishes itself from nearby siblings such as create_drive_file or import_to_google_doc, so an agent cannot rule those out from the description alone.

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?

"This tool copies the template document to a new location" implies the intended use case (duplicating an existing template or document), but there is no explicit when-to-use guidance, no stated prerequisites, and no named alternative such as create_drive_file for authoring from scratch.

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 declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds non-obvious behavioral facts: content lands as plain text with no Markdown rendering, and a fresh doc has body starting at index 1 with total length 2.

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?

Purpose is front-loaded in one sentence, followed by tightly grouped guidance on content semantics, index conventions, and the follow-up tool sequence. No filler sentences.

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

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

Output schema is present so return values need no explanation, and the description covers creation semantics, the one surprising input behavior, and the follow-up path for rich documents — everything an agent needs to call this correctly and continue afterward.

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

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

Schema coverage is 100%, so the schema already documents all four parameters; the description nonetheless adds real meaning for 'content' by stating it is inserted as plain text and that Markdown requires a different tool. folder_id and user_google_email semantics are left to the schema.

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

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

The first sentence gives a precise verb and resource ('Creates a new Google Doc') plus the optional-content scope, and the second sentence names the sibling it is not (import_to_google_doc) with the condition that selects it.

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

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

It explicitly routes away from this tool to import_to_google_doc for Markdown input, and lays out a concrete post-creation workflow: batch_update_doc with end_of_segment=true to append, then inspect_doc_structure before applying formatting.

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

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

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, non-idempotent, open world), so the bar is lower. The description still adds substantive behavior the annotations cannot convey: the three accepted content sources, the upload-URL mode used when local file access is disabled, and the important guarantee that bytes are stored verbatim rather than converted.

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

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

Four short sentences, front-loaded with the core action, each carrying distinct information: what it creates, what inputs it takes, the no-local-access fallback, and the conversion boundary. Slightly dense with edge-case detail but nothing is wasted.

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

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

With nine parameters, an output schema present, and full schema coverage, the description supplies the parts structured fields cannot: the input-mode choice and the conversion boundary. It omits size limits, default sharing/permission behavior, and explicit mention of the required identity/folder parameters, but those are adequately covered by the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds selection guidance for the mutually exclusive content parameters by enumerating text content, inline base64, and fileUrl as alternative input modes — something the schema documents individually but never frames as a choice. It does not explain mime_type/base64_sha256 behavior beyond what the schema already says.

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 ('Creates a new file in Google Drive') plus the shared-drive scope, and explicitly demarcates itself from the import_to_google_* siblings by declaring it stores bytes without conversion. An agent can distinguish it from update_drive_file or copy_drive_file without opening any 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?

Gives an explicit routing rule: use the matching import_to_google_* tool when Google-native conversion is wanted. It also explains the upload-URL fallback path when local file access is disabled, which is a real when-to-use condition. It does not discuss create-vs-update or folder-creation prerequisites, so it stops short of full when/when-not coverage.

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?

The annotations already establish that this is a read-only, idempotent, non-destructive inspection tool, so the description does not need to restate safety. The description adds useful behavioral detail by explaining exactly what the output reveals, including dimensions, cell coordinates, current content, insertion indices, and table boundaries.

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 organized into clear sections, but it is substantially longer than needed for a simple read-only debug tool. The all-caps emphasis and overlapping sections such as 'USE THIS IMMEDIATELY WHEN' and 'WORKFLOW INTEGRATION' add repetition without much additional useful 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?

Given the output schema and annotations, the description is complete enough to call the tool correctly and interpret its results. The main remaining gap is that it does not explicitly compare itself with inspect_doc_structure or clarify table_index behavior for documents with multiple tables.

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 parameter meanings are already fully documented. The description does not add parameter-level guidance such as how table_index interacts with multiple tables or when tab_id is required; it only contextualizes insertion_index as an output concept.

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

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

The description uses a specific verb and resource: debug table structure, and repeatedly scopes it to inspecting table dimensions, cell positions, content, and insertion indices. This clearly distinguishes it from broader sibling tools like inspect_doc_structure and from related mutation tools like modify_doc_text.

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

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

It provides explicit triggering conditions, such as when table population puts data in wrong cells or when a 'table not found' error occurs, plus a workflow for verification before and after population. It does not explicitly state when not to use it or name a better alternative for overlapping structure inspection.

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 (non-read-only, non-destructive, non-idempotent, open-world), the description discloses forward-mode semantics — body becomes a prepended note, subject is optional, threading/reply/signature options do not apply — and the hard API limitation on scheduled send. It does not mention that repeated calls create duplicate drafts (relevant given idempotentHint=false), which is the one behavioral gap.

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?

Front-loaded with purpose and modes, then mode-specific rules, then the scheduling constraint; no filler sentences. The scheduling paragraph runs long and restates the limitation three ways, which costs a point.

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 19-parameter mutation tool with annotations and an output schema, the description covers the mode-dependent behavior an agent cannot infer from the schema alone. Minor omissions (duplicate-on-retry behavior, relative priority of thread_id vs in_reply_to) remain but the schema carries those details.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely new meaning: the interaction rules for forward mode (what body and subject become, which options become inert) that no single parameter description states in those terms.

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?

First sentence states a specific verb+resource ('Creates a draft email in the user's Gmail account') and the next sentences enumerate the modes (new, reply, forward, alias 'Send As'). An agent can immediately distinguish this from the sibling send_gmail_message, which delivers mail rather than saving a draft.

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 routes the agent: use forward_message_id to save a forward for review, use draft_gmail_message when scheduling time delivery, then send_gmail_message (or users.drafts.send) at the chosen time, or let the user schedule in the UI. It also names an exclusion ('SCHEDULED SEND IS NOT AVAILABLE') and warns against claiming scheduling succeeded.

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 declare destructiveHint=true, readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the description can add the promotion of the default-sheet fallback and hex/format conventions. However, it never warns that this mutation is destructive (merging discards values, clearing dropdowns removes checkboxes and other validation) and never explains the non-idempotent character, which are exactly the disclosures an agent needs for a format-write tool.

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

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

Two tight paragraphs, front-loaded with the operation and its capability scope, followed by format conventions. No filler, though the hex-format sentence is largely redundant with 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?

With 21 parameters, destructive annotations and an output schema, the description covers the overall operation and conventions well enough to call the tool. It is still incomplete on the risk side: nothing tells the agent that merges drop data or that clear_dropdown also strips checkboxes and other validation rules, which are the consequences most likely to cause harm.

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 schema already documents every one of the 21 parameters in detail. The description adds almost nothing beyond the schema: its hex-color and number-format-type notes restate what the parameter descriptions already say, and only the 'first sheet is used' fallback for range_name is genuinely new.

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

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

The first sentence names a specific verb (Applies formatting) and enumerates the resource and the formatting categories (colors, number formats, wrapping, alignment, styling, merging, borders, dropdowns). It is clear what the tool does, but it never mentions how it differs from nearby siblings such as manage_conditional_formatting or modify_sheet_values, so an agent must infer the boundary.

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 only implied by the enumerated capability list; there is no explicit when-to-use or when-not-to-use statement and no named alternative. The one scoping rule given ('If no sheet name is provided, the first sheet is used') is helpful but is a behavior, not a selection guideline.

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 readOnly, idempotent, non-destructive behavior, so the description needn't restate safety. It adds real value instead: the specific formatting preserved (headings, lists with nesting, tables), the default-on comment inclusion, and that anchor text is retained for context. It stops short of discussing large-document behavior or output size, which would matter for an 8-parameter reader.

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?

Front-loaded with the core action, then the sibling differentiation, then comment behavior — a sensible order with no filler sentences. There is mild redundancy between 'optional comment context' in the first line and the later 'When comments are included (the default)' paragraph, but nothing that costs an agent comprehension.

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, the description needn't explain return values, and annotations cover the safety profile. It adequately covers the three things an agent would otherwise have to guess: formatting fidelity, comment default behavior, and contrast with get_doc_content. Minor gaps around very large docs or tab-scoped reads (left to the schema) keep it from a 5.

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 each parameter already has a detailed description, so the schema carries the semantic load. The description adds only a light note that comments are included by default, which the schema's include_comments default already conveys. Baseline 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?

States a specific verb and resource ('Reads a Google Doc and returns it as clean Markdown') and immediately names the sibling it differs from, get_doc_content, along with the precise difference (plain text vs. preserved formatting). An agent can distinguish it without opening either 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?

Explicitly routes the agent between this tool and get_doc_content based on whether formatting matters, which is the key selection decision. It does not address other plausible siblings such as inspect_doc_structure or get_drive_file_content, so the guidance is clear but not exhaustive.

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

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

Annotations already declare readOnly/idempotent/openWorld, yet the description goes well beyond them: index alignment guarantees, U+FFFC placeholder conventions, body offset of 1, the n+1 mapping, and the caveat that alignment breaks at the first table or tab header. It also states what is excluded (comments, revision history, exact visual layout, hidden chip details).

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

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

Front-loaded with purpose and mode split, then the index-alignment contract, then the sibling pointer. It is dense and longer than typical, but nearly every sentence carries operational information; the offset arithmetic paragraph is verbose relative to its value.

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

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

For a five-parameter read tool with an output schema, the description covers the non-obvious risks an agent needs: which extraction path applies, the index-offset contract required for follow-up edits, and what content is unavailable. Nothing essential to correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning for preserve_context (readable link targets and object context at the cost of index alignment) and for how returned offsets map to document indices usable by format_text/delete_text. tab_id and suggestions_view_mode are left to the schema.

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

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

States a specific verb and resource ('Retrieves content of a Google Doc or a Drive file identified by document_id') and splits the two retrieval paths (Docs API vs Drive download/extract). It also explicitly routes formatting/comment use cases to get_doc_as_markdown, so the agent can separate it from the nearest 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?

Gives explicit guidance on when to set preserve_context=True and when to prefer get_doc_as_markdown, plus the caveat that offsets from preserve_context output must not be used for editing. It does not distinguish itself from the sibling get_drive_file_content for the '.docx in Drive' case, which is the one remaining routing ambiguity.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so safety is covered; the description goes further with genuinely useful behavior: export vs. unzip-and-parse vs. pypdf extraction, image returned as MCP image content, SVG base64 sub-images numbered to markup, and explicit fallbacks ('download hint') when extraction or page size fails. It does not mention error/failure modes (not found, permission denied) or what happens when full_content exceeds limits, keeping it short of a 5.

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

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

The core action is front-loaded in sentence one, then a scannable bullet list keyed by file type. Every bullet carries a distinct, non-redundant fact. Slight deduction for length and for awkward line-wrapped continuations inside the bullets.

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 tool with an output schema, rich annotations, and fully documented parameters, the description covers the one thing structured fields cannot: which file types are convertible and what the agent actually gets back for each. Missing error/auth details are minor given the annotation and output-schema coverage.

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

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

Schema description coverage is 100%, so the schema already carries offset, full_content, file_id and user_google_email semantics; baseline 3 applies. The description adds only indirect context via the repeated notion of 'default page size' and 'download hint', which hints at pagination but gives no guidance on choosing offset vs. full_content.

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 gives a specific verb and resource ('Retrieves the content of a specific Google Drive file by ID') plus a scope note about shared drives. The type-by-type breakdown makes the tool's remit unmistakable. It loses a point for never naming the adjacent siblings (get_doc_content, get_doc_as_markdown, get_drive_file_download_url) that an agent must choose between for Docs or link-style access.

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

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

Usage is only implied: the bullet list signals this tool spans Docs/Sheets/Slides/Office/PDF/images, letting an agent infer it can be used generically. There is no explicit statement of when to prefer this over get_doc_content, get_doc_as_markdown, or get_drive_file_download_url, and no prerequisites are stated beyond the email parameter. Adequate but leaves real routing ambiguity in a very crowded file/doc toolset.

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 substantial behavioral detail beyond the annotations: stdio saves to local disk, HTTP returns a temporary URL valid for 1 hour, stateless mode embeds the file up to configured byte limits, and Google native files are exported to specific formats. These are important operational traits an agent would not infer from the schema or annotations alone.

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?

Despite covering multiple deployment modes and export mappings, the description is well structured and front-loaded with the core operation. The mode-specific return behavior and export-format bullets each earn their place.

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

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

The tool has an output schema, so return values need not be exhaustively explained, yet the description still covers the key return modes. It also explains size limits and Google native export behavior, making the definition complete for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents the three parameters. The description adds useful semantic detail for export_format by mapping Google Docs, Sheets, Slides, and Drawings to their supported formats and defaults.

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

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

The description states a specific verb and resource: downloading a Google Drive file and returning either a local path, temporary URL, or embedded resource. It clearly describes the operation, but it does not differentiate itself from sibling tools such as get_drive_file_content or get_drive_shareable_link.

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

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

It provides clear context for when the behavior changes by deployment mode and by Google native file type, including export format behavior. It does not explicitly say when to prefer this tool over sibling download/content/link tools, but the intended use case is clear.

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

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

Annotations already 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 carry readOnlyHint, idempotentHint and destructiveHint, so the safety profile is covered. The description adds little beyond restating the read modes; pagination behavior, default time_min handling and recurring-expansion semantics are all disclosed in the schema, not here.

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, front-loaded with the primary action and then the alternate modes. No filler, though the second sentence is somewhat redundant with the first.

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 11 fully documented parameters, an output schema, and read-only annotations, the description only needs to orient the agent to the modes, which it does. Nothing critical is missing, though a note on pagination or recurring-instance behavior would round it out.

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 baseline is 3. The description calls out the optional query param for keyword search but adds no format details, defaults or precedence rules beyond what each parameter description 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?

States a specific verb (retrieves) and resource (events from a Google Calendar) and enumerates the three access modes: single by ID, range by time, keyword query. It does not explicitly contrast with siblings like manage_event or query_freebusy, 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?

Describes the modes of use (event_id vs time range vs query), which implicitly tells the agent how to pick parameters, but never says when to prefer this over manage_event or query_freebusy, and gives no exclusions or prerequisites beyond the email.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds real value beyond them: mode-dependent return behavior (stdio file path vs HTTP temp URL valid for 1 hour) and the side effect of re-fetching message metadata. It clarifies the otherwise-surprising readOnlyHint=false by explaining it writes to disk.

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, front-loaded sentences with zero filler. The core action comes first, followed by mode-specific return behavior. Every sentence earns its place.

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

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

With an output schema present, return values need not be explained, yet the description helpfully covers mode-dependent outputs. It is complete enough for correct invocation given 100% schema coverage and annotations; only user-facing routing 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 already fully documents all five parameters, making 3 the baseline. The description does not reference return_base64 or attachment_index directly, so it adds no 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?

States a specific verb and resource ('Downloads an email attachment and saves it to local disk'), which is unambiguous. It does not, however, differentiate itself from close siblings such as get_gmail_message_content or download_chat_attachment, so an agent still has to infer the boundary.

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 when-to-use vs alternative guidance and no exclusions. An agent is not told when to prefer this over reading the full message body or when attachment_index resolution is required, leaving routing 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 cover read-only, idempotent, non-destructive, and open-world behavior, but the description adds substantial context: attachments and attached messages are excluded, bodies are truncated at 20,000 characters, paging uses offsets and hash validation, and full=True switches to storage with either a short-lived download URL or file path depending on deployment. It also discloses the stateless-without-GCS fallback where full=True returns the body inline.

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 purpose, then covers paging, truncation, and full-export behavior. Its length is justified by the tool's stateful paging and deployment-dependent export modes, though some of the truncation and full=True behavior is repeated from 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?

Given the tool's complexity, 10 parameters, rich annotations, and output schema, the description is complete enough: it explains paging, truncation, full-message export, storage/download-URL behavior, and stateless deployment behavior. Return values themselves are left to the output schema, so no essential context is missing.

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

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

Schema coverage is 100%, so individual parameter meanings are already well documented in the schema. The description still adds value by explaining cross-parameter workflow: start page_offset at 0, follow next_offset until complete, pass body_sha256 as expected_sha256, and keep body_format and include_links unchanged across pages.

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: retrieving full content of a specific Gmail message, including subject, sender, recipients, and body. The purpose is clear, but the description does not explicitly differentiate this tool from siblings such as get_gmail_messages_content_batch, get_gmail_thread_content, get_gmail_attachment_content, or search_gmail_messages.

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

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

Provides operational usage guidance for paging via page_offset/next_offset and for full=True when the message is large or byte-exact fidelity is needed. However, it does not explicitly say when to use this tool versus sibling tools for batches, threads, attachments, or search, so tool-selection guidance remains implied rather than stated.

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

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

Annotations already declare the safe read-only, open-world, idempotent, non-destructive behavior. The description adds a meaningful operational constraint: batches are capped at 25 messages to prevent SSL connection exhaustion, which is useful behavioral context 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 two sentences, front-loads the tool's purpose, and follows with the batch-size constraint. Every sentence contributes useful information with no wasted text.

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

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

Given the rich annotations, complete input schema, and presence of an output schema, the description supplies enough context for correct invocation. It covers the batch purpose and the 25-message limit, though it does not discuss error handling or partial-failure behavior.

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

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

Schema description coverage is 100%, so all five parameters, including format, body_format, include_links, message_ids, and user_google_email, are already documented in the schema. The description adds only the batch-size context and does not need to carry parameter semantics here.

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

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

The description states a specific verb and resource: retrieving content of multiple Gmail messages in a single batch request. It clearly signals batch scope, distinguishing it from single-message retrieval, but it does not explicitly name or contrast with sibling tools such as get_gmail_message_content.

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

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

The word 'multiple' and the batch framing imply this tool is for fetching several messages at once, rather than single-message or thread retrieval. However, there is no explicit when-to-use guidance, exclusions, or named alternatives.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds genuinely non-redundant behavior: enabling include_analysis changes the return type to a dict with ownership analysis, which matters for callers writing downstream code. It does not cover pagination or size limits on large threads, keeping it below a 5.

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

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

Two short sentences, front-loaded with the core action, and the optional capability follows. The second sentence is slightly verbose ('without re-parsing the formatted string or making a second tool call') but it does convey the practical payoff, so nothing is wasted outright.

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, rich annotations, and 100% schema coverage, the description only needs to convey purpose and the conditional return-shape behavior, which it does. Residual gaps (large-thread behavior, attachment handling) are minor for a read-only fetch 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 all five parameters including the body_format enum and include_links are fully documented structurally. The description only restates the include_analysis outcome already present in the schema, adding little beyond baseline; a 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?

States a specific verb and resource ('Retrieves the complete content of a Gmail conversation thread, including all messages'), which implicitly separates it from single-message siblings like get_gmail_message_content. However, it never names a sibling or asserts the distinction, so differentiation is left to inference.

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 mention of getting ownership analysis 'without... making a second tool call' hints at when the include_analysis option is worth enabling. But there is no explicit guidance on when to use this thread tool versus get_gmail_message_content or get_gmail_threads_content_batch, which are both plausible alternatives in the sibling list.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive, open-world operation. The description adds useful operational context by noting the 25-thread batch limit and the reason for it: avoiding SSL connection exhaustion. It does not describe return shape, but an output schema exists.

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

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

The description is two tight sentences with no wasted language. The batch purpose is front-loaded, followed immediately by the important operational limit.

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 sufficient for calling the tool correctly given rich annotations, 100% schema coverage, and an output schema. Its main gap is contextual routing: it does not explicitly distinguish this batch thread reader from single-thread or batch-message 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?

Schema description coverage is 100%, so parameters such as body_format, include_links, and user_google_email are already fully documented. The description only reinforces the thread_ids batching behavior and the 25-thread limit, so it adds some value but not much beyond the schema.

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

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

The description states a specific verb and resource: it retrieves content for multiple Gmail threads in one batch request. It clearly implies a batch-oriented variant of thread retrieval, though it does not explicitly name the single-thread sibling get_gmail_thread_content or other message-search alternatives.

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

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

The batching language implies this tool is for retrieving multiple thread contents efficiently, and the 25-thread limit gives a practical usage boundary. However, it does not explicitly say when to choose this over get_gmail_thread_content, get_gmail_messages_content_batch, or search_gmail_messages, nor does it state 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, 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 readOnly/idempotent/non-destructive/openWorld, so safety is covered structurally. The description adds nothing behavioral: it does not mention that output shape varies dramatically with raw/include_styles/include_geometry, nor the token-cost implications of those flags. With full annotation coverage the bar is lower, but a bare restatement earns only a 2.

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

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

A single front-loaded sentence with zero padding, and the '(slide)' clarification is the one piece of information it needs to convey. It is efficient, though its brevity is close to under-specification rather than true 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?

An output schema exists so return values need not be explained, and the input schema is fully documented. Still, for a tool sitting next to get_presentation and get_page_thumbnail, the lack of any routing or prerequisite context leaves a real gap for correct invocation.

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

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

Schema description coverage is 100% and the flag parameters (raw, include_styles, include_geometry) have detailed, high-quality docs, so the schema does the heavy lifting. The description adds no parameter meaning beyond that, making the baseline 3 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?

States a specific verb and resource ('Get details about a specific page (slide)') and clarifies that 'page' means a slide, which is genuinely useful terminology mapping. However, it never distinguishes itself from siblings like get_presentation or get_page_thumbnail, so an agent must infer the boundary.

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 when-to-use guidance and no mention of alternatives. An agent cannot tell from the description whether to call this, get_presentation, or get_page_thumbnail for a given need, nor that it requires an existing page_object_id from another call.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context of its own — it does not mention that a summary is returned by default, that raw=True returns the full unfiltered resource, or anything about payload size.

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 short sentence with no waste and a clear lead verb. However, its extreme brevity means important scoping information is absent rather than merely condensed, so it is minimal rather than optimally structured.

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?

An output schema exists and annotations cover the safety profile, and 100% schema coverage documents every flag, so the agent can still call the tool correctly. The description nevertheless omits the tool's default summary-vs-raw behavior and its relationship to get_page, leaving a modest gap for a six-parameter read tool with several output-shaping flags.

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 six parameters (raw, include_styles, include_geometry, include_speaker_notes, presentation_id, user_google_email) are already fully documented in the schema, including cross-tool hints. The description adds nothing beyond the schema, which is the expected baseline 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?

States a clear verb+resource: retrieving details of a Google Slides presentation. It does not differentiate itself from siblings such as get_page (single slide), create_presentation, or batch_update_presentation, leaving the agent to infer the boundary from context.

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

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

The description gives no when-to-use guidance, no alternatives, and no prerequisites. Some routing hints exist (e.g. 'prefer get_page with raw=True for a single slide') but they live in the schema's parameter descriptions, not the tool description, so the description itself contributes nothing.

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.