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

Annotations already declare destructiveHint=true and idempotentHint=true, covering the destructive and idempotent nature. However, the description adds no additional behavioral context, such as irreversibility, notifications to attendees, or effects on recurring event series. Since it contributes nothing beyond the annotations, the behavioral transparency burden is not advanced by the description.

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

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

The description is a single, direct sentence with no filler or redundant content. It is appropriately sized for a simple delete operation and front-loads the verb and resource, exemplifying efficient structure.

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 low-complexity: both required parameters are documented in the schema, and annotations convey destructive and idempotent behavior. The description is minimally sufficient for calling the tool correctly, but it lacks any usage context, side-effect notes, or guidance on edge cases (e.g., recurring events), leaving gaps that prevent a higher score.

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 eventId and calendarId are individually described in the input schema. The description adds no parameter-level information beyond the schema, so it appropriately relies on the schema; 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?

The description 'Delete a calendar event' uses a specific verb (delete) and resource (calendar event), clearly conveying the operation. It distinguishes itself from sibling read/update/create tools by specifying a single-event deletion, but it does not explicitly contrast with alternatives like calendar_events_update or calendar_events_insert.

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

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

No guidance is provided about when to use this tool versus calendar_events_update or calendar_events_insert, nor any mention of prerequisites such as event ownership, recurring-event behavior, or how to obtain the eventId. The description simply states the action with no conditional or alternative routing, leaving the agent to infer usage.

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 readOnlyHint and openWorldHint annotations already establish that this is a safe read operation with open-world semantics. The description adds only the 'single event' scoping but does not disclose return shape, error behavior, or external-change caveats beyond what annotations provide.

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

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

The description is a single sentence with no filler. It front-loads the action, resource, and identifying constraint, making it easy for an agent to parse 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?

For a simple read-only fetch with two fully documented required parameters, the description is nearly sufficient. It lacks explicit guidance about using list instead of get and does not describe the response, but those are minor gaps given the tool's simplicity and the 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%, with 'Event ID' and 'Calendar ID' already documented. The description does not add deeper meaning about ID formats, where to find the IDs, or relationships between the parameters, so it stays at the baseline.

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

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

The description states a specific verb ('Get'), resource ('calendar event'), and scope ('single ... by ID'), which clearly distinguishes it from sibling tools like calendar_events_list, insert, update, and delete. An agent can immediately understand what this tool does.

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 'by ID' implies this tool should be used when the agent already has an eventId and calendarId, but it does not explicitly mention when to prefer alternatives such as calendar_events_list. Usage context is only implied, not stated.

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

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

Annotations already indicate this is a mutating, non-idempotent, non-destructive operation. The description adds no further behavioral context such as invite email behavior, duplicate handling, or what the created event object contains.

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 clear, front-loaded sentence with no filler or redundant information. It efficiently communicates the core 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?

The schema and annotations cover parameter semantics and mutation safety, making this minimally viable. However, there is no output schema and the description does not mention return values or usage context, leaving some gaps for an agent.

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

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

Schema description coverage is 100%, with detailed parameter descriptions including JSON formats and enum meanings. The description itself adds no 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 states a specific verb and resource: 'Create a new calendar event.' This clearly separates it from update/delete/list operations, though it does not explicitly name or contrast sibling tools.

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

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

No guidance is given about when to use this tool versus calendar_events_update, calendar_events_delete, or calendar_events_list. There are no stated prerequisites or alternative conditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which covers the safety profile. The description adds no additional behavioral context such as pagination, default ordering, or return format. It is consistent with the annotations but does not enhance 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 with no filler. It is front-loaded with the core action and resource, making it immediately scannable and easy to parse.

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

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

With 7 parameters, no output schema, but strong annotations, the description is minimal. It does not explain the return format or how parameters like timeMin/timeMax interact, but the schema covers parameter semantics. The description is adequate for a straightforward listing tool, though it lacks depth.

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 description coverage is 100%, so all parameters are documented in the schema. The description does not add any extra meaning beyond the schema, and the baseline of 3 is appropriate given the high coverage.

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

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

The description clearly states the action (List) and the resource (events from a calendar), which is specific and distinct from siblings like calendar_events_get (get a single event) and calendar_events_insert (create). It is a precise verb+resource phrasing.

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

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

There is no guidance on when to use this tool versus alternatives like calendar_events_get or calendar_freebusy_query. The description only states what it does, leaving the agent to infer usage without any explicit context 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 establish readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description's main addition is the patch-semantics disclosure: 'only supplied fields change.' That is a useful behavioral trait, but the description does not mention significant side effects such as attendee-list replacement or update-email behavior, which are relevant for a mutation tool. No contradiction exists between the description and 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?

A single sentence that is front-loaded with the operation and resource and conveys the key semantic in a short parenthetical. There is no filler, repetition, or duplication of schema content.

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

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

The schema is rich and covers parameter meanings, required fields, enum values, and the sensitive attendees-overwrite behavior, so an agent can construct a correct call. However, the description itself is minimal: it does not describe the response (no output schema), permissions, or side effects such as the sendUpdates default, leaving an agent to rely entirely on schema 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?

All 8 parameters have schema descriptions (100% coverage), including a detailed warning about attendees replacement, so the schema carries the parameter-level burden. The description only adds the general patch rule 'only supplied fields change,' which contextualizes optionality but does not explain any specific parameter.

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

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

The description leads with the verb 'Update' and identifies the exact resource, 'existing calendar event,' so an agent knows immediately this modifies an event rather than listing, creating, or deleting it. Adding 'patch semantics' further distinguishes this from a full-replacement update and from sibling operations such as calendar_events_insert or calendar_events_delete.

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

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

It clearly situates the tool as the update operation for already-created events ('existing calendar event'), implying it should not be used for creation or deletion. It does not explicitly name alternatives or list exclusions, so it falls slightly short of full routing 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 annotations already declare readOnlyHint and openWorldHint, so the description only reinforces that this is a read-only availability query. It does not disclose extra behavioral context such as response shape, pagination, or whether external calendar data may appear, but the read-only safety profile is already covered by annotations.

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

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

A single, front-loaded sentence states the verb, resource, scope, and time constraint with no filler. Every part of the sentence earns its place.

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

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

For a read-only tool with four fully documented parameters and a short description, the core call is clear. However, the lack of usage differentiation from calendar siblings and the absence of any indication about the free/busy response format leave some gaps, especially since no output schema exists to fill them.

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

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

Schema coverage is 100%, with field descriptions for items, timeMin, timeMax, and timeZone including examples. The description adds the concept of querying multiple calendars, but the parameters' meaning and format are already well documented in the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb 'Query' with a clear resource: free/busy information for one or more calendars over a time range. This distinguishes it from calendar_events_get and calendar_events_list, which fetch event details rather than availability data.

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

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

There is no explicit guidance about when to use this tool instead of calendar_events_get or calendar_events_list. The agent must infer its role solely from the name and the one-line description, with no stated exclusions or alternatives.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds meaningful behavioral context by specifying that content can be 'permanently delete[d]', which goes beyond the generic destructive hint and warns the agent about irreversibility. It also discloses the range of mutating operations (insert, format, replace). 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?

A single concise sentence that front-loads the action and resource, followed by a parenthetical list of operation types. No filler or redundant phrasing; every word contributes to understanding.

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

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

For a 2-parameter mutation tool with annotations and full schema coverage, the description is nearly complete. It conveys the destructive nature and scope of updates. A minor gap is that it doesn't explicitly note that multiple updates can be applied in one batch (though the tool name and schema's 'Array of update requests' already imply this), and it doesn't mention any prerequisite like the doc being editable.

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 both parameters (documentId, requests). The description's mention of operation types provides general context for what `requests` may contain, but it does not add any concrete semantic detail beyond the schema, such as request structure or documentId format. Baseline 3 is appropriate.

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

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

States a specific verb ('Apply updates'), the resource ('Google Doc'), and enumerates specific operation types (insert, format, replace, delete). This clearly distinguishes from docs_get (read) and docs_create (create), and the 'Google Doc' resource separates it from Slides/Sheets batch update 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?

No guidance on when to use this tool versus alternatives. It does not mention that it's the tool to use for any Google Doc modification, nor does it mention docs_get or docs_create as alternatives for read/create operations. Usage context is only implied by the name and description, not explicit.

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

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

Annotations already declare readOnlyHint false and destructiveHint false, indicating a non-read-only, non-destructive action. The description adds no further behavioral context (e.g., that it creates a document in the user's Drive, or that no existing data is modified), but it does not contradict the annotations, so a 3 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, front-loaded sentence with zero unnecessary words. It clearly communicates the core action and resource, making it appropriately sized and easy to parse.

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

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

For a create operation with no output schema, the description fails to disclose the return value (e.g., the created document ID) or any side effects (e.g., saving to Drive). An agent would need to infer how to use the result, making this incomplete for a simple create 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%, with the parameter 'title' fully documented as 'Document title.' The description adds no additional meaning beyond what the schema already provides, so it meets the baseline for adequately documented parameters.

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

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

The description clearly states the verb 'Create' and resource 'a new empty Google Doc,' which is specific and distinct from sibling tools like docs_get (retrieve) and docs_batchUpdate (modify). An agent can immediately understand the tool's purpose without inspecting 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?

No guidance is given on when to use this tool versus alternatives such as drive_files_create or slides_create. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that both content and metadata are returned, which is useful, but it does not disclose output structure, pagination, or authentication requirements.

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

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

The description is a single efficient sentence with no wasted words. The action and target 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 one-parameter read-only tool with annotations covering safety, the description is nearly complete. It could specify what 'content and metadata' includes, but an agent has enough to select and invoke the tool correctly.

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

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

Schema coverage is 100% and the single parameter documentId is described as 'The document ID'. The description adds no further parameter guidance, so the schema carries the semantic load.

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

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

The description states a specific verb ('Get') and resource ('a Google Doc's content and metadata'), making the tool's basic purpose clear. It is distinct from mutating siblings like docs_batchUpdate and docs_create, though it does not explicitly contrast with similar getters like drive_files_get.

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

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

The read-only verb and resource give clear context for when to use this tool: when an agent needs a Google Doc's content and metadata. It does not mention alternatives or exclusion criteria, but none are necessary for such a straightforward getter.

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

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

The description adds meaningful behavioral context beyond the annotations: Drive stores the anchor as an opaque, unvalidated JSON string, and editor apps will still show such comments as unanchored. This is exactly the kind of non-obvious side-effect and limitation an agent needs.

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

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

Three sentences, each earning its place: a clear one-line purpose, a key parameter nuance, and an important caveat with an alternative. The most essential information is front-loaded and there is no filler.

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

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

For a create operation, the description, schema, and annotations together give the agent everything needed: required parameters, the anchor behavior, the visual limitation, and a pointer to better alternatives. No critical gap remains 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 baseline is 3. The description adds extra value by explaining the anchor parameter's semantics in depth: it is app-defined, opaque to Drive, not validated, and ignored visually by Workspace editors. It does not add anything about content or fileId, but the schema already covers those clearly.

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

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

The description opens with a specific verb and resource: 'Add a comment to a file.' It clearly distinguishes this create operation from sibling comment list/get/update/delete tools and even contrasts it with the Docs/Sheets/Slides APIs for anchoring.

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 states when this tool is appropriate and when it is not: use it for app-defined anchors, but use the Docs/Sheets/Slides APIs directly if visual anchoring in those editors matters. This gives the agent a clear decision rule versus a named alternative.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds valuable context: the author-only restriction and the permanent nature of the deletion. It also clarifies that the API rejects unauthorized requests, which goes beyond the basic annotation hints. No contradiction with annotations.

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

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

The description is two short sentences, front-loaded with the action and key constraint. Every word earns its place, with no filler or repetition.

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

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

For a simple delete operation with two parameters and no output schema, the description covers the essential behavioral details: permanence, authorization, and rejection. It doesn't mention side effects (e.g., deleting replies) or error handling, but given the tool's simplicity and annotation coverage, it is nearly complete.

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

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

Schema coverage is 100% and both parameters (fileId, commentId) have adequate descriptions. The tool description does not add any additional parameter-specific guidance beyond what the schema provides, 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 clearly states the verb 'delete' and the resource 'comment', making the action unambiguous. It also adds 'permanently' to clarify irreversibility, distinguishing it from soft-delete or update operations. While it doesn't name a sibling, the resource specificity is sufficient to differentiate from other delete tools.

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

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

The description provides a key prerequisite (only the author can delete) but offers no explicit guidance on when to choose this over alternatives like drive_comments_update or drive_comments_get. The usage context is implied by the resource and action, but no exclusions or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds no behavioral detail beyond the name—it doesn't mention how includeDeleted affects results or that fields is required. It neither contradicts annotations nor provides additional value.

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

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

A single, tight sentence with zero extraneous words. It is immediately scannable and front-loaded with the core 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?

For a simple read operation with full schema coverage and a read-only annotation, the description is minimally adequate. However, it lacks any mention of the response format or the effect of includeDeleted, and there is no output schema to compensate. It could benefit from a note about the returned comment object, but it is not severely incomplete.

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

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

Schema coverage is 100%, with all parameters (fileId, commentId, fields, includeDeleted) described in the schema. The description adds no extra meaning beyond the schema, 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 clear verb ('Get') and a specific resource ('a single comment on a file'), which distinguishes it from sibling tools like drive_comments_list or drive_comments_create. It implies retrieval by IDs, though it doesn't explicitly name fileId and commentId; the schema provides those. This is clear but not exhaustive.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention that it is for retrieving a specific comment by ID, nor does it contrast with drive_comments_list for listing all comments. The agent must infer usage from the name alone.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safe, read-only nature is covered. However, the description adds no behavioral context beyond that—no mention of pagination, required fields, deleted comments, or that replies are separate.

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 filler. It states the verb and object directly and is appropriately sized for such a simple list 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?

The description is minimally viable: with full schema coverage and read-only annotations, an agent can likely invoke it correctly. However, there is no output schema and the description does not mention pagination behavior, the required fields parameter, or the boundary between comments and replies, leaving some context for the agent to infer.

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 provides 100% description coverage for all six parameters, so the baseline of 3 applies. The description adds no parameter-specific meaning, but it does not need to compensate for missing schema documentation.

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 operation ('List') and the resource ('comments on a file'). It does not explicitly distinguish this from drive_comments_get or drive_replies_list, but the verb and object alone are unambiguous enough 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?

No guidance is provided about when to use this tool versus drive_comments_get (single comment), drive_comments_create/update/delete, or drive_replies_list. The sibling list exists in the context, but the description itself offers no exclusions or routing hints.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable behavior: the overwrite semantics ('previous text is not retained') and an authorization requirement ('Only the comment's own author can update it — the API rejects the request otherwise'). This goes beyond annotations and directly informs the agent of side effects and failure conditions.

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

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

The description is four sentences, each earning its place: the core action is front-loaded, then overwrite behavior, then authorization, then a pointer to an alternative for resolved state. No fluff, well ordered.

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 no output schema, the description covers the main behavioral requirements (overwrite, auth, resolved state exclusion). It does not describe the return value, but that is not critical given no output schema and the tool's simple nature. It is complete enough for an agent to call it correctly.

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

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

Schema coverage is 100% — every parameter has a clear description (e.g., 'content' = 'New comment text', 'fields' = required response fields). The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: "Change the text of an existing comment." This clearly distinguishes it from siblings like drive_comments_create and drive_comments_delete. It also explicitly states what it does not do (resolved state), reinforcing its scope.

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

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

The description gives clear context: it's for updating an existing comment's text, and it explicitly points to drive_replies_create's action field for changing resolved state, which is a 'when not' guide. It also mentions the author-only requirement as a prerequisite, but does not explicitly contrast with other comment operations (e.g., create vs update). Still, the usage context is well implied.

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

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

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false). The description adds the conversion use case but does not disclose side effects such as creating a new file with a new ID or leaving the original unchanged, which would add value 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?

Two short sentences with no filler. The core action is front-loaded, and the conversion example earns its place by clarifying a common use case.

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 fully documents parameters and annotations cover safety, but the description omits return behavior and does not clarify how this tool relates to drive_files_export for conversion tasks. It is adequate for a simple copy operation 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?

Schema coverage is 100%, so the schema documents all five parameters. The description's conversion example adds slight context for mimeType, but it does not explain the parameters beyond what the schema already provides, matching the baseline 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 states a specific verb and resource ('Copy a file') and adds a concrete use case (converting markdown to Google Doc). It is clear, but it does not explicitly distinguish this tool from siblings like drive_files_export, so it falls 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?

'Useful for converting formats' gives an implied scenario for when to use the tool, but it does not name alternatives or state when not to use it. The guidance is present but not explicit enough to route an agent away from similar file operations.

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

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

Annotations already provide the safety profile (readOnlyHint=false, destructiveHint=false). The description adds the nuance that an optional local file upload is supported and that metadata should be supplied via bodyParams, which is useful but limited. It does not disclose side effects, permission requirements, or error/conflict behavior, but with annotations present the bar is lower.

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 with no filler. The primary action is front-loaded, and each clause adds useful information (creation, metadata via bodyParams, optional upload).

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

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

Given the tool has 5 parameters, no output schema, and only these annotations, the description is adequate but minimal. It explains the core purpose and upload option but leaves out potential guidance on parameter combinations, expected response format, or special handling of Google-native MIME types. Still, the schema and annotations carry enough for basic 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 documents all parameters. The description adds limited meaning by mentioning 'bodyParams' and the option to upload a local file, which maps to the uploadPath parameter. This is marginal, so a baseline of 3 is appropriate.

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

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

The description clearly states the action: 'Create a new file in Google Drive' with a specific verb and resource. It is distinguishable from sibling tools like drive_files_copy (copy), drive_files_update (update), and drive_files_delete (delete), and from docs_create/slides_create which create specific doc types.

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 hint about how to call the tool ('Use with bodyParams for metadata and optionally upload a local file') but does not specify when to choose this tool over alternatives like drive_files_copy or docs_create. No exclusions or alternative routing are mentioned, so guidance is only implied.

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

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

Annotations already provide destructiveHint: true and readOnlyHint: false. The description reinforces this with 'permanently,' adding the nuance of irreversibility. It does not contradict annotations, and it adds a small amount of behavioral context beyond what annotations state, though not substantial detail about side effects or auth requirements.

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

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

The description is a single, front-loaded sentence with zero filler. It conveys the core action immediately and is appropriately sized for a one-parameter tool.

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

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

For a simple delete operation with one parameter and annotations covering safety, the description is nearly complete. It mentions permanence, which is key. It omits details like permission requirements or error behavior, but these are not critical for basic usage, and the annotations fill the safety gap. Slight room for improvement in noting that deletion is irreversible (already implied) or that associated metadata is removed.

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

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

Schema coverage is 100% with a clear description for fileId: 'The file ID to delete.' The description adds no further semantic detail about the parameter, so it relies on the schema. Baseline 3 is appropriate given high coverage.

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

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

The description states a specific action and resource: 'permanently delete a file.' It clearly distinguishes this from siblings like drive_files_update, copy, export, and even drive_permissions_delete, since the resource and verb are explicit. The word 'permanently' adds specificity about the outcome.

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 explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While it's clear this is the delete operation for files, there is no mention of conditions like ownership or permission checks, nor whether a soft-delete alternative exists. It is minimally sufficient but lacks routing context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and scope. The description adds valuable context about return types (text vs base64) and export behavior for Google-native files, going beyond the annotations without contradicting them.

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

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

Two sentences with clear front-loading of the main purpose. However, 'plain text by default' is somewhat redundant with the schema's stated default, and the sentence about Google exports could be tightened without losing meaning.

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

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

The description covers the main return scenarios (text, binary, Google-native exports) and works with the annotations to form a fairly complete picture. However, it does not address the overlap with drive_files_export, leaving an agent uncertain about which tool to use in that case. No output schema exists, so description bears the burden of explaining return values, which it does for the core cases.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description's mention of 'plain text by default' and binary/base64 behavior adds only marginal context that mostly echoes the parameter descriptions. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a clear verb+resource ('Download a file's content from Google Drive') and specifies return behavior for text, binary, and Google-native files. It differentiates from list/get tools but does not explicitly distinguish itself from the sibling drive_files_export, which also handles exporting Google-native formats.

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 when-to-use or when-not-to-use guidance. It mentions exporting Google Docs/Sheets/Slides, which overlaps with the sibling drive_files_export, but does not explain when to choose one over the other. No alternatives or exclusions are named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that it returns JSON with export metadata, which is useful, but it doesn't disclose details like whether the export is asynchronous, size limits, or what happens with unsupported formats. With annotations covering the read-only nature, a 3 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?

Two sentences with no waste. The core action is front-loaded, and the alternative tool is mentioned in the second sentence. Every word earns its place.

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

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

For a simple two-parameter read-only export tool with full schema coverage and annotations, the description is nearly complete. It could mention that the returned JSON contains a download URL or similar, but the output schema is absent and the description says 'export metadata,' which is sufficient for an agent to understand the return value.

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 both parameters. The description adds the context that the file is a Google Workspace file and that mimeType is the export format, but it doesn't add meaning beyond what the schema provides. Baseline 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 clearly states the tool exports a Google Workspace file (Doc, Sheet, Slide) to a specific format, and explicitly distinguishes it from drive_files_download. The verb 'Export' plus the resource and format scope make the 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 explicitly says to use drive_files_download for automatic export with content returned inline, which tells the agent when to choose the alternative. This is a clear when-to-use vs. when-not-to-use distinction.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate that the tool is read-only. It adds value by specifying the operation (metadata retrieval) and the shared drive support, which is not captured in the annotations. No contradictions exist between the description and annotations.

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

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

The description is extremely concise, consisting of two short sentences with no superfluous content. It front-loads the core action and follows up with a useful supplementary detail. Every word earns its place, making it highly scannable for an AI agent.

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

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

The tool is a simple get-by-ID operation with two parameters (one required, one optional) and no output schema. The description is sufficient for an agent to understand what the tool does and how to use it, especially with the annotations covering the read-only nature. It does not explain the return format or default fields, but this is acceptable given the simplicity and the schema already documenting the optional fields parameter.

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 (fileId and fields) are already well-documented in the schema. The description does not add additional meaning beyond what the schema provides. The baseline score of 3 is appropriate because the schema carries the full burden of parameter documentation, and the description offers no extra insights.

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

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

The description clearly states the tool's purpose: 'Get a file's metadata by ID.' It specifies the action (get), the resource (file's metadata), and the key input (ID). This distinguishes it from sibling tools like drive_files_list (list files), drive_files_create (create), or drive_files_download (download content). The additional note about shared drive support further clarifies its scope.

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

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

The description implies the primary use case (fetching a single file's metadata by ID) and adds a relevant detail about shared drive files being supported automatically. However, it does not explicitly mention when to choose this over alternatives or provide exclusions. The context is clear enough for an agent to infer when to use it, given the sibling tool names, but it lacks explicit routing 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 and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral detail that shared drive files are included automatically, which is beyond what annotations provide. However, it doesn't mention pagination behavior or that results may be truncated without pageSize.

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

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

Three sentences with no waste. The core purpose is front-loaded, and the shared drive note is a useful addition. Could be slightly more structured but is appropriately sized.

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

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

For a read-only list tool with 100% schema coverage and no output schema, the description covers the essentials. However, it doesn't mention pagination behavior or that the response is a file list with nextPageToken, which an agent might need to know for complete retrieval. The shared drive inclusion note is helpful context.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds the 'q' parameter context and shared drive behavior, but doesn't add meaning beyond what the schema provides for fields, orderBy, or pageSize. Baseline 3 is appropriate.

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

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

The description states a clear verb and resource ('List files in Google Drive') and mentions search support via the 'q' parameter. It doesn't explicitly differentiate from sibling tools like drive_files_get or drive_files_download, but the listing intent is clear enough.

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

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

The description implies usage for listing files and mentions shared drive inclusion, but doesn't explicitly state when to use this over alternatives like drive_files_get or drive_files_download. No exclusions or alternative routing is provided.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds only the vague 'metadata or content' scope and does not disclose side effects, permission requirements, or how content replacement behaves.

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 or redundant phrasing. It communicates the core action 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 tool with five parameters and no output schema, the description is too thin. It does not explain how uploadPath interacts with existing content, what 'fields' controls, what the response contains, or any important behavioral caveats.

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 adds a rough grouping (metadata vs. content) that maps to name/mimeType versus uploadPath, but it does not enrich the meaning beyond what the schema provides.

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

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

The description uses a clear verb ('Update') and resource ('a file'), and it distinguishes the tool from create/delete/copy siblings by framing it as modifying an existing file's metadata or content. However, 'metadata or content' is broad and does not specify which metadata fields or content operations are included.

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 drive_files_create, drive_files_copy, or drive_files_delete. There is no mention of prerequisites, exclusions, or conditions that would route an agent to a sibling tool.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=false, so an agent knows this mutates and is not idempotent. The description adds no behavioral context beyond restating the action, such as implications of type='anyone', duplicate-permission behavior, or required scopes.

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 fluff or redundant details. Every word earns its place and the core action is immediately visible.

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 create-permission tool with complete schema coverage and informative annotations, the minimal description is mostly adequate. However, it omits significant context such as the public-sharing implication of type='anyone' and does not clarify what happens on success or when a permission already exists, leaving the agent to infer these from schemas alone.

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 well documented in the schema. The description adds no extra parameter semantics beyond the relationship between 'file' and 'permission', meriting the 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 uses a specific verb ('Share') and resource ('file') plus the object of the action ('permission'), making the core purpose clear. It does not explicitly contrast with siblings like drive_permissions_transferOwnership, but 'creating a permission' sufficiently separates this from list/update/delete operations.

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

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

The phrase 'Share a file by creating a permission' implies the primary use case: granting access to a file via a new permission. However, it provides no explicit guidance about when not to use it or when to prefer related siblings such as drive_permissions_update or drive_permissions_transferOwnership.

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 destructive and non-read-only behavior, so the bar is lower. The description adds value by specifying the access-removal effect and a non-obvious API constraint: concurrent permissions operations on the same file are not supported and only the last update applies. 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?

Two sentences with no filler: the first front-loads the core action, and the second adds an essential concurrency caveat. 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?

The tool is simple: two required fully documented parameters, no output schema, and annotations already carrying destructive/idempotent/open-world semantics. The description is sufficient for an agent to invoke it correctly, and the concurrency caveat is the only non-obvious context needed.

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 fileId and permissionId. The description adds no additional parameter-level meaning and does not need to, given the baseline of 3 for high schema coverage.

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

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

The verb 'Revoke' plus the object 'a permission from a file' states exactly what the tool does, and the consequence 'removing that user's/group's/domain's access' makes the effect unambiguous. This clearly distinguishes it from drive_permissions_create, drive_permissions_update, and drive_permissions_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 no explicit guidance on when to use this tool versus alternatives like drive_permissions_update or drive_permissions_create. The concurrency caveat is behavioral, not usage direction; the only usage hint ('get it from drive_permissions_list') lives in the schema, not the 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 readOnlyHint/openWorldHint annotations, the description discloses real behavioral traits: the default response omits emailAddress/domain, and there is no separate is-public field so absence must be interpreted carefully. This helps the agent avoid incorrect conclusions about the data.

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

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

Three dense sentences with no filler. The core purpose is front-loaded, and each subsequent sentence adds practical guidance about auditing, interpreting fields, and constructing the fields parameter.

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

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

For a read-only list operation with one required parameter and supporting annotations, the description covers the key behavioral quirks and use cases. The lack of an output schema is mitigated by the clear 'list permissions' framing and the field-level detail already present.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value for the 'fields' parameter by giving an exact syntax example and explaining why it matters (identifying grantees). It does not add detail for fileId, pageSize, or pageToken, but those are adequately documented in the schema.

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

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

The description opens with a specific verb and resource: 'List all permissions on a file.' It further differentiates itself from sibling permission tools by framing the operation as an audit of sharing state, which is distinct from create/update/delete/transfer actions.

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 says to use this tool 'to audit sharing state' and gives a concrete scenario involving type 'anyone' for detecting public access. It does not explicitly name alternatives or when not to use it, but the audit framing clearly separates it from mutation tools.

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

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

The description goes far beyond the annotations by disclosing that this tool does not complete the transfer itself, that it sets role=writer + pendingOwner=true, and that the recipient must separately accept. It also warns about the non-disableable notification email and that nothing changes for the current owner until acceptance. This is rich behavioral context beyond the readOnlyHint=false and destructiveHint=false annotations, with no contradiction.

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

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

The description is long but every sentence carries essential operational or scoping information. It front-loads the primary purpose and the sibling alternative, then layers behavioral caveats and exclusions in a logical order. There is no filler.

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

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

For a nuanced ownership-transfer tool, the description covers when to use it, how the underlying API behavior works, required recipient action, email side effects, and all major unsupported cases. No output schema exists, but the description sufficiently explains the tool's behavior 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%, so the baseline is 3. The description adds useful semantic context for parameters: emailAddress must be an individual user (not groups, domains, or service accounts) and fileId cannot refer to a file in a shared drive. This goes beyond the schema's short descriptions.

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

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

The description states a specific verb and resource: proposing an ownership transfer of a Drive file, and explicitly distinguishes it from the sibling drive_permissions_transferOwnership. It also clarifies the personal/consumer account scope, leaving no ambiguity about what the tool does.

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

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

The description explicitly says to use drive_permissions_transferOwnership for same-organization Workspace transfers that complete immediately. It also provides clear exclusions: no transfers to accounts outside a Workspace organization, no groups/domains/service accounts, and no shared drive files. An agent knows exactly when to use this tool versus the alternative.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=false, and the description greatly enriches this by disclosing the immediate ownership change, downgrade of the current owner to writer, unavoidable notification email, and lack of an acceptance step. It also explains the shared-drive exclusion with rationale.

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 packed with decision-relevant details and wastes no sentences. It front-loads the core behavior, then covers exclusions, side effects, and the sibling alternative in a logical order.

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, non-idempotent operation with no output schema, the description covers the essential behavioral context: immediate effect, recipient notification, scope limitations, and alternative routes. It does not describe the exact response shape, but that is less critical given the transfer semantics are thoroughly disclosed.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces fileId and emailAddress constraints (same organization, My Drive only) but does not add new semantics for fields or moveToNewOwnersRoot beyond what the schema states.

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

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

The description states a specific verb and resource: immediately transfer ownership of a file to another Google Workspace account in the same organization. It also clearly distinguishes this from drive_permissions_proposeOwnershipTransfer by naming the alternative and contrasting immediate vs. acceptance-required transfer.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: only for files in "My Drive," only within the same organization, and not for shared drives. It also explicitly redirects to drive_permissions_proposeOwnershipTransfer for personal/consumer Google account transfers, leaving no ambiguity about selecting the right sibling 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 indicate destructiveHint=true and readOnlyHint=false, but the description adds valuable context beyond annotations: downgrading a role removes capabilities, ownership transfers are explicitly unsupported, and concurrent operations on the same file are not supported with only the last update applied. This surfaces real behavioral edge cases an agent must know. No contradiction with annotations.

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

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

Three sentences, all informative, with the core action front-loaded. No redundant phrases or filler. Each sentence adds distinct value: what the tool does, a capability caveat, and a concurrency warning. Perfectly sized for the tool's complexity.

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 rich annotations, the description covers purpose, limitations, destructive potential, and concurrency behavior. The schema handles parameter descriptions. There is no output schema, but none is needed for an update tool. 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?

Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds semantic value by explaining that role changes can downgrade capabilities, which clarifies the meaning of the 'role' enum values (e.g., reader to writer implies privilege hierarchy). It also illustrates usage with a concrete example. The permissionId sourcing is already in the schema, but the description's role semantics enhance parameter understanding.

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

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

The description opens with a specific verb+resource: 'Change an existing permission's role on a file (e.g. reader to writer)'. This clearly states what the tool does and differentiates it from permission creation, deletion, and ownership-transfer siblings. The explicit 'Ownership transfers are not supported' further disambiguates it from drive_permissions_transferOwnership and drive_permissions_proposeOwnershipTransfer.

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

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

The description implies when to use it: when modifying an existing permission's role. The 'Ownership transfers are not supported' statement tells the agent not to use this for transfers, implying a sibling should be used instead. The concurrency caveat also informs operational timing. It doesn't explicitly name create/delete as alternatives, but the core use case is clear enough from the description plus sibling names.

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

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

Beyond the annotations, the description discloses critical runtime behavior: resolving is advisory only, the API continues accepting replies, and the client must act on resolved=true. This is exactly the kind of non-obvious side effect that annotations like readOnlyHint=false 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?

Three sentences, all information-dense and front-loaded with the core purpose. The follow-up sentences explain the content/action relationship and the advisory resolution behavior without any filler or repetition of 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 absence of an output schema, the description still covers everything needed to invoke the tool correctly: required parameters are implied, the action/content interplay is explained, and the unusual advisory-only resolution behavior is disclosed. No significant invocation-relevant 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 the baseline is 3, but the description adds relational semantics: content is required unless action is set, both can be combined, and action mutates the parent comment's resolved field. This clarifies how the parameters interact beyond their individual schema descriptions.

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

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

The description opens with a specific action and resource: 'Add a reply to a comment, or resolve/reopen it.' It clearly differentiates the tool from comment-level operations by stating that resolution/reopening is only done through posting a reply with an action set.

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 states when to use this tool versus alternatives: 'a comment can only be resolved or reopened by posting a reply with action set.' It also gives the content/action precondition, telling the agent exactly when content is required and when action suffices.

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=true, so the description's 'Permanently delete' aligns with those. The description adds valuable behavioral context beyond the annotations: the author-only permission requirement and the fact that deletion is permanent. 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?

Two sentences with zero waste. The core action and the most important constraint (author-only) are front-loaded, and every word earns its place.

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

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

For a destructive delete tool with three required parameters and no output schema, the description covers the key behavioral facts: permanence and authorization. It does not mention idempotency or what happens if the reply is already deleted, but the annotations already cover idempotency, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (fileId, commentId, replyId). The description adds no parameter-specific detail beyond what the schema provides, which is acceptable given the high coverage. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Permanently delete'), a specific resource ('a reply'), and a critical scoping constraint (only the reply's own author can delete it). This clearly distinguishes it from sibling tools like drive_replies_update or drive_comments_delete without needing to inspect 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?

The description clearly implies when to use this tool: when a reply must be permanently removed, and it explicitly warns that the API rejects requests from non-authors. It does not explicitly name alternative tools or state when not to use it, but the author-only constraint provides strong usage context.

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

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

The readOnlyHint annotation already communicates that this is a safe, non-mutating operation, and the description aligns with that. However, the description itself adds little behavioral context beyond the schema, such as deleted-reply behavior or response characteristics.

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

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

The description is a single, compact sentence that gets straight to the point with no filler. It is front-loaded with the core verb and resource, making it easy for an agent to parse 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?

For a simple read operation, the description, schema, and readOnlyHint annotation cover the essential invocation context: required IDs are in the schema and safety is in the annotations. It does not explain the return value, but that gap is minor for a standard getter.

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 are already documented in the input schema. The tool description adds no additional parameter meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Get'), a resource ('a single reply'), and a scope ('to a comment'), which clearly identifies what the tool does. This also distinguishes it from drive_replies_list by focusing on a single reply rather than all replies.

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 explicit guidance on when to use this tool versus alternatives such as drive_replies_list, drive_replies_create, or drive_replies_update. The word 'single' implies a distinction from listing, but no when-to-use or when-not-to-use context is provided.

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

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

Annotations already declare readOnlyHint=true, which the description aligns with ('List' is read-only). However, the description adds no extra behavioral context such as pagination behavior, handling of deleted replies, or whether results are ordered. With annotations present, the bar is lower, but the description still contributes nothing beyond the core action, resulting in a baseline score of 3.

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

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

The description is a single, concise sentence that front-loads the verb and object. It is efficient with no wasted words. However, it is so brief that it borders on under-specification, though not verbose enough to lose more than one 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?

Given the tool has 6 parameters, no output schema, and involves pagination (pageToken, pageSize), the description does not mention listing behavior, pagination, or the structure of results. The schema covers parameter definitions, but an agent would benefit from knowing that this supports pagination and what 'deleted' replies mean. The description is adequate for a basic list operation but lacks contextual details that would aid correct invocation.

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

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

Schema description coverage is 100%, so all 6 parameters are documented in the schema. The description itself does not elaborate on parameter usage or relationships. Since the schema carries the full explanatory load, the description adds no value here, warranting the 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 a specific verb and resource: 'List replies to a comment.' This distinguishes it from siblings like drive_replies_get (which fetches a single reply) and drive_comments_list (which lists comments). However, it does not explicitly differentiate itself from related list operations, so it loses a point for not naming 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?

There is no guidance on when to use this tool versus alternatives. It does not mention that it requires a fileId and commentId, nor does it contrast with drive_comments_list or drive_replies_get. An agent must infer usage from the schema and tool name, which is insufficient for a tool with 6 parameters.

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

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

The description adds meaningful behavior beyond annotations: it discloses that the reply's content is overwritten and the previous text is not retained, and that only the reply's author can update it (API rejects otherwise). While annotations already flag destructiveHint=true and readOnlyHint=false, the description enriches this with concrete consequences and an authorization constraint. It does not cover rate limits or error details, but the key behavioral traits are disclosed.

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

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

The description is three sentences, each carrying distinct information: the main action, the destructive consequence, the authorization rule, and the non-capability with an alternative. It is front-loaded with the core purpose and has zero filler. Every sentence earns its place.

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

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

Given 5 parameters (4 required), full schema coverage, and no output schema, the description covers the critical operational details: the overwrite behavior, the author-only restriction, and the limitation regarding action changes with a routing hint. It does not mention return format (no output schema, so not required) or potential failure modes beyond the author rejection. This is a complete picture for an agent to safely invoke the 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 are already documented in the input schema (e.g., content: 'New reply text'). The description adds no additional parameter-level detail beyond what the schema provides. It does reiterate that content is the new text, but this is redundant. Baseline 3 is appropriate given the high schema coverage.

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

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

The description opens with a specific verb+resource ('Change the text of an existing reply'), immediately distinguishing it from sibling tools like drive_replies_get or drive_replies_delete. It also explicitly contrasts with drive_replies_create by stating it does not support changing action, so an agent can clearly tell when to pick this tool over 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 description provides a clear exclusion and alternative: 'Does not support changing action — use drive_replies_create to resolve/reopen.' This tells the agent when NOT to use this tool and routes to the correct sibling. However, it does not explicitly state the general condition for using this tool (e.g., 'use to modify reply text'), though that is strongly implied by the purpose statement.

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 mutation (readOnlyHint=false) and non-destructiveness, but the description adds important behavioral detail: the draft is NOT sent and must be reviewed/sent in Gmail. It also explains that passing threadId makes the draft appear as a reply, exceeding what annotations provide.

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

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

Two sentences carry all essential information—purpose, thread attachment behavior, and the non-sending caveat—with no fluff. The main action is front-loaded, and 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?

With 9 parameters, the schema fully documents each one, so the description need not restate them. It covers the key behavioral caveat (not sent) and the threading nuance. It does not mention the return value of the created draft, but since no output schema exists, this is a minor gap rather than a blocker.

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 semantic value by explaining the consequence of passing threadId (the draft appears as a reply in the thread), which goes beyond the schema's terse description of 'attach this draft to.' This incremental meaning justifies a 4.

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

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

The description opens with a specific verb and resource, 'Create a Gmail draft,' and immediately distinguishes this tool from sending by stating the draft is NOT sent. It also clarifies the threadId behavior, which differentiates it from any sibling creation tools like drive_files_create or calendar_events_insert.

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 guidance on when to supply threadId (to attach to an existing conversation) and explicitly states the draft is not sent, implying this tool is for draft creation only. It lacks an explicit alternative comparison because no other draft tool exists among siblings, but it conveys the core usage context well.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to reiterate that this is a safe read operation. However, the description adds no behavioral details beyond what annotations provide (e.g., response format nuances, potential errors). With annotations covering the safety profile, a score of 3 is appropriate—the description is consistent but does not enrich behavioral understanding.

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 conveys the core purpose efficiently. While it could benefit from a bit more detail, for a simple get operation it is appropriately concise and 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?

Given the tool's low complexity, full schema coverage, and read-only annotations, the description is largely sufficient. The only missing element is an indication of what the response contains (no output schema), but this is not critical for a standard message retrieval and is likely inferable from the tool's purpose. Overall, it is complete enough for an agent to invoke correctly.

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

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

The input schema describes all three parameters (id, format, userId) with 100% coverage, so the description does not need to add parameter details. The description itself offers no additional meaning beyond the schema. Baseline 3 is correct when the schema handles parameter documentation.

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'), the resource ('a single Gmail message'), and the key qualifier ('by ID'). This precisely differentiates it from siblings like gmail_messages_list (which lists multiple messages) and gmail_threads_get (which targets threads). An agent can unambiguously understand the tool's scope.

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

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

The description implies usage for fetching a specific message by ID, but it does not explicitly state when to choose this over gmail_messages_list or mention any exclusions (e.g., 'use gmail_messages_list to fetch multiple messages'). The intended context is clear from the tool's name and sibling set, but explicit guidance is absent.

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 readOnlyHint=true and openWorldHint=true, so safety and open-ended queries are known. The description adds nothing about pagination, response contents, or whether it returns full messages or summaries. Minimal added value 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?

A single sentence with zero redundancy. The action is front-loaded and the meaning is clear. Perfectly concise for the information it conveys.

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 4 parameters, all documented in the schema, and no output schema. The description doesn't clarify what the response contains (e.g., message summaries, pagination tokens), which could surprise an agent. Given moderate complexity and a list operation, more detail would help, but annotations cover the read-only nature.

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

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

All four parameters are fully described in the input schema (100% coverage), so the description need not repeat parameter details. The description doesn't mention parameters at all, but the schema carries that burden, 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 (List) and resource (Gmail messages) with a query condition. It is distinct from siblings like gmail_messages_get (singular) and gmail_threads_list (threads), though it doesn't explicitly contrast them. The core purpose is unambiguous.

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

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

No guidance on when to use this tool versus alternatives like gmail_threads_list or gmail_messages_get. There is no mention of use cases, prerequisites, or typical scenarios. The agent gets no direction on selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries a low burden. It adds the key behavioral detail that all messages in the thread are returned, which is useful. No contradictions with annotations. However, no additional side-effect or formatting details are provided beyond the schema.

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

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

A single sentence with zero wasted words. The verb, resource, and key scoping detail ('all messages') are front-loaded. Efficient and well-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?

For a simple read-only operation with full schema coverage, the description provides the essential context that the thread is retrieved in full. No output schema exists, but the return value is implicitly a thread with messages. Lacking only explicit notes on pagination or response size, which are minor for this 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 documents all three parameters (id, format, userId) with adequate descriptions. The tool description does not add meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('Get'), resource ('full Gmail thread by ID'), and scope ('all messages in the conversation'). This clearly differentiates it from gmail_messages_get (single message) and gmail_threads_list (listing threads). No 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 implies usage (when you need a full thread) but does not explicitly state when to use this over gmail_messages_get or gmail_threads_list. No exclusions or alternative guidance are provided, leaving the agent to infer based on the term 'full thread'.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not contradict them and the read-only safety profile is covered. However, the description adds no behavioral context beyond the core action, such as pagination, default when q is omitted, or ordering.

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

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

A single, front-loaded sentence with no filler words. It efficiently conveys the resource, action, and filtering behavior in a way that is easy to scan.

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

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

For a simple list tool, the description is mostly sufficient, especially with 100% schema coverage and read-only annotations. It still omits the relationship to gmail_messages_list and any note about default behavior when no query is provided, and there is no output schema describing the returned thread shape.

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 q, userId, and maxResults. The description does not add any parameter-level nuance beyond repeating that the tool matches a query, which keeps it at the baseline.

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

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

The description uses a specific verb ('List'), a resource ('Gmail threads'), and a filtering condition ('matching a query'), so an agent can tell this is the thread-listing operation. It is clearly distinct from gmail_threads_get and gmail_threads_modify, though it does not explicitly differentiate itself from gmail_messages_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?

There is no guidance about when to use this tool versus siblings like gmail_messages_list or gmail_threads_get, and no mention of exclusions, prerequisites, or typical query patterns. An agent must infer the intended use from the tool name alone.

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 (readOnlyHint=false), idempotency, and non-destructive behaviorhol. The description adds behavioral value beyond that by telling agents exactly how to achieve side effects like archiving and starring, which is useful operational context not captured in the annotations.

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

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

Three short sentences, zero filler. The purpose statement is front-loaded Illustration followed directly by the most useful examples. Every sentence earns its place.

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

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

For a simple label-modification tool with 100% schema coverage and meaningful annotations, the description covers the core operational context. It does not describe response values or mention that the modification applies to all messages in the thread, but the description and annotations together are sufficient 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%, so the baseline is 3. The description goes further by explaining the semantic meaning of specific label IDs ('INBOX', 'UNREAD', 'STARRED') and how removing or adding them accomplishes user goals, making the parameters more actionable than the schema alone.

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

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

The description opens with a specific verb-resource pair ('Modify a Gmail thread') and immediately narrows the scope to add/remove labels. This clearly distinguishes it from read-only siblings like gmail_threads_get and gmail_threads_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 practical usage context by mapping labels to common intents: 'To archive, remove INBOX. To mark read, remove UNREAD. To star, add STARRED.' It does not explicitly name alternatives or exclusions, but the examples effectively tell an agent when and how to invoke the 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 flag destructiveHint=true, but the description goes further by concretely explaining what destructive means: 'permanently delete content — e.g. removing a sheet or a conditional formatting rule — with no undo via the API.' This adds the crucial no-undo consequence and concrete examples, which annotations cannot 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 sentences with no filler. The first sentence front-loads the main purpose and examples; the second delivers the critical destructive warning. 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?

For a write tool with two fully documented parameters and annotations covering mutability and destructiveness, the description is largely complete. It covers the scope of requests and the key risk (permanent deletes). It doesn't describe the response shape or permission requirements, but since no output schema exists those are minor gaps for invoking the 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 both parameters are already documented and the baseline is 3. The description's examples of request types ('conditional formatting, cell/border formatting, adding sheets') give a sense of what goes in the `requests` parameter, but it adds no format, syntax, or additional semantics 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 opens with a specific verb and resource, 'Apply updates to a spreadsheet,' and lists concrete use cases (conditional formatting, cell/border formatting, adding sheets). This clearly distinguishes it from read-only siblings like sheets_get and from value-only tools like sheets_values_update, which focus on cell values rather than structural/formatting changes.

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 context for structural/formatting changes and mentions destructive operations, but it never explicitly states when to use this tool versus alternatives such as sheets_values_update for simple value writes. The guidance is inferable from the examples but not stated as a selection rule.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, lowering the bar. The description adds the metadata scope, which is consistent with a non-destructive read. It doesn't disclose behavioral traits like the potentially large payload triggered by includeGridData, but with readOnly coverage present, a 3 is fair.

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 waste. It is appropriately sized for a two-parameter read tool. Slightly more context could be packed in, but the brevity is not a structural flaw.

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?

Adequate for a simple read tool whose params are fully covered by the schema and safety profile is carried by annotations. The main gap is the absence of any note about includeGridData's return-size implications or what metadata fields are exposed, which an agent deciding whether to set includeGridData would want.

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 both spreadsheetId and includeGridData are already documented in the schema. The description adds only the word 'metadata,' which weakly hints that includeGridData switches output between metadata-only and raw grid values, but it doesn't compensate further. Baseline 3 is appropriate.

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

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

'Get spreadsheet metadata' states a clear verb and resource. It differentiates from the closest sibling, sheets_values_get, by signaling it returns metadata rather than cell values. However, it doesn't explicitly name the sibling or quantify the scope, so the distinction is implied rather than stated.

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

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

No guidance on when to use this tool versus sheets_values_get or sheets_batchUpdate. The sibling list is large and includes a values-getter, but the description offers no routing criteria such as 'use sheets_values_get when you need cell data.' Usage context is entirely implicit.

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

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

Annotations already indicate this is a write operation that is not destructive, and the description adds the crucial behavioral detail that data is appended after the last row. This conveys non-overwriting semantics beyond what annotations state.

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 nine-word sentence that is front-loaded and contains no filler. Every word contributes to understanding the core operation and its location.

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 adequate for invoking the tool because the schema covers all parameters, but it does not mention what the operation returns, how existing data is preserved, or when to prefer append over update. With no output schema, these are notable gaps.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description adds no additional parameter-level detail, making the baseline score of 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?

The description uses a specific verb ('Append'), a clear resource ('values...to a spreadsheet range'), and a distinguishing behavior ('after the last row'). This clearly separates it from sibling tools like sheets_values_update and sheets_values_get.

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

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

The phrase 'after the last row' gives clear context for when this tool is appropriate: adding new rows rather than modifying existing data. It does not explicitly name alternatives or exclusions, but the intended use case 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 declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds only that it reads values from a range, which is consistent with annotations but does not provide additional behavioral context such as response format or pagination. It does not contradict annotations.

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

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

The description is a single, concise sentence that front-loads the action and resource. It is appropriately short with no wasted words, though it could have added a small amount of contextual detail without becoming verbose.

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

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

For a simple read operation with annotations covering safety and a complete schema, the description is sufficient. There is no output schema, so return values need not be described. Minor gaps like how majorDimension affects output are already covered by the schema. The description is adequate for an agent to call the tool correctly.

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

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

The input schema has 100% coverage for all four parameters, so the schema already documents them. The description itself adds no parameter-specific meaning beyond what the schema provides, which is acceptable given the high schema coverage.

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

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

The description states a clear verb ('read') and resource ('values from a spreadsheet range'), which distinguishes it from write operations like sheets_values_update and sheets_values_append. However, it does not explicitly contrast with sheets_get, which likely retrieves spreadsheet metadata, so the differentiation from that sibling is implicit.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention that it is for reading only, nor does it reference siblings like sheets_get or the update/append tools. An agent would have to infer the appropriate context from the name and schema.

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

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

Annotations already communicate that this is a mutating, idempotent, non-destructive operation. The description adds no behavioral context beyond 'Write values', such as whether existing cell content is replaced, how valueInputOption affects behavior, or how values are interpreted. It neither contradicts nor enriches 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 extremely concise: a single clear sentence with no filler or repetition. It is well front-loaded, though so sparse that it carries very little information beyond the tool name.

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 write operation with multiple required parameters and a nontrivial valueInputOption, the description is too incomplete. The agent still does not know that writing replaces the range, how values should be formatted beyond the schema, or when this tool is preferable to append. The schema covers parameter names but not the operational semantics needed 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?

The input schema already describes all four parameters with 100% coverage, so the baseline is 3. The description itself does not add any parameter-level meaning beyond what the schema provides.

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

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

The description states a clear action ('Write values') and a clear resource ('a spreadsheet range'), so an agent knows the basic operation. However, it does not explicitly distinguish this from the sibling sheets_values_append, which also writes values in some sense, so it misses the meaningful contrast between overwriting a range and appending.

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 sheets_values_append or sheets_batchUpdate. The description only states what it does, not when it should be chosen or what constraints apply.

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 destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is known. The description adds a valuable specific behavioral fact beyond the annotations: 'Delete requests in a batch are permanent — the API has no undo.' This clarifies the permanence of deletes, which is more concrete than the generic destructive hint.

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

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

Two sentences with no filler. The primary purpose is front-loaded, and the permanence warning is a critical behavioral note that earns its place. It is easy to parse quickly and contains only valuable 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 mutation tool with 2 parameters and no output schema, the description covers the essential call context: what the tool does and the key risk (permanent deletes). It does not mention return values or partial-failure behavior, but given the annotations already cover the safety profile and the schema covers the parameters, the gaps are relatively minor.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by enumerating what kinds of requests can be placed in the 'requests' array (insert/update/delete slides, text, shapes, tables), which helps the agent construct a valid request body. This exceeds the generic schema description 'Array of update requests as JSON string'.

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 ('Apply updates') and a clear resource ('a presentation'), and enumerates concrete update types (insert/update/delete slides, text, shapes, tables). It clearly distinguishes this from read-only siblings like slides_get and slides_create by positioning it as the mutation entry point.

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 context of when to use this tool is clear: it is the content-mutation tool for presentations. However, it does not explicitly exclude adjacent cases, such as updating file metadata via drive_files_update, nor does it name alternatives. It earns a 4 rather than a 5 because the exclusions are left 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 indicate readOnlyHint=false and idempotentHint=false, so the mutation behavior is covered. The description adds the 'blank' qualifier, which clarifies the initial content, but provides no additional behavioral details about side effects, return values, or permissions.

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

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

The description is a single, front-loaded sentence that directly conveys the core action and result with zero filler. Every word earns its place.

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

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

For a one-parameter creation tool with annotations covering the safety profile, the description is nearly complete for invocation. It lacks any mention of return value or post-creation behavior, but the operation is simple enough that this is a minor gap, not a correctness risk.

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

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

Schema coverage is 100% and the only parameter, 'title', already has a clear schema description. The tool description adds nothing beyond the schema about how the title is used, so it meets the baseline but does not elevate parameter understanding.

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: 'Create a new blank presentation.' It clearly differentiates this from sibling tools like slides_get, slides_batchUpdate, and docs_create by specifying the output is a blank presentation.

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

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

The description offers no guidance on when to use this tool versus alternatives such as drive_files_create or slides_batchUpdate. There is no mention of prerequisites, context, or exclusions; the only usage signal is implied by the action itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the scope of what is fetched (slides, layouts, masters, page elements), but it does not disclose return format, pagination, or any response limits. It adds some context beyond annotations without contradiction.

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

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

One sentence, directly front-loaded with the action and resource, with no filler. Every word contributes to the meaning.

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

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

Given a single required parameter, full schema coverage, and annotations indicating a read-only/open-world operation, the description covers the essential calling context. It stops short of describing the response structure, but that is a minor gap for a simple read operation.

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

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

Schema description coverage is 100% and the sole parameter, presentationId, already has a clear schema description ('The presentation ID'). The tool description does not add further semantic detail, so the schema carries the 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 names a specific verb ('Get'), a clear resource ('a presentation'), and enumerates the exact content scope ('slides, layouts, masters, and page elements'). This distinguishes it from siblings such as slides_pages_get and slides_batchUpdate 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 implies the tool is for retrieving full presentation structure, but it does not explicitly state when to prefer it over slides_pages_get or when not to use it. Usage context is implied by the resource scope rather than stated as 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 and openWorldHint=true, so the safety profile is covered. The description adds useful context by clarifying that the page can be a slide, layout, or master, but it does not disclose return format, error behavior, or other operational traits beyond what annotations already provide.

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

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

The description is a single, focused sentence with no filler. The core action and resource type are front-loaded, and the parenthetical enumeration of page types adds useful specificity without redundancy.

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

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

For a simple read-only GET operation with two fully described required parameters and annotations covering safety, the description is complete. An agent has enough information to invoke the tool correctly; no output schema exists, but the expected result is sufficiently implied by 'Get a single page'.

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 presentationId and pageObjectId are already described in the schema. The description adds no new parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the resource: a single page (slide, layout, or master) from a presentation. This distinguishes it from sibling tools like slides_get (which gets the presentation itself) and slides_pages_getThumbnail (which gets an image).

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

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

No guidance is provided about when to use this tool versus alternatives. The description does not mention slides_get for presentation-level access or slides_pages_getThumbnail for page thumbnails, leaving the agent to infer routing from the tool name and sibling list.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the description is not required to state safety. It adds that the tool returns a URL (not the image itself), which is a useful behavioral detail. However, it does not disclose any limitations, error conditions, or how the URL should be used, leaving some behavioral gaps 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, concise sentence that front-loads the action and resource. It has no wasted words and is appropriately sized for the tool's simplicity.

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 no output schema, so the description should ideally mention the return format (e.g., a URL string) and any constraints. It does mention 'image URL', which is some guidance, but it omits details about how the URL is delivered, possible error responses, or any required permissions. For a simple read-only tool with full schema coverage, this is adequate but not comprehensive.

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 four parameters (presentationId, pageObjectId, thumbnailProperties.mimeType, thumbnailProperties.thumbnailSize) are already described in the schema. The description adds no extra meaning about parameter usage, syntax, or relationships, so the baseline score of 3 applies.

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

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

The description clearly states the action (get) and resource (thumbnail image URL for a page), specifying it applies to slide, layout, or master. It is distinct from sibling tools like slides_get (which retrieves the presentation) and slides_pages_get (which retrieves page content), though it does not explicitly name these alternatives. The purpose is unambiguous.

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

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

No guidance is given on when to use this tool versus alternatives. The description does not mention typical use cases, prerequisites, or when to avoid it. An agent must infer from the name that this is for thumbnails only, but no explicit direction is provided.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false, and the description adds the critical cascade side effect: deleting a task list with assigned tasks also removes the originals in Docs/Chat Spaces. This is exactly the kind of behavior an agent needs to know before invoking.

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 with no filler: the action is front-loaded, and the only important caveat follows immediately. Every sentence earns its place.

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

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

For a one-parameter delete operation with destructive annotations and no output schema, the description covers the action and the only meaningful side effect. Nothing else is needed 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 schema already documents the only parameter with 100% coverage ('Task list ID to delete'), so the baseline is 3. The description adds no further parameter details, but none are necessary for a straightforward ID argument.

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 ('Delete'), a clear resource ('task list'), and the distinct deletion semantics among siblings. It is unambiguous against tasks_tasks_delete (tasks vs. task lists) and against tasks_tasklists_update/insert.

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

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

The description makes the use case obvious and does not risk confusion with the sibling list/get/update/insert tools. It does not explicitly say 'use this when you want to remove a task list, not a task,' but the resource name and operation make the intended usage clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that retrieval is by ID but does not disclose return shape, potential errors, or external-world caveats. It is consistent with the annotations and minimally transparent, but it contributes little 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?

A single, direct sentence with no filler. The verb, resource, and lookup key are all front-loaded, making it immediately scannable and easy for an agent to parse.

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

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

For a one-parameter, read-only getter with safety annotations, this is nearly complete: the agent only needs the task list ID, and the schema supplies the default-list special value. The only minor gap is the lack of any hint about the return object shape, which is not critical at this complexity.

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

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

Schema description coverage is 100%, and the schema already documents the tasklist parameter including the '@default' convention. The description merely echoes 'by ID' and adds no parameter-level meaning beyond what the schema provides.

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

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

The description uses a specific verb and resource, 'Get a task list by ID,' which clearly identifies a single-resource retrieval operation. It is distinct from siblings like tasks_tasklists_list, tasks_tasklists_insert, and tasks_tasklists_delete without needing to open 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?

The phrase 'by ID' implies the intended use case—retrieve one known task list rather than listing all—but it does not explicitly name alternatives or exclusions. An agent must infer when to choose this over tasks_tasklists_list; the guidance is only implicit.

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 matches the annotations: readOnlyHint=false, idempotentHint=false, destructiveHint=false. It does not add behavioral context beyond what the annotations already communicate, such as return behavior or side effects, but it also does not contradict them.

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

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

The description is a single clear sentence with no filler or redundant wording. It is appropriately sized for a one-parameter creation tool and front-loads the core action immediately.

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

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

For a simple create operation with one required parameter and complete schema coverage, the description is nearly sufficient for an agent to invoke the tool. The main missing piece is the return value, especially since there is no output schema, but this is not critical for a 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 only parameter, 'title', is documented in the schema as 'Task list title'. The description adds no additional parameter meaning, which is acceptable because the schema already fully covers the parameter.

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

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

The description uses a specific verb ('Create') and a specific resource ('task list'), making the operation unambiguous. It clearly distinguishes itself from sibling tools like tasks_tasklists_update, tasks_tasklists_get, and tasks_tasklists_delete by stating it creates a new 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 usage context is implied by the verb 'create' and the resource name, so an agent can infer it is the right tool when a new task list is needed. However, it provides no explicit guidance about when NOT to use it or which sibling alternative to choose in related cases.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation that may return partial results. The description adds the scope ('authenticated user's task lists') but doesn't disclose pagination behavior beyond what the schema's pageToken parameter already implies. 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?

A single sentence that is direct and front-loaded with the action and resource. No wasted words.

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

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

For a simple read-only list operation with no required parameters and full schema coverage, the description is nearly complete. It could mention that it returns only the authenticated user's lists, which it does, and the pagination is already covered by the schema. The lack of an output schema is not a gap since the description's job is not to document return values.

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

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

Schema description coverage is 100%, so both pageToken and maxResults are already documented in the schema. The description adds no additional parameter meaning beyond what the schema provides, 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?

The description states a specific verb ('List') and resource ('the authenticated user's task lists'), which clearly identifies the operation. It doesn't explicitly distinguish from sibling tools like tasks_tasklists_get, but the verb 'List' versus 'Get' and the plural 'task lists' make the distinction reasonably clear.

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

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

The description implies this is for retrieving the user's task lists, and the sibling context shows tasks_tasklists_get as the alternative for a single list. However, it doesn't explicitly state when to use this tool versus tasks_tasklists_get or tasks_tasks_list, leaving the routing decision mostly 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 indicate this is not read-only, not destructive, and idempotent. The description adds meaningful behavioral context by stating that only supplied fields change, which clarifies that omitted fields are preserved. This is useful partial-update semantics beyond what the annotations alone convey.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes: "Update" states the action, "a task list" states the resource, and the parenthetical adds critical partial-update behavior.

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 update tool, the description plus schema and annotations are sufficient for an agent to invoke it correctly: the required tasklist ID and optional title are documented, and partial-update behavior is stated. No return value is described, but the absence of an output schema makes this a minor gap rather than a blocking one.

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

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

Schema description coverage is 100%, with both `title` and `tasklist` already documented in the schema. The description's "only supplied fields change" adds useful context for how optional parameters behave, but it does not add per-parameter meaning beyond the schema.

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

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

The description states a specific verb and resource: "Update a task list", which clearly identifies the operation. It also adds the partial-update qualifier "only supplied fields change", distinguishing it from a full overwrite. It does not explicitly contrast with sibling tools like tasks_tasklists_insert or tasks_tasklists_delete, but the resource and action are 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 this tool is used to update an existing task list rather than create or delete one, reinforced by "only supplied fields change". However, it provides no explicit when-to-use guidance, exclusions, or pointers to alternative sibling tools such as tasks_tasklists_insert or tasks_tasklists_delete.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable behavioral context by clarifying that 'cleared tasks are not deleted but stop appearing in default list responses,' which explains the destructive nature is about visibility, not deletion. It also implies idempotency by describing a state change that would be consistent across calls, though not explicitly stated. This goes beyond the annotations without contradicting them.

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

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

The description is exceptionally concise—two short sentences that front-load the primary action and immediately clarify the non-deletion behavior. There is zero redundancy or unnecessary detail, making it highly scannable for an agent.

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