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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the call fails on duplicate tab names, what permissions are required, whether the new tab's ID is returned, or what happens to a spreadsheet that already has many tabs — all meaningful gaps for a mutation tool.

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

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

A single front-loaded sentence with no waste. It is efficient, though its brevity contributes to gaps elsewhere rather than being 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?

For a mutation tool with no annotations and no output schema, the description leaves too much unspecified: permission requirements, failure modes, and result shape are all unaddressed. Only the basic purpose is covered.

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 schema already documents both 'title' and 'spreadsheetId' (including the URL/ID parsing hint), so the baseline of 3 applies. The description adds no parameter detail beyond the schema.

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

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

States a specific verb and resource ('Adds a new tab') with the scope qualifier 'to an existing spreadsheet'. It is clearly distinguishable from create_spreadsheet or rename_tab in intent, though it does not explicitly name a sibling.

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

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

There is no guidance on when to use this versus rename_tab, create_spreadsheet, or delete_tab, and no prerequisites (e.g., the spreadsheet must already exist and be writable). Usage is only implied by the verb.

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?

No annotations are provided, so the description carries the full burden. It does disclose the most important behavioral trait for an append tool: rows land after the last occupied row and existing data is preserved. However, it says nothing about permissions/auth, return payload, partial-append failure behavior, or how trailing blank rows are treated.

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 operation and followed by the differentiator. Nothing redundant and no wasted framing.

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 4-parameter, 100%-documented schema with no output schema and no annotations, the description covers the core append semantics adequately. Minor gaps remain around return value expectations and failure/partial-write behavior, but nothing critical to invoking 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 description coverage is 100% and the schema already documents range, values, spreadsheetId, and the RAW/USER_ENTERED enum. The description's only nod to parameters is the loose phrase 'the given table', adding no format or encoding detail beyond the schema, 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?

Specific verb+resource ('Adds rows') with a precise placement rule ('after the last occupied row of the given table'). It implicitly separates itself from overwriting siblings like write_range or update_row via 'without touching what is already there', but never names a sibling explicitly.

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

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

'This is the safe way to insert new data without touching what is already there' gives a clear selection criterion: use it when you want additive inserts rather than replacement. It stops short of naming an alternative (e.g. write_range) or stating when-not to use it, so it is clear context without explicit routing.

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

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

With no annotations, the description carries the full burden. It does disclose a real behavioral trait — this is a destructive mutation that preserves formatting — which is genuinely useful beyond structured fields. However it omits permission requirements, reversibility/undo behavior, and what happens to formulas, so it only partially covers the mutation's 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?

Two short sentences, zero waste, and the preservation constraint ('formatting intact') is packed into the first sentence before the destructive warning. Nothing to trim.

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 destructive mutation with no annotations and no output schema, the description covers the essential 'what is destroyed / what is preserved' but leaves out permissions, undo behavior, and edge cases like formulas or empty cells. Adequate but with 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 description coverage is 100%, so both parameters (spreadsheetId, range) are fully documented in the schema, setting the baseline at 3. The description adds no additional detail about range syntax or ID handling, so it neither helps nor hurts.

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 ('clears the values of a range') plus a scope constraint ('leaving formatting intact') that meaningfully distinguishes it from write_range and update_cell. It does not name any sibling explicitly, so it stops short of full 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?

No when-to-use guidance at all. It never says when to prefer clearing over write_range with empty values, nor any prerequisites. The agent gets the what but not the when.

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?

With no annotations provided, the description carries the full burden. It usefully discloses the return value (ID and URL) and the location (user's Drive), which goes beyond the schema, but omits anything about permissions/scopes required or side effects of creating a file.

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 efficient sentence with no filler, front-loading the action and then the return value. Appropriate for a two-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 creation tool with full schema coverage and no output schema, the description covers the essential action and explicitly names what is returned (ID and URL). Only minor gaps remain, such as required auth scope.

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 the title and tabs parameters are already documented in the schema. The description adds no parameter-level syntax or default details beyond what the schema 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 states a specific verb (Creates) and resource (a new spreadsheet in the user's Drive), which is clear and distinguishable from the range/tab manipulation siblings. It does not explicitly name alternatives, but the create-vs-modify distinction is inherent in the verb.

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, no prerequisites, and no mention of alternatives such as add_tab for adding tabs to an existing file. An agent must infer that this is the entry point for new files.

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?

With no annotations, the description carries the full burden and does it well: states permanence, the recovery path (version history), and the confirm=true requirement. These are exactly the behavioral traits an agent needs to avoid accidental data loss.

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: action + permanence, recovery constraint, and confirmation requirement. Front-loaded with the destructive nature; 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?

For a destructive no-annotation tool with no output schema, the description covers what matters: irreversibility, recovery path, and confirmation gating. Nothing essential for safe invocation is missing.

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

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

Schema coverage is 100% with rich per-parameter descriptions (title, confirm, spreadsheetId URL parsing), so the schema already documents parameters thoroughly. The description adds the confirm requirement contextually but doesn't exceed 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?

States a specific verb and resource: permanently deletes a tab and all its contents. This clearly distinguishes it from siblings like clear_range (which empties without deleting) and add_tab/rename_tab.

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?

Explains it is not reversible except via version history, and that explicit user confirmation should be obtained before calling. It implies when to use (intentional removal of entire tabs) but doesn't contrast with clear_range explicitly; that gap is minor given the destructive nature is front-loaded.

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?

With no annotations, the description carries the full burden and does well: it discloses the return shape (matching rows + absolute row numbers), the efficiency rationale versus read_range, and the chaining contract with update_row. It never states the operation is non-mutating, what happens on zero matches, or that results are capped, so it falls short of a full behavioral picture.

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 purpose then routing then chaining, with zero filler. Every sentence changes how the agent behaves.

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?

Covers purpose, when to prefer it, what comes back, and how to reuse the result — strong for a six-parameter read tool with no output schema. Minor gaps remain: the 50-row default/200 max cap and zero-match behavior are only discoverable from the schema.

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

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

Schema description coverage is 100% and each parameter (limit, query, where, sheet, headerRow, spreadsheetId) is already documented in the schema. The description only alludes to 'one or more criteria' without adding filter syntax, AND-combination, or default-limits context, 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 and resource ('finds rows matching one or more criteria') and explicitly says what is returned: only matching rows plus their absolute row numbers. It also distinguishes itself from the sibling read_range, so an agent can route without opening the schema.

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

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

Gives explicit selection guidance: 'Prefer this over read_range on long tables' with the reason (avoids pulling hundreds of irrelevant rows into context). It also names the downstream use ('The row numbers it returns can be passed straight to update_row'), covering the main alternatives an agent would weigh.

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?

No annotations are provided, so the description carries the full burden. It helpfully discloses what the response contains (tab dimensions, sheetId, file title), but says nothing about read-only safety, permissions, or pagination behavior on large spreadsheets.

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, front-loaded with the verb and resource, with the return payload appended economically. Nothing is wasted.

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

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

For a simple one-parameter read tool this is nearly sufficient: it compensates for the absent output schema by naming the fields returned, and the single parameter is fully documented in the schema. Only behavioral details like ordering or permissions are 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 explains the ID/URL format in detail. The description adds no parameter-level meaning beyond that, 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 (lists) and resource (tabs of a spreadsheet) and even enumerates the returned fields (dimensions, sheetId, file title). It is clearly distinct from the mutating siblings (add_tab, rename_tab, delete_tab), though it does not explicitly name them.

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

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

Usage is only implied: an agent can infer this is the read-only discovery step before calling read_range or update_cell. There is no explicit when-to-use, prerequisite, or alternative-tool guidance tying it to those siblings.

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

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

No annotations are provided, so the description carries the full disclosure burden. It discloses the read-only nature implicitly and the bare-tab-name expansion behavior, which is useful, but says nothing about return format, empty ranges, permissions, or large-range 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?

Two tight sentences, front-loaded with the core purpose and immediately followed by the non-obvious edge case. 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?

Adequate for a simple two-parameter read with full schema coverage, but with no annotations and no output schema, the description could disclose more about return shape or error behavior to fully equip the 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 coverage is 100% and both parameters are documented in the schema, including A1 examples and the spreadsheetId URL-derivation hint. The description's tab-name example overlaps with schema content without adding syntax beyond it, 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?

States a specific verb (reads), resource (range values), and format (A1 notation). The special-case behavior of passing a bare tab name is a precise, distinguishing detail that differentiates it from siblings like write_range or find_rows.

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

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

Usage is implied by the read semantics and the note about bare tab names, but there is no explicit guidance on when to use read_range vs alternatives like find_rows or list_tabs, nor any stated preconditions.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses one non-obvious side effect — that formulas referencing the tab are updated automatically — but omits permission requirements, what happens if newTitle collides with an existing tab name, and whether the rename is reversible.

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, zero filler, with the action stated first and the side-effect note following. 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?

For a simple three-parameter mutation with no output schema and no annotations, the description covers the action and one important side effect. The main remaining gap is conflict/error behavior when the target name already exists, which an agent would need to handle.

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 (spreadsheetId, currentTitle, newTitle) is already documented in the schema, including the URL-parsing detail for spreadsheetId. The description adds no additional parameter meaning, 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 and resource ('Renames an existing tab'), which clearly separates it from siblings like add_tab, delete_tab, and list_tabs even without naming them. It stops short of explicitly contrasting with those siblings, keeping it at a 4 rather than 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?

Usage is implied by the name and the phrase 'an existing tab' signals the precondition that the tab must already exist. There is no explicit when-to-use guidance, no naming of alternatives (e.g., when to rename vs. delete and re-create), and no stated failure 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?

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait — the write is narrowly scoped to one cell and cannot affect neighbors — which is genuine added value. However, it says nothing about permissions, whether the previous value is overwritten/destroyed, or what the response looks like, leaving gaps for a mutation tool.

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

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

Two sentences, zero filler, and the core purpose plus the routing hint are front-loaded. 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?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers purpose, scope, and the sibling routing decision well. It would be complete at 5 if it stated the mutation is destructive/overwriting or mentioned the success response, but overall it is adequate.

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

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

Schema description coverage is 100%, so all four parameters (cell, value, spreadsheetId, valueInputOption) are already documented with formats and enum semantics in the schema. The description adds no parameter detail beyond that, 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?

States a specific verb and resource ('Changes the value of a single cell') and immediately differentiates itself from the sibling write_range. An agent can tell exactly what this does and how it differs from the range-writing 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?

Explicitly names the alternative (write_range) and the condition that selects this tool (single-cell target), plus the reason (cannot touch surrounding cells). This is exactly the when-to-use guidance an agent needs.

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?

Without annotations, description carries full burden. It states the non-destructive scope (only named columns), which is valuable. However, it doesn't cover authentication needs, rate limits, error behavior, what happens if row/match not found, or reversibility. Some behavioral context is present but incomplete.

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 core behavior (partial column update), then the sibling contrast and row identification. Every sentence earns its place with no waste.

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 7 parameters, nested objects, and no output schema, the description covers the key behavioral trait (partial update) and row identification alternatives. It could mention what happens on missing row/match or the valueInputOption implications, but schema handles most parameter details.

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

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

Schema coverage is 86%, so schema already documents most parameters. The description adds meaning about row identification ('by number (from find_rows) or by matching a value in a column') and the partial-update semantics of 'updates'. This goes beyond the schema's per-field descriptions.

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

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

States a specific verb (modifies) and scope (only named columns, other columns untouched), and distinguishes itself from write_range by contrast. Siblings like update_cell and write_range are implicitly differentiated by scope description.

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 when to use this tool ('changing a status or fixing a field') and names the alternative (write_range) with the condition that selects it ('unlike write_range it does not overwrite the whole row'). No explicit when-not conditions, but the alternative contrast is clear.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it does disclose the critical destructive trait: existing data in the range is lost. It does not cover permission/auth requirements or the response shape, so it falls short of a full 5, but the most important risk is stated prominently.

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 packed sentences: behavior, warning, and alternatives. The destructive warning is front-loaded after the action, and every clause earns its place with zero 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 4-parameter write tool with no annotations and no output schema, the description covers the destructive overwrite semantics and sibling routing that an agent needs. It could optionally note return behavior or scope-limiting, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so range, values, spreadsheetId, and the valueInputOption enum are all documented in the schema itself. The description adds no parameter-level detail beyond that, which makes the baseline 3 appropriate.

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

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

States a specific verb and resource ('Overwrites the cells of a range') and immediately distinguishes itself from the two nearest siblings by naming them (append_rows for adding rows, update_row for editing a field). An agent can route correctly without opening any sibling 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?

Explicit when-to-use and when-not-to-use guidance: use append_rows to add rows at the end, update_row to change an existing field. This is the exact routing information needed among list_tabs/read_range/append_rows/update_row/clear_range siblings.

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