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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds that matched rows are returned (rather than an aggregate or count, which matters against get_summary_stats), but it says nothing about the 500-row default limit, the 5000 cap, or behavior on non-matching/empty results.

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 front-loaded sentence states the action and its operand types with no preamble. The long parenthetical operator list consumes most of the sentence and duplicates the schema enum verbatim, but it does let an agent gauge capability without opening the schema.

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

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

For a read-only filtering tool with complete schema descriptions and full annotation coverage, the definition is close to sufficient: action, operands, and return shape ('matching rows') are all stated. The absence of any note on the default/capped row limit is the only real gap, and no output schema exists to carry 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?

Schema description coverage is 100%, including per-operator value formatting ([low, high] for between, list for in, ISO dates) and the limit cap, so the schema already carries parameter meaning. The description's operator list merely mirrors the schema enum and adds no semantics the schema lacks; the baseline 3 applies.

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

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

The description pairs a specific verb (filter) with a specific resource (rows) and enumerates the supported comparison operators, so the agent knows exactly what operation it performs. It stops short of differentiating from siblings like search or get_sheet_data, which also retrieve row data, so the boundary between them must be inferred.

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 statement of when to reach for apply_filter versus search, get_sheet_data, or read_spreadsheet, nor any prerequisite or exclusion guidance. The only usable signal is 'return the matching rows,' which is a restatement of purpose rather than a routing rule.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true and openWorldHint=false, so the mutation and safety profile is covered structurally. The description only adds the format constraint (.xlsx/.xlsm), and says nothing about what happens on a duplicate sheet name, whether the file is rewritten, or error behavior.

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

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

A single front-loaded sentence naming the action, the resource, and the target format. There is no filler and nothing is buried.

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

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

For a mutation tool whose annotations already carry the destructive/idempotent profile, the description is minimally viable, but it omits name-uniqueness behavior, failure modes, and any confirmation that the sheet is appended when index is null.

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

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

Schema description coverage is 100%, so name, path, index (0 = first, defaults to last) and headers are all documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('add a new sheet') and constrains the target to existing .xlsx/.xlsm workbooks, which implicitly separates it from create_workbook. It is clear without explicitly naming siblings, so 4 rather than 5.

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

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

The word 'existing' implies this is for workbooks that already exist (versus create_workbook for new ones), but there is no explicit when-to-use statement, no exclusion, and no mention of required preconditions such as the file needing to exist.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that: it never explains that an existing file is destroyed unless overwrite is set, nor what the tool returns.

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

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

A single tight sentence with the core action front-loaded and the optional modifier trailing. It earns its place, though it is terse enough that there is no room for the routing guidance an agent would benefit from.

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

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

For a destructive, file-creating tool with four parameters and no output schema, the description omits critical context: the overwrite risk, what happens on a name collision, and how this differs from create_sheet. Annotations cover safety hints but not the workflow positioning the agent needs.

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

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

Schema description coverage is 75%, with overwrite and headers semantics already documented in the schema (including bold/frozen formatting for headers). The description only echoes the optional header-row behavior and adds nothing for the undocumented sheet_name parameter, so the baseline 3 applies.

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

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

States a specific verb (Create) and resource (.xlsx workbook), which is clearly distinguishable from siblings like create_sheet or write_cell by the resource type. However, it never names or contrasts with those siblings, so an agent must infer the workbook-vs-worksheet boundary itself.

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

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

No when-to-use guidance, no prerequisites, and no mention of the closely related create_sheet sibling, which is the most likely confusion point. The reader must infer that this is the entry point before writing cells or creating sheets.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs incremental value — and it delivers by disclosing the return shape (formulas plus each cell's last cached result) and a format restriction, which is important since there is no output schema.

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

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

Two short sentences, front-loaded with the core purpose and immediately followed by the format constraint. No filler words and nothing redundant with the schema.

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

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

With no output schema, the description compensates by explaining what is returned (formulas, not values, plus cached results) and which file types are supported. It is complete enough to call safely, with only minor gaps around range defaults that the schema already covers.

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

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

Schema description coverage is 100%, and the schema already documents path, sheet (defaults to first sheet) and cell_range (e.g. 'A1:D20', defaults to whole sheet). The description's 'in a range' merely echoes cell_range, adding no syntax or default detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (formulas) with scope (in a range), and explicitly disambiguates from value-reading siblings by saying '(not values)'. It does not name read_spreadsheet or get_sheet_data directly, but the formula-vs-value distinction is enough for an agent to route correctly.

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

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

Gives a clear scope condition ('in a range') and a hard exclusion ('.xlsx/.xlsm only'), which tells the agent when this tool is not applicable. It stops short of naming the alternative tool to use for values or for unsupported formats.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that output is JSON records and that results are optionally column-limited and paged, but it does not disclose row caps, error behavior, or return structure beyond the basic format.

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

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

The description is a single, well-formed sentence that front-loads the core action and result. Every word contributes to the stated capability with no filler or repetition.

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

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

Given rich schema descriptions and comprehensive read-only annotations, the description is nearly sufficient for correct invocation. However, because there is no output schema, it could say more about the returned JSON record shape or header handling, making it slightly incomplete for an agent needing return-value 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?

Schema description coverage is 100%, so all six parameters are already documented, including path, limit, sheet, offset, columns, and header_row. The description merely echoes the optional column limitation and paging without adding syntax, defaults, or edge-case meaning beyond the schema.

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

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

The description states a specific verb ('Return') and resource ('a sheet's rows as JSON records') with scope modifiers for columns and paging. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like read_spreadsheet or get_formulas.

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 read_spreadsheet, get_summary_stats, or search. It only describes capability, leaving the agent to infer appropriate contexts and exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine value by naming the exact metrics returned per column type, which matters since there is no output schema, but it says nothing about how missing/blank values are treated or how non-numeric columns are skipped.

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

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

A single dense sentence that front-loads the resource ('per column') and then enumerates output metrics without filler. Efficient, though the numeric/text split is packed into one long clause.

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 no annotations describing results, the description carries the return-value burden and does so well by enumerating every statistic per column type. The remaining gap is edge-case behavior (empty sheets, all-text columns, missing handling), which is minor for this tool.

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

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

Schema description coverage is 100%, so path, sheet, columns, and header_row are already documented in the schema (including defaults). The description adds no parameter-level meaning beyond that, making the baseline 3 correct.

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

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

The description states a specific verb ('Summary statistics') and resource ('per column'), and enumerates exactly which statistics are produced for numeric vs text columns. It does not explicitly differentiate itself from siblings like get_sheet_data or get_formulas, so an agent must infer the boundary, but the purpose itself is unambiguous.

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

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

There is no when-to-use guidance, no mention of alternatives such as get_sheet_data for raw values, and no prerequisites or caveats. The agent can infer this is the stats tool, but nothing routes it here over the 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description usefully adds the shape of the result (sheet names, dimensions, row preview), which matters since there is no output schema, but says nothing about pagination, limits, or failure modes.

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

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

One sentence, front-loaded with the action, with no filler. Every clause (sheets, dimensions, row preview) carries information.

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

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

For a simple, read-only two-parameter tool with full annotation coverage and 100% schema description coverage, the description is nearly sufficient, and it compensates for the missing output schema by naming what is returned. It stops short of explaining limits or whether all sheets are always listed.

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

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

Schema coverage is 100% and both parameters are documented in the schema (including the max-50 bound on preview_rows). The description's phrase 'preview of the first rows' gestures at preview_rows but adds no syntax or default information beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Open a spreadsheet and list its sheets with dimensions and a preview of the first rows.' This clearly conveys a metadata-plus-preview read, distinct from data-reading siblings like get_sheet_data. However, it does not explicitly name any sibling, so differentiation is inferred rather than stated.

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

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

Usage is implied (inspect sheets and preview before pulling full data), but there is no explicit when-to-use, when-not-to-use, or alternative (e.g. get_sheet_data) named. The agent must infer the routing decision from the purpose alone.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context. It does add real value by disclosing the return shape ('Returns cell addresses'), which is otherwise undocumented since there is no output schema. It stops short of mentioning result caps/pagination behavior.

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

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

Two short sentences, zero filler, with the action front-loaded and the return value second. Nothing could be trimmed without losing 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 read-only search tool with strong annotations and a well-documented schema, the description supplies the missing return-type information. The only gap is that case_sensitive carries no schema description and the description does not compensate for it, which is minor.

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

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

Schema description coverage is 83%, above the 80% threshold, so the schema already documents mode, path, limit, sheet and query. The description's mention of 'text, numeric or regex' loosely maps to query/mode but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Find cells') plus the matching criteria (text, numeric, regex) and the return shape ('cell addresses'). This is clear and unambiguous, but it never names or contrasts with the adjacent siblings like get_sheet_data or apply_filter, so the agent must infer the boundary itself.

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

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

Usage is only implied by the verb: an agent can infer 'use this to locate values,' but there is no explicit when-to-use, no when-not-to-use, and no named alternative (e.g., apply_filter for filtered views) to disambiguate the crowded sibling set.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds two useful facts beyond them: the return of the previous value and the supported formats, but it does not explain that the existing cell content is overwritten, nor how the claimed idempotency interacts with returning a different 'previous value' on repeated calls.

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

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

Two short sentences with no filler; the operation and its scope are front-loaded and the return behavior follows immediately. Nothing is wasted.

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

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

With a 4-parameter schema fully described and no output schema, the description is nearly sufficient: it names the operation, scope and return value. Minor gaps remain, such as error behavior for a missing sheet or non-existent workbook path, but nothing required to invoke the tool correctly is 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 description coverage is 100%, so the schema already documents path, cell, sheet default and the '=' formula/null-clears semantics of value. The description's 'one value or formula' adds only a restatement of what the schema's value description covers, so the baseline 3 applies.

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

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

The description states a specific verb and resource (write one value/formula to a cell) plus the file formats supported (.xlsx/.xlsm), which lets an agent distinguish it from the sibling write_range by the 'one value ... a cell' scope. It stops short of naming write_range explicitly, so the sibling differentiation is inferred rather than stated.

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

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

Usage is implied by scope: single-cell writes versus the sibling write_range, and the format constraint rules out non-xlsx files. There is no explicit when-to-use/when-not-to-use statement, no mention of create_sheet/create_workbook ordering, and no note that the file must already exist.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the mutation profile is covered by structured data. The description contributes the file-format constraint (.xlsx/.xlsm), but does not disclose the key behavior an agent would want: that existing cell contents in the target rectangle are overwritten, or how formatting is 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?

A single sentence, front-loaded with the action and resource, with no filler. It is efficient, though it is arguably too terse for a destructive block write and leaves room for one more useful clause.

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

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

For a 4-parameter destructive write with no output schema, the description is adequate but thin: it omits overwrite semantics, sheet-existence requirements, and whether ranges may extend the used region. Annotations cover the safety signal, which keeps this at minimum-viable rather than deficient.

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

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

Schema coverage is 100%, so path, sheet, values and start_cell are all documented in the schema. The description echoes the shape ('2D block', 'starting at a cell') but adds no format details, value-coercion rules, or behavior beyond what the schema already provides; baseline 3 applies.

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

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

States a specific verb (Write) and resource (a 2D block of values / rows of cells) with the origin point (starting at a cell) and file scope (.xlsx/.xlsm). The '2D block' framing implicitly separates it from the single-cell sibling write_cell, but it never names that sibling to make the distinction 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?

Usage is implied by the description ('starting at a cell in an .xlsx/.xlsm file'), which tells the agent the tool applies to block writes in supported formats. There is no explicit when-to-use versus write_cell, and no exclusions or prerequisites (e.g. sheet must exist, whether existing data is overwritten).

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