ShareWatch

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds specific behavioral detail beyond annotations: it returns content if accessible, otherwise returns a grant link. It also mentions resolving against the Drive API and the file_name_hint usage. This enriches the agent's understanding without contradicting annotations.

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

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

The description is three sentences, each earning its place: the first specifies when to use, the second explains the dual outcome, and the third gives an actionable hint. It is front-loaded with the trigger condition and avoids redundancy. Highly concise 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?

Given the tool has an output schema (not shown) and schema coverage is complete, the description does not need to detail return structures. It covers the essential behavior (access resolution, content or grant link) and even links to API docs. It lacks explicit authentication notes, but that is likely not needed for a read-only operation and is implied by 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%, so the baseline is 3. The description's explanation of file_name_hint ('so the picker can search for it') adds a subtle purpose clarification, but the schema already covers the parameter's meaning ('Used to pre-fill the file picker search'). Thus the description provides little additional value 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 the tool's purpose clearly: access a file when the user shares a Google Drive URL or asks to access a specific file. It specifies the resource (URL) and the verb (access). However, it does not explicitly distinguish from sibling tools like read_file or request_file_access, though the URL focus is implicit differentiation.

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

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

The description gives a clear trigger condition: 'When a user shares a Google Drive URL or asks you to access a specific file, use this tool.' It also explains behavior for accessible vs inaccessible files. It does not explicitly mention when NOT to use it or alternatives, but the context is clear enough for most cases. A brief note on when to prefer read_file or request_file_access would improve it.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the mutation profile is covered. The description adds that the response includes the new tab's sheetId, which is useful for subsequent calls. It doesn't discuss permissions or side effects beyond 'adding a tab,' but with annotations present, this is adequate.

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

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

Two sentences, front-loaded with the action and context, no 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 simple two-parameter mutation with annotations already covering side effects, the description covers the core need: what it does, when to use it, and what it returns. It doesn't discuss error conditions or required permissions, but those are not essential for this tool's 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%, so both parameters are documented in the schema. The description adds no additional parameter meaning beyond what's already in the schema, so 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 ('Add'), a resource ('new tab'), and the target ('existing Google Sheet'). Combined with the name 'add_sheet_tab' and the phrase 'additional sheet after creation,' it clearly distinguishes this from create_spreadsheet and other 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?

Explicitly says 'Use this when you need an additional sheet after creation,' which gives a clear when-to-use context. It doesn't name alternatives or exclusion cases, but the scenario is specific enough for an agent to route correctly alongside tools like create_spreadsheet.

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, but the description adds critical context: blocking does not remove the file from listings, and there is no unblock tool (user must use the ShareWatch dashboard). This goes beyond annotations and fully discloses the irreversible gating behavior without contradicting any annotation.

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, front-loaded with the core purpose and trigger, then side effects and critical user guidance. No filler or repetition; every sentence adds value.

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

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

Given the tool's moderate complexity, full schema coverage, and an output schema, the description covers all essential aspects: what it does, when to use, what it doesn't do, and the lack of an unblock path. An agent has sufficient information to call it correctly and inform the user appropriately.

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 file_id and reason are already documented in the schema. The description does not add parameter-specific details beyond the schema; it only reiterates the purpose. Baseline 3 is appropriate since 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?

States a specific verb+resource ('Block MCP access to a file') and clearly distinguishes its effect from un-sharing or deletion by explaining it only gates access. It names the user-facing trigger (mistaken share or want access stopped), which differentiates it from sibling tools like delete_file or set_file_read_only.

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

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

Explicitly states when to use it (user shared by mistake or wants access stopped) and clarifies what it does not do (un-share) and that there is no unblock tool, with guidance to tell the user. However, it does not name alternative tools like delete_file or set_file_read_only, nor provide explicit when-not conditions, so it misses the full 5.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the write/additive nature is already known. The description adds substantial behavioral context beyond that: positioning happens via placeholders with no manual geometry, an unfilled two-column side renders as a blank box, and bullets wins over body/body_right when both are supplied. It stops short of describing auth/permission needs, so 4 rather than 5.

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

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

Front-loads purpose and sibling differentiation before the dense layout catalogue and workflow, and nearly every clause carries decision-relevant information. The layout→slots run-on (particularly the TITLE_AND_TWO_COLUMNS entry) is long and would read better as structured lines, which keeps it from a 5.

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 nested-content creation tool with 100% schema coverage and an output schema (so return values need not be explained), the description covers the remaining gaps: layout semantics, slot requirements, fill precedence, and the recommended verification workflow. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, setting the baseline at 3, but the description adds meaning the schema does not: a layout→slot mapping (TITLE = title + subtitle; SECTION_HEADER = title only; TITLE_AND_TWO_COLUMNS = left/right slots; BLANK = nothing) and precedence rules for bullets. This clarifies how the fields interact per layout rather than merely restating them.

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

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

States a specific verb+resource (create a Google Slides deck from a structured outline) and immediately distinguishes itself from the sibling create_presentation by noting it applies Google's own layouts rather than taking raw slides. The layout-based approach is spelled out concretely, so the agent can tell the two apart without opening either schema.

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

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

Explicitly routes the agent between alternatives ('Unlike create_presentation, which takes raw slides, this one applies Google's own layouts, so it suits decks meant to look designed') and provides a full workflow: build, then describe_slides to catch dropped content/overflow/overlap, then preview_slides for a visual check. When-to-use and follow-up tools are both covered.

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

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

The description discloses that the tool creates a new file and leaves the original unchanged, which is important behavioral information not present in the annotations. It also mandates asking the user, a procedural constraint. It does not describe failure modes or side effects beyond creation, but the annotations (readOnlyHint=false, destructiveHint=false) already indicate it's a mutating but non-destructive operation, and the description adds useful context on the new-file behavior.

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

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

The description is compact and well-organized: it starts with the core action, provides the format mappings, notes the non-destructive nature, and ends with a critical usage instruction. Every sentence contributes meaningful information without redundancy or filler.

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

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

For a simple one-parameter conversion tool, the description covers the essential behavior: what it converts, what the output is, and the prerequisite to ask the user. It does not explicitly state the return value, but the presence of an output schema (per context signals) likely covers that. Given the tool's simplicity and the existing schema coverage, the description is sufficiently 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?

The schema provides 100% coverage for the single parameter 'file_id' with its description. The description does not add further semantic detail about the parameter itself, only explaining the conversion behavior. With complete schema coverage, a baseline of 3 is appropriate; no additional compensation is needed.

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: converting Office/PDF files to Google-native formats, with explicit format mappings. It distinguishes from siblings like create_document or upload_file by focusing on conversion, and the mapping to specific target formats leaves 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 provides a clear usage context: when you need to convert an Office or PDF file to a Google-native format. It also includes an explicit 'ALWAYS ask the user before converting' instruction, which is a strong usage guideline. It does not explicitly mention when not to use or list alternatives, but the mappings and the safety requirement 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), and the description adds a genuinely non-obvious behavioral caveat that the annotations cannot express: incoming content arrives as literal plain text with ** and # preserved verbatim.

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

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

Three tight sentences, front-loaded with the action and followed by the caveat and the remedy. No sentence is redundant with the schema or annotations.

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

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

An output schema exists so return values need no explanation, and the description covers the one thing a caller could get wrong here: expecting Markdown to render. Nothing necessary for a correct call is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning for the 'content' parameter by specifying its plain-text treatment and giving the workaround for formatted output.

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

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

States a specific verb and resource ('Create a new Google Doc in the user's Drive') and immediately distinguishes the outcome from its sibling format_document, which an agent can act on without opening either schema.

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

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

Gives an explicit when-not ('Markdown is NOT rendered') plus the corrective workflow: create first, then call format_document for formatting. That is a named alternative with the condition that selects it.

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

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

Annotations already state readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds that the folder can be a default location for new files, which is useful behavioral context, but it says nothing about duplicate-creation on repeated calls, permission needs, or account scoping beyond what the schema covers.

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

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

Three short sentences, front-loaded with the core action, no padding. The third sentence is somewhat redundant with the schema's set_as_default description, which keeps it from a 5.

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

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

With annotations carrying the safety profile and an output schema handling return values, the description only needs to establish purpose and scope, which it does. Slightly thin on interactions with sibling tools (e.g., where the created folder lands relative to move_file), but adequate for a simple 4-parameter creator.

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 (name, account, parent_id, set_as_default) with good detail. The description only echoes the set_as_default capability, adding no syntax, format, or edge-case meaning beyond 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 gives a specific verb and resource ('Create a folder in Google Drive') plus an intent ('organize files'), so an agent immediately knows what it does. It does not distinguish itself from siblings such as move_file or upload_file that also touch Drive structure, 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?

'Use this to organize files' implies a use case but gives no when-not conditions and names no alternatives among the many sibling tools. Usage is inferable but 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, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only that slides are optional; it says nothing about account side effects, what happens on duplicate titles, or whether the call creates an empty deck when slides_json is omitted.

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. It is arguably too terse for a mutation tool with three parameters, but there is no wasted text.

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

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

An output schema exists, so return values are covered, and the schema documents all parameters. The remaining gap is the missing relationship to build_presentation and update_presentation, which an agent needs to select correctly among these near-identical siblings.

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

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

Schema coverage is 100% and each parameter is documented in the schema, including the layout enum list and the account-selection rule, so the description needn't carry that load. It adds only the word 'optional' for slides, giving no meaning beyond the schema - the baseline 3.

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

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

States a specific verb and resource ('Create a new Google Slides presentation') plus scope ('with optional slides'). It does not differentiate from the sibling build_presentation, and the only hint of a relationship lives in the slides_json schema field rather than the description itself.

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 when-to-use guidance, no prerequisites, and no routing between this tool and build_presentation, preview_slides, or update_presentation, all of which sound applicable to the same task. The agent must guess whether 'create' precedes or replaces 'build'.

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, idempotentHint=false, and destructiveHint=false, so the mutation profile is covered. The description adds genuinely useful cross-parameter behavior: sheet_names_json creates multiple tabs and data_json targets the first tab. It omits any account/auth or side-effect context beyond that, so a mid-range score is appropriate.

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

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

Two short sentences, front-loaded with the core action and followed immediately by the key cross-parameter constraint. No filler or restated boilerplate.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description covers the essential tab/data interaction, though it is silent on account selection and any failure modes for a 5-parameter mutation 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 baseline is 3. The description reinforces how data_json and sheet_names_json interact (data_json writes to the first tab), which is also stated in the schema, but adds no syntax or format guidance beyond it.

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

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

Opening sentence gives a specific verb and resource ('Create a new Google Sheet'), which distinguishes it from siblings like create_document and create_presentation. However, it never explicitly names an alternative or clarifies scope beyond the resource type.

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

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

There is no when-to-use guidance or when-not-to-use guidance. The second sentence describes parameter behavior (multi-tab creation), not usage context, so an agent gets no help deciding between this and create_document or upload_file.

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

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

Annotations already include destructiveHint: true and readOnlyHint: false, but the description adds valuable context: 'this cannot be undone' and the mandatory user confirmation step. It discloses irreversibility and a required pre-call action, going beyond what annotations state. No contradiction with annotations.

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

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

The description is a single, tightly-worded sentence that front-loads the primary action and immediately follows with the critical confirmation requirement. Zero wasted words; every clause serves a purpose.

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

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

For a one-parameter destructive tool with an output schema, the description fully covers what an agent needs: the operation, the irreversibility warning, and the required user confirmation. No missing behavioral or usage information that the schema or annotations wouldn't already provide.

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 describes file_id as 'The file ID to delete' with 100% coverage. The description adds no additional parameter-specific meaning beyond confirming the deletion target. Per calibration, baseline 3 is appropriate when schema fully documents 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 explicitly states the action ('Permanently delete') and the resource ('a file from Google Drive'). It clearly distinguishes from siblings like move_file or set_file_read_only, which are non-destructive operations. The verb 'delete' plus 'permanently' makes 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 provides a clear usage precondition: 'ALWAYS confirm with the user before deleting'. This tells the agent when it is appropriate to invoke the tool and implies it should not be used without user consent. However, it does not explicitly mention alternatives or when not to use it (e.g., for temporary changes), so it falls short of a perfect score.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds extra behavioral context by stating 'Cheap (no image render)' and describing the geometry-level readback including overflow, overlap, and sub-legible font flags. This goes beyond 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 compact sentences, each earning its place: the first defines exactly what the tool produces, and the second explains the cost/use-case tradeoff and names the alternative. The information is front-loaded and entirely relevant, with no padding 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 read-only inspection tool with one fully documented parameter and a declared output schema, the description covers every piece an agent needs: what it returns (geometry, text, flags), typical usage, and the alternative for a different need. Nothing about the tool's operation is left ambiguous.

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

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

The input schema covers the only parameter (presentation_id) 100% with a clear description. The tool description adds no additional meaning to the parameter beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Inspect the layout of every slide without rendering images.' It clearly states what is inspected (position, size, text, overflow, overlap, font legibility) and explicitly names preview_slides as the sibling for the final visual pass, making it easy to tell apart from the closest alternative.

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

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

The text gives explicit guidance: use this tool to catch mechanical layout problems while editing, and use preview_slides for the final visual pass. This is a clear when-to-use/when-not-to-use directive that names the alternative tool and the condition that selects it.

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

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

Annotations already signal destructiveHint=true and readOnlyHint=false. The description adds that passing file_id replaces an existing document's content and that omitting it creates a new doc, which clarifies what side effect may occur. It also lists the markdown constructs that get rendered. It does not mention irreversibility or permission requirements, but the destructive annotation already covers the safety profile.

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

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

Three tightly written sentences with no filler. The core action and formatting scope are front-loaded, followed by sibling guidance and the create-vs-replace behavior. Every sentence earns its place.

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

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

Given the high schema coverage, presence of an output schema, and clear annotations, the description covers the essential decisions: what the tool does, when to use it over siblings, and how file_id changes the operation. No critical guidance 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 description coverage is 100%, so all four parameters are documented. The description mostly repeats the file_id behavior and markdown feature list already present in the schema, and it adds no new meaning for title or account. This matches the baseline for high schema coverage.

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

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

The description states a specific verb and resource: 'Write markdown content into a Google Doc with full formatting' and enumerates supported formatting (headings, bold, italic, bullets, numbered lists, links, horizontal rules). It also explicitly distinguishes itself from create_document and update_document, so an agent can tell what this tool is for.

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

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

The description directly says to use this tool 'instead of create_document or update_document when the content has structure that should be visually formatted.' It also gives a concrete decision rule: pass file_id to replace existing content, or omit to create a new doc. This is explicit, actionable 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, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral context beyond annotations: it explains that setup problems are reported clearly here versus surfacing as unrelated failures elsewhere, and that it identifies which account the connector uses when multiple are configured. 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 well-structured and concise. It front-loads the core purpose, lists the reported fields, then explains the diagnostic value and the multi-connector behavior. Each sentence contributes meaningfully 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?

Given zero parameters, an output schema, and safety annotations, the description is complete. It covers what the tool reports, why it's useful for troubleshooting, and the edge case of multiple connectors. No critical information is missing 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?

The tool has zero parameters, so the schema provides no parameter semantics. The baseline for 0 parameters is 4, and the description doesn't need to add parameter details. It appropriately focuses on the tool's purpose and output.

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 ('Report') and resource ('ShareWatch setup status') and lists the exact fields returned (email, connection status, default folder, org membership, available actions). It also distinguishes itself from sibling tools by explaining that setup problems surface here clearly rather than as unrelated failures, making its 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 provides clear context on when to use this tool: to diagnose setup issues and identify the authenticated Google account when multiple connectors exist. It contrasts its behavior with other tools ('whereas they surface in other tools as unrelated-looking failures'), which implies when to prefer it, though it lacks an explicit 'use this instead of X' exclusion.

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

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

Annotations already convey readOnly, idempotent, and non-destructive traits. The description adds crucial behavioral context beyond annotations: the access model, per-file sharing semantics, folder behavior, and the fact that an empty list does not mean an empty Drive. This is exactly the kind of nuance an agent needs.

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

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

The description is longer than a typical one-liner, but every sentence earns its place by preventing a specific misinterpretation or unsafe user-facing claim. The core scope is front-loaded, and the caveats are progressively layered 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?

The description covers scope, interpretation, folder-sharing behavior, and practical user guidance, and an output schema exists to document return structure. There are no obvious gaps that would prevent an agent from using this tool correctly.

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

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

The tool has zero parameters and schema coverage is 100%, so parameter-level documentation is unnecessary. The description still adds value by explicitly listing the returned fields (file IDs, names, types, URLs, parent folder IDs), maintaining the baseline of 4 for parameter-free tools.

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: 'List the Google Workspace files ShareWatch can see.' It immediately distinguishes this from the user's Drive, which clearly separates it from siblings like search_files and avoids ambiguity about the tool's narrow 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 provides strong interpretive guidance: never claim a file doesn't exist based on this list, and direct users to open the folder in the picker if folder contents are missing. However, it does not explicitly name alternative sibling tools like search_files or when-not scenarios, so it stops 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the agent knows this is a destructive, idempotent operation. The description adds the accessibility requirement ('Both the file and destination folder must be accessible to ShareWatch'), which is useful context beyond the annotations. However, it doesn't disclose what happens to the file's sharing permissions or whether the move is reversible, which would be valuable for a destructive operation.

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 wasted words. The core action is front-loaded, and the accessibility constraint is stated concisely. 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 two-parameter tool with a full output schema and annotations covering safety, the description is nearly complete. The only gap is that it doesn't explain what happens to the file's sharing settings or permissions after the move, which could matter in a file-management context. But given the schema and annotations, this is a minor omission.

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 in the schema. The description adds no additional parameter-level detail beyond what the schema provides, so the 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 ('Move') and resource ('a file into a different folder'), which clearly distinguishes it from siblings like delete_file or upload_file. It doesn't explicitly name a sibling alternative, but the action is unambiguous.

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

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

The description implies when to use it: when you need to relocate a file to a different folder. It doesn't explicitly state when not to use it or mention alternatives like copy or rename, but the context is clear enough for an agent to select it for a move operation.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful detail that it returns rendered PNG thumbnails of each slide, and 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?

Three short sentences with no filler: action, output format, and use case are each addressed. The most decision-relevant phrase 'thumbnail images' appears first, and every sentence earns its place.

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

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

With a single parameter, full schema coverage, rich annotations, and an output schema, the description covers everything needed to select and invoke the tool correctly. The visual-check use case adds the final piece of decision-relevant 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% for the single parameter, so the schema fully documents presentation_id. The description adds no additional parameter-level meaning, 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 action ('Get thumbnail images for all slides') and resource ('Google Slides presentation'), and clarifies the output ('rendered PNG images of each slide'). This clearly distinguishes it from siblings like describe_slides, which would focus on textual or structural content.

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

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

The description explicitly says to use it 'for a final visual check of layout and formatting', giving clear context for when to choose it. It does not name an alternative or provide when-not-to-use guidance, so it stops short of a 5.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important behaviors: export formats, size warning instead of content for large files, the need to chunk with max_chars/offset, the handoff code substitution and its 30-day validity, and the fact that the result reports the real file_id. This is substantial behavioral context that goes far 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 two concise paragraphs with no wasted words. The primary purpose is front-loaded in the first sentence, and the second paragraph addresses the handoff code without clutter. Every sentence contributes meaningful information, and the structure 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?

Given the tool's complexity (multiple file types, large-file handling, handoff codes, output schema), the description covers all essential aspects: what it reads, how output is formatted, how to paginate, and a special input mode. It also references the output schema implicitly by describing return behaviors. Nothing critical is missing 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 has 100% coverage with detailed descriptions for all four parameters. The description adds extra value by explaining how to combine max_chars and offset for chunking, the behavior when max_chars is omitted (server decides), and the specificity of the handoff code for file_id. This enriches the semantics, though the schema already does a good job.

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 reads text content from Google Docs, Sheets, and Slides, and specifies the export formats (plain text, CSV, plain text). This is a specific verb+resource that naturally distinguishes it from create/update/delete siblings and from describe_slides or preview_slides which serve different purposes.

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

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

It provides practical context such as handling large files with max_chars/offset and explains the handoff code behavior. However, it does not explicitly mention when to use this tool versus competing read-like alternatives (e.g., describe_slides for slide structure), so it lacks explicit exclusion guidance but still gives clear situational 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?

Annotations only indicate the tool is not read-only, not idempotent, not open-world, and not destructive. The description adds meaningful behavioral context beyond those flags: reports are written to the user's audit log, visible to workspace administrators, and recorded in ShareWatch's operational logs. It also clarifies scope boundaries, telling the agent to write about the tool, not the user's documents or conversation.

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

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

The description is longer than average, but it earns its length by front-loading the core purpose and then providing necessary exclusions and behavioral constraints. The five-item by-design list is verbose but valuable because it prevents misuse of the tool. It is well-organized and not redundant with the schema.

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

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

The description is complete for a bug-report tool: it states what to report, when to report it, what not to report, where the report goes, scope limitations, and where to find supplementary documentation. The output schema likely covers the return value, so the description does not need to explain it. An agent has everything needed to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents the tool, file_id, and description parameters well. The description reinforces the intent behind the description parameter (focus on the agent's experience, not user content), but it does not substantially add new semantic meaning beyond what the schema already provides. 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 opens with a concrete statement of purpose: 'Tell the ShareWatch developers what this server got wrong.' It clearly identifies the resource (ShareWatch's API/server behavior) and the action (reporting bugs and friction), and it is easily distinguished from sibling tools, which all perform file, document, or status 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 description is explicit about when to use the tool: for outright bugs and for friction such as confusing parameters or unhelpful errors. It also gives a detailed when-not-to-use list of five by-design behaviors, instructing the agent to explain those to the user instead of reporting them. This is strong usage guidance with clear 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 signal read-only, idempotent, non-destructive. The description adds user-mediated flow: returns a URL the user can open to grant access, making the deferral of action clear. It doesn't mention permissions or waiting behavior, but the key non-mutating behavior is disclosed.

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

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

Two sentences; first sentence gives the trigger condition and action, second gives the outcome. No filler.

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

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

With one optional parameter, readable output schema, and clear trigger condition, this is nearly complete. It does not mention what happens after the user grants access or that access may be delayed, but for such a simple tool the description covers the essential flow.

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?

One parameter is fully documented in the schema (100% coverage). The description adds no extra semantic beyond 'shown to the user', which is already in the schema, so baseline 3 is appropriate.

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

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

The description uses a specific trigger ('when a user wants you to access a file that isn't in the file list'), a clear action (call this tool), and states the outcome (returns a URL for the user to select and grant access). This clearly distinguishes it from siblings like access_file_by_url or list_files.

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

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

Provides an explicit when-to-use condition ('file isn't in the file list') and implies you should not use it for files already in the list, but does not explicitly contrast with alternative tools or state when not to use it.

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

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

Annotations already mark it read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds valuable behavioral context: searches are scoped to explicitly shared files, and a shared folder does not imply its contents are shared.

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

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

The description is compact and front-loaded with the main purpose, followed by differentiation and important scope caveats. Every sentence adds distinct value without unnecessary padding.

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

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

Given the rich schema, an output schema, and safety annotations, the description covers what an agent needs: purpose, when to use it, how to combine parameters, and the critical sharing scope limitation.

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 carries most parameter meaning. The description adds useful aggregate semantics by noting all parameters are optional and can be combined to narrow results, which goes beyond a simple restatement.

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

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

Description names a specific action (search), the object (files), and the dimensions (name, text content, type, date range). It also distinguishes itself from list_files, making it clear what this tool is for.

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

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

Explicitly says to use this instead of list_files when the user has many files or is looking for something specific. It also gives parameter-level guidance on when to use content search, which helps an agent choose the right approach.

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

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

The description adds substantial behavioral context beyond annotations: enforcement at the proxy layer regardless of Drive permissions, the one-way nature (only set to true), and the user-only revert path via ShareWatch Files page. This goes beyond the readOnlyHint=false and destructiveHint=true annotations, giving the agent a clear picture of side effects and reversibility.

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

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

The description is two sentences, front-loading the primary purpose and then providing essential behavioral details. Every sentence adds value with no redundancy, making it concise 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?

Given the tool's simplicity (2 params, both documented), the existence of an output schema, and the rich behavioral disclosure in the description, nothing an agent needs to correctly invoke and interpret the tool is missing. It covers purpose, constraints, enforcement, and reversal path.

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 file_id and read_only are already described in the schema. The description adds a minor clarification about the one-way behavior (already present in the schema's read_only description) but does not introduce new parameter-level meaning beyond that. 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 ('Mark'), resource ('file'), and state ('read-only'), and explicitly explains what read-only means ('can be read but not updated through ShareWatch'). This clearly distinguishes it from siblings like delete_file or block_file, which have different effects on file access.

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

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

The description clearly implies when to use the tool (to make a file read-only) and provides a crucial usage constraint: 'read_only=false is refused'. However, it does not explicitly compare to alternatives (e.g., block_file for full blocking) or state when not to use it, so it stops short of full guidance.

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

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

Beyond the destructiveHint annotation, the description clarifies exactly what destructive means: 'replace' clears and replaces all content. It also discloses useful runtime behavior: the result reports the mode actually applied and character count, with a clear warning to confirm a replace was a replace. This adds genuine 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?

The description is three sentences with no wasted words. The main action is front-loaded, and the result-confirmation guidance is placed where it reinforces safe use without bloating the text.

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

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

Given the destructive annotation, 100% schema coverage, and the presence of an output schema, the description covers the key risk area: confirming which write mode was actually applied. Nothing essential for selecting or invoking the tool 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%, and the schema already documents mode defaults, case-insensitivity, validation, and content/document_id meanings. The description adds output-focused context rather than parameter semantics, 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 identifies the tool as updating an existing Google Docched, distinguishing it from create_document and other update tools by resource type. It specifies the two supported write operations, replace and append, which gives the agent a precise sense of 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 phrase 'existing Google Doc' implies this is not for document creation, and the replace/append distinction offers some contextual guidance. However, there is no explicit statement of when to prefer this tool over siblings like format_document or update_spreadsheet, nor any exclusions or prerequisites.

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

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

Annotations already include destructiveHint=true and readOnlyHint=false, but the description goes beyond by detailing rejection behavior ('REJECTED with a message naming the operation; nothing is silently skipped'), the flexibility of Google's spellings, and the direct mapping to BatchUpdatePresentationRequest. This prepares the agent for edge cases.

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

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

The description is well-structured with clear sections: purpose, operations list, examples, and raw mode. It is dense but efficient, with front-loaded purpose and examples that directly map to parameter usage. Every sentence adds value without redundancy.

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

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

Given the tool's complexity (supporting multiple operations and raw API access), the description is complete. It covers operation types with examples, error handling, the raw request alternative with a link, and the required parameter. The output schema is present, so return format details are not needed in the description.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description enriches the parameters significantly. It explains the operations_json format with detailed examples for each operation, clarifies the raw_requests parameter with a link to official documentation, and the required presentation_id is contextually obvious from the description.

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

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

The description states a specific verb ('Modify') and resource ('existing Google Slides presentation'), and lists the structured operations supported. It distinguishes from siblings like create_presentation and preview_slides by focusing on modification of existing presentations.

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

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

The description explicitly explains the two modes of operation (structured operations_json vs raw_requests) and when to use each, including that raw mode is for 'full API access'. It provides clear guidance on how to structure calls and notes that unrecognized types are rejected, preventing silent failures.

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

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

Beyond annotations (destructiveHint true), the description discloses the exact 'RAW' storage behavior, the fact that '=B1+B2' is stored as literal text unless USER_ENTERED is passed, the specific 'Unable to parse range' error mode, and the formula_notice result field. This is substantial behavioral context that annotations do not 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 front-loaded with the core purpose, then each sentence adds a distinct constraint or behavior. There is no filler or redundancy, and the most important caveats (tab existence, formula handling, error notice) are compactly presented.

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 existing output schema, 100% parameter documentation, and destructiveHint annotation, the description covers the remaining operational details an agent needs: prerequisites, failure modes, formula behavior, and result notice. 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 baseline is 3, but the description goes further: it explains that range must reference an existing tab, gives the error behavior when it doesn't, and clarifies the practical difference between RAW and USER_ENTERED beyond the schema text. It doesn't add new meaning to spreadsheet_id or data_json, so not a 5.

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

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

Description opens with 'Write data to a range in an existing Google Sheet', a specific verb+resource that clearly distinguishes it from sibling tools like create_spreadsheet, add_sheet_tab, update_document, and update_presentation. The mention of tab-qualified ranges and Google Sheets further scopes the tool.

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 tells the agent to call add_sheet_tab first when the target tab doesn't exist, which is a direct when/alternative statement. The phrase 'existing Google Sheet' and the tab-existence rule make it clear when this tool is appropriate versus creating a spreadsheet or adding a tab.

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, idempotentHint=false and destructiveHint=false, so the write, non-repeatable, non-destructive profile is covered. The description adds genuinely new behavioral facts the annotations do not carry: the 20MB decoded size ceiling and the effect of convert on stored format.

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

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

Three tight sentences, front-loaded with what is uploaded and where, followed by the selection condition and the size ceiling. 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?

With an output schema present, return values need no explanation, and the description covers format support, base64 input, conversion and the size limit. The only soft spot is that it does not mention auth/permission requirements for writing into the user's Drive.

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

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

Schema description coverage is 100%, so all six parameters including account, convert, mime_type and content_base64 are already documented. The description restates the convert and 20MB constraints without adding syntax or format detail beyond the schema, which is the expected 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?

States a specific verb and resource ('Upload a binary file ... to Drive from base64-encoded content') and names the accepted formats and the source of the bytes. It is clearly distinguishable from siblings like convert_to_google_format or create_document.

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

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

Gives a clear usage trigger ('when you have file bytes from the conversation ... and need to put them in the user's Drive') plus the convert=true condition for Office formats. It stops short of naming alternatives such as access_file_by_url or convert_to_google_format for URL-sourced or post-upload conversion cases.

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