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

The description provides no information about side effects (though it is clearly a read operation), return format, error handling, pagination, or other behaviors. Without annotations, the description carries the full burden, and it only states the basic action.

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

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

The description is one clear sentence with no unnecessary words. It immediately conveys the tool's function and scope.

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 batch read operation, the description provides the core context (multiple ranges, single request). However, it lacks details about the expected response structure, how ranges are formatted, or how valueRenderOption affects results—information that would help an agent use the tool effectively.

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 includes descriptions for spreadsheetId and ranges, but valueRenderOption lacks a description. Coverage is 67% (2 of 3 parameters), which is above the 50% threshold but below 80%. The existing descriptions are minimal but sufficient for those parameters.

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

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

The description clearly states the tool's purpose: to retrieve data from multiple ranges in a single request. It directly contrasts with the sibling tool sheets_get_data, which presumably handles a single range, making the batch nature explicit.

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?

While the description implies usage for fetching multiple ranges at once (as opposed to the single-range sheets_get_data), it does not explicitly state 'use this instead of sheets_get_data for multiple ranges'. The guidance is sufficient but not directly stated.

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

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

The description provides no behavioral details such as whether the batch is atomic, how partial failures are handled, or any authentication/permission requirements. With no annotations, this lack of transparency leaves the agent without critical information about side effects or error handling.

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

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

The description is a single, clear sentence that leads with the core action. It contains no extraneous words and is appropriately concise for the tool's 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?

The description omits essential context such as the permissible request types, the response format, or any constraints like maximum batch size. While the sibling tools and name imply a Sheets batch operation, the description alone is not complete enough for an agent to invoke it correctly without additional assumptions.

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 covers both parameters with basic descriptions, and the tool description adds no further meaning. The 'requests' parameter is still vague—its element structure is unexplained—but the baseline for high schema coverage is 3, and no additional insight is provided.

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 primary action—performing multiple operations in a single request—which is distinct from single-operation tools. However, it does not specify which operations are included, leaving some ambiguity about the tool's scope.

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

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

The only guidance is 'for better performance,' which implies batching but does not explicitly state when to use this instead of individual update tools. No comparison to alternatives like sheets_update_data or sheets_clear_range is provided, so an agent cannot easily decide when this is the appropriate choice.

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

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

The description implies a read-only calculation but does not explicitly state that no spreadsheet data is modified, nor does it mention return format or error behavior. With no annotations, the agent is left without important behavioral expectations.

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

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

The description is a single concise sentence with no extraneous words. It is appropriately short for the limited information provided.

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 no output schema and minimal description, critical context is missing: the agent does not know what the function returns, whether it returns a scalar value, or how formula references are resolved. This makes the tool difficult to use reliably.

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 lists spreadsheetId and formula, but the descriptions merely repeat the parameter names without adding meaning. There is no explanation of formula syntax, whether a leading '=' is expected, or what spreadsheet context is used for calculation.

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 verb 'Calculate' and the resource 'formula', so the basic purpose is identifiable. However, it does not clarify whether this evaluates a formula string in the spreadsheet context or returns a computed value, and it does not distinguish it from sheets_set_formula.

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

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

No guidance is provided on when to use this tool versus alternatives like sheets_set_formula or sheets_get_data. The description gives no context for when formula evaluation is appropriate, leaving the agent to guess.

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 burden. It transparently states the effect (clearing content and formatting) and implies no other side effects, which is sufficient for this simple operation, though it does not mention potential errors or 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 a single, short sentence that directly conveys the core purpose with no unnecessary words. It is optimally concise.

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

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

Given the simplicity of the operation and the absence of an output schema, the description is complete enough for an agent to understand what the tool does. It does not explain the response format or error handling, but those are implicit in the trivial nature of the action.

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 fully describes both parameters (spreadsheetId and range) with clear descriptions. The tool description adds no additional parameter details, so it meets the baseline for full schema coverage.

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

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

The description clearly states the action ('Clear content and formatting') and the resource ('a range'), which distinguishes it from other sheet operations like updating or formatting. It is specific and unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives (e.g., update_data or format_cells). While the purpose is clear, there is no guidance on scenario selection, leaving some inference to the agent.

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

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

There are no annotations and the description only says 'apply', revealing minimal behavioral detail. It does not disclose whether existing conditional formatting rules are replaced, merged, or how invalid ranges or rule conflicts are handled.

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

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

The description is a single, direct sentence with no filler or redundant wording. It is appropriately sized and front-loaded with the core action.

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

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

The description is too thin for a tool with six parameters, nested color objects, and no output schema. It lacks examples, rule-type behavior, effect on existing formatting, and color object structure, leaving significant gaps 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?

All top-level parameters have one-line descriptions, giving 100% schema coverage, but the descriptions are minimal. The nested textColor and backgroundColor objects have no property definitions, and value's dependence on ruleType is not explained.

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

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

The description clearly states the operation ('apply conditional formatting rules') and the target ('cells'). 'Conditional formatting' distinguishes this from sibling tools like sheets_format_cells or sheets_set_data_validation.

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

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

No guidance is given on when to use this tool versus siblings such as sheets_format_cells or sheets_set_data_validation. There is also no mention of when not to use it or any alternative approaches.

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 must convey behavioral details. It does not mention whether the source sheet is modified, if a copy is created in the destination, or any side effects. The operation's non-destructive nature is implied but not stated, and no return 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?

The description is a single, concise sentence that conveys the essential operation without unnecessary elaboration. It is well-structured and free of redundant content.

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

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

For a simple copy operation, the description is sufficiently complete. It does not mention return values or side effects, but given the lack of an output schema and the straightforward nature of the task, the information provided is adequate and no critical gaps are apparent.

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

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

All three parameters are covered by the schema with descriptions, achieving 100% coverage. However, the descriptions merely restate the parameter names ('The ID of the sheet to copy') without adding significant meaning. Since coverage is high, the baseline score of 3 is appropriate.

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

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

The description clearly states the action (copy), the resource (a sheet), and the target (another spreadsheet). It effectively distinguishes this from sibling tools like 'sheets_duplicate_sheet' (which copies within the same spreadsheet) and 'sheets_move_sheet'.

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

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

The description implies the use case (copying across spreadsheets) but does not explicitly contrast it with alternative tools. While the purpose is clear, there is no direct 'use this when' guidance, leaving some inference required.

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 full responsibility for disclosing behavior. It does not mention what happens on creation (e.g., returns a spreadsheet ID, opens a new file), side effects, or whether the tool is read-only or mutating. The phrase 'Create a new' implies a mutation but leaves specifics unstated.

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

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

The description is a single, concise sentence that efficiently conveys the core action and optional enhancements. It is well-structured but could benefit from breaking out key details about parameters or return values without sacrificing brevity.

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 large set of sibling tools, the description lacks context on how this tool differs from closely related ones (e.g., 'sheets_create_sheet' for creating a sheet within an existing spreadsheet). It also omits any output schema or return value details, making it incomplete for an agent to fully understand the tool's place and expectations.

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

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

All three parameters are described in the schema: title, theme, and initialData. However, the descriptions are minimal. 'initialData' is described only as 'Optional initial data' without specifying its structure or format, and 'theme' is an enum but its effect is not explained. The schema coverage is complete but shallow.

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

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

The description clearly states the verb 'Create' and the resource 'a new Google Sheets', but it does not specify whether this creates a spreadsheet or a sheet within a spreadsheet, which is ambiguous given the sibling tool 'sheets_create_sheet'. The mention of 'optional initial data and formatting' adds clarity but could be more precise.

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

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

No guidance is provided regarding when to use this tool versus alternatives like 'sheets_create_sheet' or 'sheets_create_chart'. There is no mention of prerequisites, scenarios, or limitations, leaving the agent to infer appropriate usage from the tool name alone.

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

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

With no annotations, the description carries the full burden. It does not mention side effects, permissions, or what happens to existing charts. It only states the action 'create charts', which is insufficient for transparency about the operation's impact.

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

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

The description is a single concise sentence without redundancy. It efficiently states the purpose and action, making it easy to parse.

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

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

The description is adequate for a simple create action but lacks details about the return value, success/error behavior, or any constraints. Given the existence of sibling tools, more context would help an agent choose correctly, but the description is not misleading.

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

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

All parameters are described in the schema (100% coverage). The descriptions are minimal but present, providing basic type and purpose. This meets the baseline for full schema coverage, though it doesn't add extra semantic depth beyond the schema.

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

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

The description clearly states the tool creates charts in Google Sheets, indicating the primary action and resource. However, it does not differentiate from the sibling tool 'sheets_create_chart_from_table', which also creates charts, so it lacks explicit distinction.

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

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

No guidance is provided on when to use this tool versus alternatives like sheets_create_chart_from_table or when a specific chart type is appropriate. The description only states the action without context.

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

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

There are no annotations and the description only states the high-level action. It does not disclose whether the tool overwrites existing charts, requires specific permissions, or has any side effects beyond creating a chart, leaving the agent without information about behavioral consequences.

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

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

The description is a single clear sentence that directly states the tool's purpose. It is concise with no unnecessary words or redundant information, making it easy for an agent to parse quickly.

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

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

With 6 parameters and a nested object, the tool has moderate complexity, but the description provides no context about the output, return value, or how to integrate this with other spreadsheet operations. The absence of an output schema and lack of usage guidance for a crowded sibling space leaves gaps in task completion 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?

All parameters have descriptions, so schema coverage is 100% (baseline 3). However, 'chartOptions' is defined only as 'Additional chart options' without explaining what options are valid or their effect, and 'useFirstRowAsLabels' is clear but could be more explicit about default behavior. No contradictions or missing parameters.

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

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

The description clearly states the action ('Create'), the object ('a chart'), and the specific input format ('from a table structure with headers and data'), which distinguishes it from sibling tools like sheets_create_chart_with_data or sheets_create_chart that might have different input expectations.

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

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

No guidance is provided on when to use this tool versus the many sibling chart creation/update tools. There is no mention of selection criteria, such as preferring this when data is already in a table layout or when needing headers as labels, which would help an agent choose correctly.

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 of explaining side effects, but it only says the chart is created and populated. It does not disclose whether an existing chart is overwritten, whether write access is required, or what output/response format to expect.

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

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

The description is a single, concise sentence with no unnecessary fluff. It is appropriately sized for the tool's purpose, though slightly vague in wording.

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

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

The tool has multiple parameters including nested objects and no output schema, but the description and parameter summaries do not explain how to construct position or chartOptions, nor what the tool returns. More context is needed 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?

All six parameters have short descriptions, covering 100% of the schema, but nested objects like position and chartOptions are only vaguely described. The descriptions add basic meaning but do not provide enough detail about nested structures or expected values.

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 identifies a specific action (create) and object (chart with data), and clarifies that it automatically populates the chart from the provided data range. However, it does not explicitly distinguish itself from sibling tools like sheets_create_chart or sheets_create_chart_from_table.

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

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

No guidance is provided about when to use this tool versus alternatives such as sheets_create_chart_from_table or sheets_update_chart_data. There are no usage conditions, prerequisites, or exclusions mentioned.

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

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

No annotations exist, and the description does not disclose side effects, permissions, or failure modes. Creating a sheet is a mutating operation, but the description gives no indication of impact on existing data or potential errors.

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

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

The description is extremely concise and front-loaded, stating the action and target in a single sentence. There is no unnecessary verbosity.

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 omits important context such as default behavior when index is not provided, whether duplicate titles are allowed, and how the sheet is positioned if inserted. While the schema lists parameters, the operational context is incomplete.

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

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

The schema provides brief descriptions for all three parameters, including the optional index. However, the description adds no extra meaning beyond these schema comments, so it meets the baseline for full schema coverage.

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

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

The description clearly states the tool's function: creating a new sheet in a spreadsheet. It is distinct from sibling tools like duplicate_sheet, rename_sheet, or delete_sheet.

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 usage guidance is provided. The description does not mention when to use this tool instead of alternatives, nor any prerequisites or conditions for creating a sheet.

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 of disclosing side effects. It only says 'delete,' without noting that the deletion is permanent, whether it affects only the chart object, or what other consequences may occur.

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

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

The description is a single, concise sentence with the key action and object front-loaded. It contains no unnecessary words 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?

The tool is simple and the schema covers the required parameters, but the description omits important contextual details such as permanence and whether any related data is affected. It is adequate but not 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 descriptions fully cover both parameters with clear names and types, so the description adds no extra parameter meaning. With 100% schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the action (delete), the object (chart), and the scope (from the spreadsheet). It distinguishes this from chart creation/update/list tools by using the verb 'delete', though it does not explicitly contrast it with sibling tools.

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

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

The description implies the tool is used when a chart needs to be removed from a spreadsheet, but it gives no explicit guidance about when to choose this over related chart operations such as updating or listing charts.

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, and the description only says 'Delete columns', which implies destructiveness but does not mention irreversibility, side effects on formulas or references, or permission requirements. The lack of detail leaves the agent uncertain about the full impact.

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

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

The description is a single, concise sentence that directly states the action and target. It avoids unnecessary detail or redundant wording, making it efficient and easy to parse.

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

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

The description is adequate for a straightforward delete operation but omits important context such as whether the endIndex is inclusive or exclusive, and the fact that deleting columns will shift subsequent columns. Given the simplicity of the operation, a score of 3 is appropriate.

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

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

The input schema already provides descriptions for all parameters, including the 0-based indexing of startIndex and endIndex. The tool description adds no extra semantic information beyond what is already in the schema, so it meets the baseline but does not enhance understanding.

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

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

The description uses the specific verb 'Delete' and identifies the resource 'columns' in a spreadsheet, distinguishing it from sibling tools like delete_rows or delete_sheet. The phrase 'from a specific position' further clarifies the operation's scope.

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

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

No explicit guidance is given about when to use this tool instead of alternatives. However, the operation is self-explanatory and clearly intended for removing columns, so the context is implied but not explicitly stated.

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

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

There are no annotations and the description fails to mention that the deletion is permanent, shifts subsequent rows up, or that it affects data and formatting. Given the complete absence of behavioral disclosure, this is a significant gap.

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

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

The description is a single, concise sentence with no unnecessary words. It is well-structured for its brevity, though it could be slightly more informative without becoming verbose.

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

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

The description lacks essential context such as the permanent nature of the deletion, the behavior of endIndex (inclusive/exclusive, optional), and any side effects on the spreadsheet. With no output schema or annotations, this leaves the agent under-informed for a destructive operation.

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

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

The input schema provides descriptions for all parameters (100% coverage), but those descriptions are minimal and almost tautological (e.g., 'The ID of the sheet'). The tool description adds no additional parameter semantics, 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 'Delete rows from a specific position' clearly states the action (delete) and resource (rows), and it distinguishes itself from column operations. However, 'from a specific position' is somewhat vague and could be more explicit about the range being deleted.

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

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

No guidance is provided on when to use this tool versus similar tools like sheets_delete_columns or sheets_insert_rows. The description does not mention optionality of endIndex or any context for deleting rows.

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?

As a destructive operation, the description does not mention irreversibility, data loss, or potential permission requirements. With no annotations to fill this gap, the user is left without critical side-effect information.

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

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

The description is a single, concise sentence with no redundancy or unnecessary words. It is exceptionally parsimonious while remaining grammatically correct and clear.

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

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

The description is too minimal to be contextually complete given the lack of annotations and output schema. It does not distinguish this action from other sheet-related operations (e.g., delete_rows, delete_columns) nor explain the scope of deletion (entire sheet vs. contents). More detail is needed for an agent to confidently invoke it correctly.

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

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

The schema already provides clear descriptions for spreadsheetId and sheetId, so the description adds no extra semantic value. Baseline of 3 is appropriate since parameter coverage is complete in the schema.

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

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

The description clearly states the action (delete) and resource (sheet from spreadsheet), but it largely paraphrases the tool name without adding new specificity. It is unambiguous but does not elevate beyond the name's inherent meaning.

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

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

The description provides no guidance on when to use this tool over alternatives such as deleting rows or columns, or even when not to use it (e.g., if only clearing contents is intended). It lacks any disambiguation among the many sibling tools.

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

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

The description implies creating a copy but does not disclose side effects, such as whether the original sheet is modified, or any permissions required. Since no annotations are present, the description carries the full burden but fails to provide these details.

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

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

The description is a single, concise sentence with no redundant words. It is appropriately brief for the simple action described.

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 minimal and does not explain the exact behavior of duplication (e.g., whether formatting is copied) or the relationship to similar tools like 'sheets_copy_to' or 'sheets_create_sheet'. This lack of context may leave an agent uncertain about when to use this tool.

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

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

The schema descriptions for the three parameters (sheetId, newTitle, spreadsheetId) are self-explanatory and cover all fields. The tool description adds no additional semantic information beyond the parameter names.

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

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

The description states the action 'duplicate' and the resource 'sheet' clearly, but it does not specify the scope (e.g., within the same spreadsheet) or distinguish it from sibling tools like 'sheets_copy_to'. However, the core purpose is understandable.

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 usage conditions or alternatives are mentioned. The description does not indicate when to prefer this tool over others, such as when duplicating within the same spreadsheet vs. copying to another location.

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, and the description does not disclose side effects, permission requirements, idempotency, or whether existing formatting is overwritten or merged. It is purely a statement of capability.

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

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

The description is a single, concise sentence with no unnecessary words. It conveys the essential information efficiently.

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

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

The description gives the core context (what and where) but lacks details on how optional parameters interact, default behavior, or the resulting state of formatted cells. Given the simplicity of the tool, it is adequate but not fully comprehensive.

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

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

All 10 parameters have descriptions, including explanations for nested objects like color and border settings. The descriptions add value beyond the schema types (e.g., 'Color object with red, green, blue, alpha values'), though the structure of nested objects could be more explicit.

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 action ('Apply formatting') and resource ('cells'), and specifies the formatting categories (colors, fonts, borders, alignment). It is distinct from sibling tools like sheets_set_formula or sheets_conditional_formatting.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., conditional formatting, merging cells, or setting formulas). No comparison or condition is given.

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 full burden for disclosing behavior. It does not mention that this is a read-only operation, that it does not modify data, or any other side effects or guarantees.

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

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

The description is a single, concise sentence that efficiently conveys the core purpose without unnecessary words or 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 operation is simple and the schema covers all parameters, but the lack of usage guidance and behavioral transparency leaves gaps. An agent might not know when to prefer this over other get operations or that it is safe (read-only).

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 full descriptions for all four parameters, including enums. The phrase 'optional formatting' adds a minor hint about valueRenderOption and dateTimeRenderOption but does not materially enhance the schema's explanations.

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 it gets data from Google Sheets, which is a specific verb and resource. It doesn't explicitly distinguish itself from sibling tools like sheets_batch_get or sheets_get_metadata, but the name and phrasing make its purpose reasonably clear.

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

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

No guidance is provided on when to use this tool versus alternatives such as sheets_batch_get or sheets_get_metadata. Users are left to infer from the name alone.

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

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

No annotations are provided, so the description must fully disclose behavior. It only says 'Get comprehensive metadata' and does not explicitly state read-only behavior, the exact content of the metadata, or the potential impact of includeGridData, which could yield a large response.

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

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

The description is a single concise sentence with no filler or redundancy. It efficiently conveys the core 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?

The tool is simple, and the schema covers the parameters, but there is no output schema and no connection to sibling tools. The description does not clarify the response structure or the scope of 'comprehensive metadata,' leaving some contextual gaps.

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

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

Schema coverage is 100%, with both parameters having basic descriptions. The description adds little beyond what the schema already states, but the parameter meaning is adequately conveyed, so it meets the baseline without adding significant extra value.

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

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

The description uses a clear verb ('Get') and a specific resource ('comprehensive metadata about Google Sheets'). However, it does not explicitly differentiate from sibling tools such as sheets_get_sheet_info, sheets_get_sheet_properties, or sheets_get_data, so it is clear but not fully distinctive.

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

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

The description provides no guidance on when to use this tool versus alternatives. Given the large sibling set with overlapping metadata-related tools, the lack of any when-to-use or when-not-to-use direction is a significant gap.

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?

There are no annotations, and the description does not disclose any behavioral traits such as read-only nature, side effects, permission requirements, or potential errors. The verb 'Get' implies read-only, but this is not made explicit, and no details about includeGridData behavior are provided.

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

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

The description is a single, concise sentence that directly states the tool's purpose without unnecessary words or redundancy. It is well-structured and easy to parse.

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

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

For a simple informational tool with no output schema, the description is minimal but adequate. It does not explain what 'detailed information' includes or provide context about the response format, but given the low complexity, it is arguably sufficient. However, the lack of any additional context about the tool's role among many sheet-related siblings prevents a higher score.

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

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

The input schema provides descriptions for both parameters: spreadsheetId is described as 'The ID of the spreadsheet' and includeGridData as 'Whether to include grid data'. Schema coverage is 100%, so the baseline is 3. The description adds no additional semantic nuance beyond what is already in the schema.

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

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

The description clearly states the verb 'Get' and the resource 'detailed information about all sheets in a spreadsheet', distinguishing it from tools that target a single sheet (e.g., sheets_get_sheet_properties). It does not name a sibling explicitly, but the phrase 'all sheets' provides sufficient 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 guidance is provided on when to use this tool versus alternatives. The description only states what it does, without any context about selection criteria, prerequisites, or scenarios where a different tool would be more appropriate.

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?

There are no annotations to indicate side effects or read-only behavior. The description uses 'get', which implies a read operation, but it does not explicitly state that no data is modified, nor does it mention any potential errors or output format. Given the absence of annotations, the description carries the full burden and falls short.

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

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

The description is a single sentence that is direct and free of unnecessary words. It effectively communicates the primary purpose without extraneous detail, making it well-structured for quick comprehension.

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

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

While the description mentions example properties (title, index, hidden status), it lacks enough context to fully disambiguate from similar sibling tools like sheets_get_sheet_info. The 'etc.' is vague, and the description does not clarify what specific properties are included or how the tool fits into a broader workflow. Given the existence of closely named alternatives, this incompleteness is significant.

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?

Both parameters are described with minimal phrases ('The ID of the specific sheet', 'The ID of the spreadsheet') that merely restate the parameter names without adding meaningful context about their format, origin, or relationship. Since schema coverage is 100% but the descriptions add negligible value, the score is low.

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

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

The description clearly states the verb 'get' and the resource 'properties of a specific sheet', listing examples like title, index, and hidden status. It is concise and easily understood, though the trailing 'etc.' introduces slight vagueness.

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

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

No guidance is provided regarding when to use this tool versus the closely related sibling tools such as sheets_get_sheet_info or sheets_get_metadata. An agent cannot determine the appropriate context or distinguish this tool from alternatives based on the description alone.

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

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

The description indicates a mutating action but does not disclose potential side effects, reversibility, or any preconditions. Since no annotations are provided, the description carries the full burden, and it falls short of transparency.

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, straightforward sentence with no unnecessary words. It is concise and to the point.

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

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

The tool is simple and the description covers the core action. However, it could briefly mention that hiding is reversible or that the sheet is not deleted, which would provide better context for an agent.

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

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

Both parameters are described with their IDs, but the descriptions are minimal and do not add meaningful context beyond the schema types. They are self-explanatory, meeting baseline expectations without enrichment.

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

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

The description clearly states the action and its effect (hide a sheet from view). It is specific and unambiguous, and the phrase 'make it invisible' reinforces the meaning.

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

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

No guidance is provided on when to use this tool versus alternatives. Although sibling tools like sheets_show_sheet exist, the description does not mention them or any conditions for choosing this tool.

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

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

There are no annotations, and the description fails to mention side effects like shifting existing data, required permissions, or the number of columns inserted based on endIndex and startIndex.

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

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

The description is a single, focused sentence that immediately conveys the core action without unnecessary detail, making it highly efficient.

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 lacks important context such as expected return value, error conditions, or the relationship between startIndex and endIndex, leaving gaps for effective use despite the clear purpose.

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

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

All four parameters have schema descriptions, providing basic meanings (e.g., '0-based' indexes), but the description does not add extra clarity about how endIndex and startIndex determine the insertion count or whether endIndex is optional.

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

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

The description clearly states the verb 'Insert', the object 'columns', and the specific position, making it distinct from sibling tools like sheets_insert_rows and sheets_delete_columns.

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

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

The description offers no guidance on when to use this tool versus alternatives, such as when to insert rows or delete columns, nor any scenario-based context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it does not mention side effects like shifting existing rows down, impact on formatting or formulas, or that startIndex is zero-based. The behavior is non-obvious for a mutating 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?

The description is a single, focused sentence with no extraneous filler. It is front-loaded with the core intent and reads clearly.

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

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

For a write operation with no annotations, the description is too sparse. It omits critical context such as what happens at the insertion point, how many rows are inserted (implied by endIndex - startIndex), and any constraints or prerequisites, leaving the agent with insufficient understanding to use the tool correctly without additional research.

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 for parameters is 100% with simple descriptions like 'Starting row index (0-based)', which is adequate. However, the description does not explain the relationship between startIndex and endIndex (e.g., how many rows are inserted when endIndex is omitted or included), so no additional meaning is added.

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

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

The description clearly states the action (insert), the resource (rows), and the location (at a specific position). This distinguishes it from sibling tools like sheets_insert_columns or sheets_delete_rows without needing to open schemas.

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

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

No guidance is provided for when to use this tool versus alternatives, such as 'use when you need to add rows without overwriting existing data' or 'use insert_columns for columns.' The agent is left to infer the appropriate context solely from the name and the sibling list.

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

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

The description implies a read-only operation by using 'List', but it does not explicitly state side effects or lack thereof. Since there are no annotations to rely on, the description alone partially covers behavioral transparency but leaves room for interpretation about what 'details' entails.

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

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

The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to parse quickly.

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

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

The description adequately conveys the tool's purpose for the given complexity. While it does not specify the structure of the 'details' returned, this is not critical given the simple read-only nature and the availability of the tool name. The context is sufficiently complete for an agent to decide when to use it.

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

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

The only parameter, spreadsheetId, is well-described with 'The ID of the spreadsheet'. The schema provides full coverage, and the description adds no ambiguity. Both the schema and description align perfectly.

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 function: to list all charts in a spreadsheet and provide their details. The verb 'List' and the resource 'charts' are specific, and the scope 'in a spreadsheet' is unambiguous. It is easily distinguished from sibling chart tools that create or update charts.

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

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

The description does not explicitly mention when to use this tool versus alternatives such as creating or updating charts. While the listing nature implies a read-only use case, there is no direct guidance on when to choose this over other chart-related tools.

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

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

The description gives no information about side effects, such as data loss from merging (only the top-left value is kept), irreversibility, or effects on formatting. With no annotations, the description carries the full burden, and it is insufficient.

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

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

The description is extremely concise and to the point, with no unnecessary words. It is well-structured and easy to parse.

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

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

The description lacks important context such as the behavior of different merge types (e.g., MERGE_ALL vs MERGE_ROWS), potential data loss, and any prerequisites. Given the tool's simplicity, it is still minimal and incomplete.

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

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

The schema already provides descriptions for all three parameters, and the tool description adds no extra context or clarifications. Since schema coverage is 100%, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool merges cells in a range, using a specific verb and object. It is distinguishable from sibling tools like sheets_batch_update or sheets_format_cells, though it could be more explicit about the merging behavior.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of when merging is appropriate or how it differs from related operations like batch updates or formatting.

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

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

With no annotations, the description carries the full burden of explaining behavior. It clearly states the operation (moving a sheet to a new position), which is straightforward and does not involve hidden side effects like data deletion. However, it does not mention any limitations or consequences (e.g., how references are affected), so a slight deduction is warranted.

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

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

The description is a single, clear sentence with no redundant information. It is concise and well-structured, with all necessary information included without fluff.

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 simplicity of the tool and the absence of an output schema, the description is sufficient for an agent to invoke it correctly. No additional context about return values or edge cases is needed for a basic move operation.

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

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

The schema covers all three parameters (spreadsheetId, sheetId, newIndex) with descriptions, so coverage is 100%. The description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed 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?

The description clearly states the action ('Move a sheet') and the resource ('spreadsheet'), making it distinct from sibling tools like rename or delete sheet. The verb 'move' and target 'sheet position' are specific and unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives, but the action is self-explanatory. No guidance is provided about when not to use it or how it differs from other sheet operations, so some inference is required.

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, and the description does not disclose side effects, whether the action is reversible, or if it requires special permissions. The lack of any behavioral detail leaves the agent uncertain about the tool's impact.

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

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

The description is extremely brief and to the point, with no redundant information. It efficiently conveys the core function without unnecessary 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?

The lack of an output schema means the agent cannot anticipate the return value or confirmation. The description does not mention any related steps or special considerations. However, the simplicity of the operation and the clear parameter definitions provide some 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?

All four parameters are described in the schema, covering the essential fields. Descriptions are concise and understandable (e.g., 'warningOnly' explains its purpose). While minimal, they are adequate for an agent to infer the meaning.

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

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

The description clearly states the action (protect) and the resource (range of cells). It is distinguishable from sibling tools like sheets_get_data and sheets_update_data. However, it could be more specific about the mechanism or effect of protection (e.g., permissions, warnings).

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

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

The description provides no guidance on when to use this tool vs alternatives. It does not mention prerequisites, such as the need to obtain a spreadsheet ID or the format of the range string. No context on how this fits into a workflow.

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 present, so the description bears full responsibility for disclosing side effects. It merely states the action without mentioning any potential consequences, permissions, or changes to related data (e.g., formulas referencing the sheet name).

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?

Extremely concise: one short sentence with no unnecessary words. The essential information is conveyed efficiently and front-loaded.

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

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

For a simple rename operation, the description is functionally adequate but lacks any context about return values, potential errors (e.g., duplicate sheet names), or interaction with other spreadsheet elements. It is minimal but not misleading.

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 descriptions for all three parameters (spreadsheetId, sheetId, newTitle), so coverage is 100%. The description adds no extra semantic detail beyond what the schema already states, warranting the baseline score.

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?

Clearly states the action (rename) and the target resource (an existing sheet). Though it does not differentiate from sibling tools that operate on sheets, the specific verb 'rename' makes the purpose distinct from duplicate, move, or delete operations.

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

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

Provides no guidance on when to use this tool versus alternatives such as sheets_duplicate_sheet or sheets_move_sheet. There is no mention of conditions, prerequisites, or typical use cases.

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

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

There are no annotations and the description does not explicitly state that the operation is read-only or non-destructive. It also does not disclose what fields are returned, whether results match partial/fuzzy criteria, or how errors/no-results are handled.

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

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

The description is a single, focused sentence with no filler or redundant content. It is appropriately sized for the tool's simple 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?

Given that there is no output schema and no usage guidance, the description is incomplete for a new agent. It lacks information about the returned object shape, how to interpret results, search scope (e.g., Drive-wide vs. a specific location), and how the results connect to other tools that require spreadsheet IDs.

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 basic descriptions for 'query' and 'maxResults'. The description adds minimal extra meaning by clarifying that search is by name or content, but parameter descriptions remain shallow and do not explain query format or result limits beyond defaults.

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

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

Description states a specific verb ('Search'), a specific resource ('Google Sheets'), and the scope ('by name or content'). It is immediately clear what the tool does and it stands apart from the many mutation/retrieval sibling tools.

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

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

No guidance is given about when to use this tool versus alternatives, such as using it to discover spreadsheet IDs before calling sheets_get_data or sheets_update_data. The description implies a search/discovery role but never states it explicitly.

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 not disclose whether existing validation rules are overwritten, how invalid data is handled, if the rule applies to new cells, or any side effects. The reader is left without behavioral expectations beyond 'setting a rule'.

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

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

The description is a single, concise sentence that directly states the action. It is not bloated or redundant, though it omits important details that are captured in other dimensions.

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

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

The tool is relatively simple with no output schema and only five parameters, but the description still feels incomplete. It lacks examples, explanation of rule types, or how the 'values' field interacts with different rule types. The contextual information needed for correct usage is mostly absent.

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 each parameter described. The description adds no extra semantic meaning 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 clearly states the tool's purpose: to set data validation rules on cells. The verb 'set' is specific, and the resource ('data validation rules') distinguishes it from sibling tools like set_formula or format_cells.

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

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

No guidance is provided on when to use this tool versus alternatives such as conditional formatting or setting formulas. There is no mention of prerequisites, limitations, or scenarios where this tool is preferred.

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 full responsibility for revealing behavior. It states 'set formulas' but does not disclose side effects like overwriting existing formulas, expected formula format (e.g., leading '='), or that it is a write 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?

One short, direct sentence with no redundant wording. Perfectly concise for the intended 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?

Sufficient for a simple setter, but lacks context on error handling, confirmation of written data, or interaction with existing cell content. No output schema is provided, which is acceptable for a write operation.

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

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

Schema descriptions cover the basics (range, formulas, spreadsheet ID) but lack detail on formula syntax, array dimensions matching the range, or whether the formulas parameter should be a flat list or 2D array.

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?

Clearly states the action (set) and resource (formulas in cells), distinguishing it from value-setting tools. However, it could be more specific about overwriting behavior or the need for A1 notation.

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

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

No guidance on when to use this tool versus siblings like sheets_update_data or sheets_batch_update. The description does not mention alternatives 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 are absent, so the description must convey behavior. It only says 'Share... with specific permissions' but does not disclose potential side effects such as email notifications, permission replacement, or access revocation implications. This lack of transparency warrants a 2.

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

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

The description is a single, clear sentence with no redundancy, earning 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?

Given the tool's simplicity and lack of an output schema, the description is minimally sufficient, but it omits details about success/failure behavior. Considering the absence of annotations, a 3 seems fair.

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

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

All four parameters are described in the schema with brief explanations, providing basic coverage. The description text adds no additional parameter semantics beyond what the schema offers, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Share') and the resource ('Google Sheets') along with the capability ('specific permissions'). It is distinct from sibling tools like sheets_get_data or sheets_update_data, though it doesn't explicitly name an alternative, so a 4 is appropriate.

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

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

There is no guidance on when to use this tool versus other sharing or permission-related tools, nor any mention of alternatives. The description simply states the action without contextual direction, so a 2.

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 burden. It indicates a state change (making visible) but does not mention idempotency, potential errors, or side effects.

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

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

The description is a single concise sentence with no redundant information.

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

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

The description covers the core functionality. It does not address error cases or prerequisites, but for a simple unhide operation, this is acceptable. It could be more complete with a note about the sheet needing to be hidden.

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 both parameters with full coverage. The tool description does not add any additional meaning beyond what the schema provides, so the baseline score applies.

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

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

The description clearly states the action (show) and the resource (hidden sheet), and the parenthetical 'make it visible again' reinforces its purpose. It distinguishes itself from the sibling 'hide_sheet' by being the inverse operation.

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

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

The description does not explicitly state when to use this tool versus alternatives, such as when you need to unhide a sheet. It only describes the action without guidance on selection criteria.

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?

There are no annotations and the description does not disclose side effects, failure behavior, or whether the chart must already exist. The word 'Update' implies modification, but nothing is said about what happens if chartId is invalid or if no update fields are supplied.

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

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

The description is a single, clear sentence with no filler or redundant phrases. It is appropriately concise and front-loads the action.

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

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

The description is too sparse to be complete for an agent invoking the tool. It omits how title and dataRange interact, whether both are optional, what should happen if only one is provided, and how it differs from the similar sheets_update_chart_data 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?

The input schema has 100% description coverage for its four parameters, so the baseline is 3. The description adds no extra meaning beyond the schema, but the schema itself provides basic definitions for all 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 states the verb and resource ('Update an existing chart in Google Sheets'), but it does not specify which aspects of the chart can be updated. With sibling tools like sheets_update_chart_data, the description is too generic to clearly distinguish this tool's scope.

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

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

There is no guidance about when to use this tool versus alternatives such as sheets_update_chart_data or sheets_create_chart. The description does not mention that title and dataRange are optional or that at least one should be provided.

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

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

No annotations are provided, so the description carries the burden of disclosing side effects. It only mentions 'refresh the chart' as a side effect, but does not describe any other behavioral aspects such as idempotency, permission requirements, or impact on existing data. This is minimal and insufficient for full transparency.

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

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

The description is a single concise sentence, which is efficient and to the point. It does not waste words, but it lacks any structural elements like bullet points or explicit parameter references. Still, it is appropriately sized for the task.

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 simplicity of the operation, the description covers the basic purpose but does not provide context about the expected outcome, relation to other chart operations, or any edge cases. It is adequate but could be more complete by mentioning that only the data range and title are updated, not other chart properties.

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 descriptions for all four parameters (spreadsheetId, chartId, newDataRange, updateTitle), achieving high coverage. The tool description itself does not add additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description states a clear verb ('Update') and resource ('chart data'), and mentions refreshing the chart. However, it does not explicitly differentiate from the sibling tool 'sheets_update_chart' which might update chart properties, leaving some ambiguity about the exact scope of 'chart data'.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'sheets_update_chart', 'sheets_create_chart', or 'sheets_get_data'. There is no mention of conditions, exclusions, or preferred scenarios, leaving the agent without sufficient direction for tool selection.

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

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

No annotations are provided, leaving the description to explain behavioral traits. It only states 'update data' without detailing whether it overwrites existing values, how it handles empty ranges, return values, or side effects. This lack of transparency could lead to incorrect usage.

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 concise and straight to the point. It is one sentence that directly conveys the tool's purpose without unnecessary fluff. The inclusion of 'optional formatting' is slightly inaccurate but does not significantly affect conciseness.

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

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

Given the large number of sibling tools, the description lacks context about return values, error behavior, or how it differs from related operations like batch updates or formatting. This incompleteness makes it harder for an agent to anticipate the tool's full behavior and fit within a workflow.

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 descriptions cover all four parameters, providing basic information for each. However, the description for 'valueInputOption' ('How the input should be interpreted') is vague and does not clarify the difference between RAW and USER_ENTERED, leaving some ambiguity for the agent. The other parameters are adequately described.

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 updates data in Google Sheets, with a specific resource and action. The phrase 'optional formatting' is slightly misleading because the parameters do not include formatting options, but the core purpose is still clear.

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

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

The description provides no guidance on when to use this tool versus similar siblings like sheets_batch_update, sheets_set_formula, or sheets_clear_range. Without any differentiation, an agent may struggle to select the appropriate tool.

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