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

With no annotations provided, the description carries the full burden. It states the operation (group/aggregate) but does not explicitly mention that it is read-only, what side effects occur (likely none), or any permission requirements. The arg details add some context but not full behavioral 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 opening sentence followed by a compact, well-organized Args list. Every line adds value, no fluff, and the main purpose is 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?

Given the tool's complexity (6 params, nested objects) and the existing output schema, the description covers the operation and all parameters adequately. It could be slightly more complete by explicitly noting the operation's read-only nature and return value, but the output schema covers the return and the description is otherwise thorough.

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 0%, but the description thoroughly explains all six parameters: path, sheet, group_by, agg, cell_range, and has_header. This fully compensates for the lack of schema descriptions, providing clear meaning and examples.

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 'Group and aggregate sheet data with pandas' with a concrete example ('sum sales by region'). This is a specific verb+resource that distinguishes it from siblings like read_sheet or write_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?

The description implies usage through its name and purpose, and provides parameter-level guidance (e.g., 'Omit if only one file is configured') but does not explicitly explain when to choose this tool over alternatives or when not to use it.

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

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

No annotations are provided, so the description carries the full burden and does meaningfully more than restate the name: it discloses the append position, the automatic LibreOffice recalculate pass, and the cost/risk tradeoff of that recompute step. It does not state whether appends are reversible, whether a backup is auto-taken (the 'backup' param exists but is unmentioned), or what happens on sheet-size overflow – gaps that keep it below 5.

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

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

The core behavior and the recalculate caveat are front-loaded in the first two sentences, followed by an Args block. Every sentence adds information; there is no filler or redundant restatement of the name.

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

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

An output schema exists, so return values needn't be explained, and the write/recalculate behavior is covered. But for a mutation tool with 7 parameters, no annotations, and two parameters (backup, allow_external_formulas) undocumented in both schema and description, the definition leaves an agent unable to reason about durability and external-reference handling.

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 0% and there are 7 parameters, so the description must compensate – and it documents path (including the preloaded-file fallback and omission case), sheet, rows (structurally: list of row-lists in column order), create_sheet_if_missing, and recalculate. That covers the two required params plus key behavior, but silently omits backup and allow_external_formulas, leaving two of seven parameters undocumented anywhere.

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 ('append rows') plus the exact placement ('after the last used row of a sheet') and names the subsequent side effect ('recalculate the workbook'). That positioning clause cleanly distinguishes it from sibling insert_rows and write_cells, which lack any placement semantics.

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 recalculate parameter is framed with a when-to-skip condition ('structurally complex workbooks you don't want round-tripped'), which is real usage guidance. However, it never addresses when to choose append_rows over insert_rows, write_cells, or create_sheet, and doesn't mention preconditions like required file configuration beyond the path note.

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

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

No annotations are provided, so the description carries the full burden. It implies a file mutation but never states whether changes persist, whether a backup is created, or what happens to the existing widths. The 'backup' parameter exists in the schema yet is entirely absent from the description, leaving a significant behavioral 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 summary line is front-loaded and the docstring-style Args block is compact and easy to scan. No filler sentences, though the parameter listing is a bit terse and the base-width unit (characters) is left implicit.

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?

Since an output schema exists, return values need not be explained. But for a mutating tool with no annotations, the missing 'backup' semantics and lack of any persistence/safety disclosure leave an agent partially under-informed about side effects.

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 0%, so the description must compensate. It explains five of six parameters meaningfully (path, sheet, min_width, max_width, padding), adding semantics like 'extra padding characters to add to max length.' However, it omits 'backup' entirely, leaving one parameter undocumented in both schema and description.

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

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

The opening sentence states a specific verb (adjust) and resource (column widths) with the mechanism (based on maximum text length). This clearly distinguishes it from structural siblings like insert_columns/delete_columns and styling tools like set_cell_style. No explicit sibling routing, but the purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives, nor any prerequisite or exclusion. The only conditional note is a parameter-level hint ('Omit if only one file is configured') tucked into the Args list rather than usage guidance.

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

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

With no annotations, the description carries the full burden. It usefully discloses that rows/columns are preserved and gives the default polarity of values vs. styles, which is real behavioral context. However, it says nothing about reversibility, permissions, or the existence of the schema's 'backup' parameter, leaving the safety profile of a destructive-style operation incomplete.

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

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

Front-loaded single-sentence purpose followed by a tight per-argument list; no filler. The A1 example ('A1:D10') earns its place by clarifying the format. Slightly verbose in the per-arg prose but well organized.

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

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

An output schema exists, so return values need no explanation, and the clearing semantics are reasonably covered. But for a mutation tool with zero annotations, omitting the 'backup' parameter (and any note on reversibility) leaves an agent without enough to reason about risk before invoking 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 0%, so the description must compensate, and it does for 5 of 6 parameters: path semantics (file or preloaded name, omittable when one file is configured), sheet, A1-style range format, and the defaults for clear_values (True) and clear_styles (False). The 'backup' parameter is entirely undocumented, which is the only material gap.

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 (clear) and resource (cell values/styles within a range) and explicitly bounds scope with 'without deleting rows or columns,' which distinguishes it from delete_rows/delete_columns and insert/delete siblings. An agent can tell exactly what this does versus the rest of the sheet-mutation 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 'without deleting rows or columns' clause implies when this tool is preferred over delete_rows/delete_columns, but there is no explicit when-to-use guidance or named alternative. Usage is left to inference from the scope statement.

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

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

No annotations are provided, so the description carries the full burden. It tells what is copied (contents, formulas, styles) but does not state whether the original sheet remains, whether the copy includes comments, charts, or tables, or anything about permissions or side effects. For a mutation tool with zero annotation coverage, 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?

Front-loaded with the core action, then a clean args list. No wasted words; each sentence earns its place.

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

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

For a 4-parameter mutation tool with no annotations and an output schema, the description covers purpose and three parameters but omits the 'backup' parameter and any behavioral details like what happens to the original or what the return value is. The presence of an output schema reduces the need to explain returns, but the missing parameter and side-effect information leaves it incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It documents path, source_sheet, and target_sheet, adding meaning (e.g., '1-31 chars, valid Excel sheet name' for target_sheet). However, the 'backup' parameter is completely undocumented in both schema and description, leaving one of four parameters unexplained. The description adds value but does not fully compensate for the coverage gap.

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

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

Specific verb+resource: 'Duplicate a sheet including its contents, formulas, and styles.' Clearly distinguishes from siblings like create_sheet or rename_sheet by describing exactly what it copies.

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?

Implied usage: use this when you want to copy an existing sheet. But no explicit when-not-to-use or alternatives (e.g., create_sheet + write_cells). The context of duplicating is clear, but it doesn't tell the agent when to prefer this over other ways to create 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?

No annotations are provided, so the description carries the full burden. It does signal a mutating operation via 'backup: Whether to create a backup before modifying the workbook,' which usefully implies the workbook is written in place. However it omits permissions, error behavior for invalid ranges, and whether the file must already exist.

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 purpose sentence is front-loaded and the Args list is compact and scannable, with each line adding distinct parameter meaning. No filler 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?

An output schema exists, so return values need not be explained, and all 8 parameters are fully covered. The remaining gap is usage/permission context for a write operation, which is modest against the otherwise thorough documentation.

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 0%, so the description must fully compensate, and it does: all 8 parameters are documented with real semantics, including the 'omit if only one file is configured' note for path, optional status of categories_range, and A1-style examples for the range 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?

States a specific verb and resource ('Create a native Excel chart') and immediately enumerates the supported chart types (bar, line, pie, scatter). No sibling tool creates charts, so the resource alone distinguishes it from create_table, create_sheet, and create_workbook.

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 says nothing about when to choose this tool versus alternatives or prerequisites (e.g., does the target sheet/file need to exist first?). The only guidance is embedded in parameter text, not in usage framing.

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

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

No annotations are provided, so the description carries the full burden for a mutating tool. It does not say what happens if a sheet with that name already exists, whether the change is persisted to disk, what the backup parameter does, or whether the workbook must be closed — all meaningful behavioral gaps for 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?

Front-loaded purpose with a compact, well-structured Args block; no filler sentences. Slight redundancy between the schema titles and the arg list, but nothing wasteful.

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

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

An output schema exists so return values need not be described, and the per-parameter notes are helpful. However, for a mutation tool with zero annotations and an undocumented 'backup' parameter, the description leaves key behaviors (name collision, persistence) unaddressed.

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 0%, so the description must compensate. It documents three of four parameters with added meaning (path accepts a preloaded file name; index is zero-based and defaults to append), which is genuinely useful, but leaves the 'backup' parameter completely unexplained.

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 ('Add a new empty sheet to an existing workbook') and the word 'empty' distinguishes it from siblings like copy_sheet and create_workbook. An agent can identify the operation without opening the schema.

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

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

Usage context is implied by the phrase 'an existing workbook' and the arg note 'Omit if only one file is configured', but there is no explicit when-to-use vs. alternatives guidance (e.g., copy_sheet when duplicating content, create_workbook when starting fresh).

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 behavioral burden. It discloses that a Table/ListObject is created and that 'backup' can create a backup before modifying the workbook, but doesn't state what happens on existing ranges (e.g., conversion of data, overwrite of formatting) or permission preconditions. Some value, but incomplete for a mutation tool with no annotations.

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

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

The description is front-loaded with the core action and then uses a structured Args block. It is efficient and each parameter note earns its place, though the list format is a bit text-heavy for what could be a tighter sentence, and 'formal' is slightly redundant with ListObject.

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 8 parameters, mutation semantics, and no annotations, the description covers required inputs and behavior of each optional flag. It omits return value details, but since an output schema exists that burden is lifted. It still lacks error or conflict conditions (e.g., duplicate table_name), so not fully complete.

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

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

Schema description coverage is 0%, so the Args list is the only documentation of parameters. It meaningfully explains every parameter: path preloaded-file behavior, table_name uniqueness across the workbook, style_name example, show_filter dropdowns, show_row_stripes shading, and backup behavior—this compensates fully for the empty schema text.

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

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

States a specific verb and resource ('Create a formal Excel Table (ListObject)'), and ties it to a concrete location ('on the specified range'). This cleanly distinguishes it from table-modifying siblings like write_cells or set_cell_style, and the ListObject terminology removes ambiguity about what entity is produced.

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

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

The description implies usage through required ranges and table naming, but gives no explicit when-to-use or when-not-to guidance, no prerequisites (e.g., sheet must exist, range must be contiguous), and does not reference alternatives. Adequate but leaves the agent to infer timing.

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 burden of behavioral disclosure. It explains the 'real path' requirement and the overwrite behavior, but does not clarify what happens if the file exists and overwrite is False, nor whether parent directories are created. These are significant behavioral gaps for a mutation tool.

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

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

The description is concise and front-loaded with the purpose, followed by a clean Args list. Every sentence adds value, with no redundant or vague text. The structure is easy to scan and understand.

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 the presence of an output schema, the description covers most essential aspects: purpose, parameters, and key constraints. Minor omissions like error behavior on existing files without overwrite prevent a perfect score. Overall, it is nearly complete for a create 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 description thoroughly explains each parameter beyond the schema: path must be real, sheets defaults to 'Sheet1', and overwrite controls replacement. Since the schema has no descriptions, this is essential and well-executed. It provides clear semantics for all three parameters.

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

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

The description explicitly states 'Create a new .xlsx workbook', which clearly identifies the verb and resource. This differentiates it from sibling tools like create_sheet, which likely operates on an existing workbook. The mention of '.xlsx' also specifies the file format.

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

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

The description implies usage for creating a new workbook but does not explicitly mention when to use it over create_sheet or other file-related tools. It does provide contextual clues ('New files aren't preloaded') but lacks direct alternatives or exclusions. Thus, usage guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It usefully discloses the column-shift semantics and the LibreOffice recompute pass with its opt-out, but never states that deletion is destructive/irreversible or what the 'backup' parameter does — significant omissions for a mutation tool.

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

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

Front-loaded with the operation and its effect, then a clean Args block. The parenthetical on recalculate is slightly wordy but earns its place by explaining the rationale rather than padding.

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

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

An output schema exists so return values need no explanation, and the recompute behavior is covered. However, for a destructive operation with zero annotations, the description should flag irreversibility and document the undocumented 'backup' parameter.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for 5 of 6 parameters, including the 1-based indexing semantics of start_column and the default behavior of count and recalculate. It omits 'backup' entirely, which is the one remaining gap.

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

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

States a specific verb+resource ('Delete columns') and adds the mechanical consequence ('shifting the columns to their right leftward'), which distinguishes it from insert_columns/delete_rows behaviorally. It does not explicitly name those siblings, so it stops short of a 5.

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

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

Gives a concrete when-to-use condition for one parameter ('Set recalculate=False ... e.g. for structurally complex workbooks you don't want round-tripped'), but offers no guidance on when to choose this over insert_columns, delete_rows, or clear_range, and no 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the row-shift semantics and the recompute-skip trade-off, but says nothing about irreversibility, the role of the undocumented backup parameter, or how merges/formulas are affected by a destructive operation.

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

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

Purpose and structural consequence are front-loaded, followed by the recalculate nuance and a clean Args list. Slightly verbose as a param list, but each line is informative and no sentence 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?

Output schema exists so return values needn't be described, and the core delete semantics are covered. But for a destructive 6-parameter tool with zero annotation coverage, the absence of the backup parameter's meaning and any warning about irreversibility leaves the definition short of 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?

With 0% schema description coverage the description must compensate, and it does for 5 of 6 parameters, clarifying 1-based indexing, the count default semantics, and the preloaded-file behavior of path. It omits the 'backup' parameter entirely, which is the main gap.

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

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

States a specific verb+resource ('Delete rows') and immediately describes the structural consequence ('shifting the rows below them upward'), which cleanly separates it from siblings like delete_columns, delete_sheet, and clear_range. An agent can identify the operation without opening the schema.

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

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

Gives conditional guidance for one parameter ('Set recalculate=False ... for structurally complex workbooks you don't want round-tripped'), which implicitly tells the agent when to use the non-default path. However, it offers no when-to-use-vs-alternatives routing (e.g. vs clear_range or delete_columns) and no 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?

No annotations are provided, so the description must carry the full burden. It does disclose one important behavioral trait: it fails if it's the only sheet left. However, it omits critical mutation details such as whether the deletion is permanent or recoverable, what happens to cell data/formulas referencing the sheet, and whether a backup is created. The 'backup' parameter exists in the schema but is not explained in the description.

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

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

The description is front-loaded with the core purpose, followed by a key constraint, and then a well-organized Args section. Every sentence earns its place, with no redundant or vague language.

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 basic operation and one failure mode, which is a good start for a 3-parameter mutation tool. However, with no annotations and incomplete parameter coverage (missing 'backup'), it leaves an agent guessing about backup behavior and the permanence of deletion. An output schema exists, so return values need not be explained.

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 0%, so the description must compensate, but it only partially does. The 'path' and 'sheet' parameters are explained in the Args section, providing useful meaning beyond the bare schema. However, the 'backup' parameter is completely undocumented in both the schema and description, leaving one-third of parameters opaque.

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

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

States a specific verb+resource ('Delete a sheet from a workbook') that clearly distinguishes it from siblings like delete_rows, delete_columns, and copy_sheet. An agent can immediately understand the operation from the first sentence.

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 mentions a failure condition ('Fails if it is the only sheet left'), which is useful guardrail context. However, it doesn't explicitly say when to use this versus alternatives like clear_range or delete_rows, nor does it state prerequisites. Usage is implied by the tool name and description but not explicitly guided.

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 must carry the transparency burden. It discloses the data fields returned, but it does not explicitly state that the operation is read-only or describe error behavior (e.g., missing file or invalid cell reference). The verb 'get' implies no mutation, but more explicit disclosure would improve 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 succinct and well-structured. The first sentence states the purpose, followed by a clean Args list with explanations. There is no filler 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?

For a simple get tool with three parameters and no annotations, the description covers the essential aspects: what it does, parameter semantics, and expected return fields. It does not address alternative tool selection or edge-case behavior, but given the simplicity, it is largely complete. The presence of an output schema also reduces the need to detail return values, though the description still lists them.

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

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

The description provides detailed explanations for all three parameters in the Args section, including path semantics (preloaded file or default), sheet name, and cell reference with an example. This fully compensates for the 0% schema description coverage, adding meaning beyond the raw 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's function: 'Get full detail for a single cell' and enumerates the specific aspects (value, formula, number format, font, fill, merge, comment). This distinguishes it from sibling tools like read_sheet or write_cells, which handle ranges or modifications.

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

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

The description implies usage for retrieving detailed cell information, but it does not explicitly mention when to prefer this tool over alternatives (e.g., read_sheet for ranges) or provide exclusions. The context of 'single cell' is clear, but no specific guidance is offered.

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 verb 'Get' implies a read-only operation, but with no annotations, the description doesn't explicitly state that no modifications are made or discuss file access permissions. It adds value by listing the metadata returned, but does not fully disclose behavioral traits.

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 highly concise: a single sentence states the purpose, followed by a brief Args section for the only parameter. Every word earns its place, with no redundancy or filler.

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

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

For a simple read tool with one optional parameter and an output schema, the description covers the purpose, the metadata scope, and the path semantics. It provides sufficient context for an agent to know when and how to invoke it correctly.

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

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

The input schema only provides the parameter name 'path', type (string/null), and a default. The description compensates fully by explaining that path can be an .xlsx path or preloaded file name and when to omit it, significantly adding 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 clearly states the tool's function with a specific verb ('Get') and resource ('workbook-level metadata'), and enumerates concrete items (sheets, dimensions, active sheet, defined names). This distinguishes it from sibling tools like read_sheet or list_sheets.

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

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

The description implies usage for retrieving workbook metadata but does not explicitly state when to prefer this tool over alternatives or provide exclusions. The note about omitting the path when only one file is configured gives some situational guidance, but no direct comparison to 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?

With no annotations, the description carries the full burden of behavioral disclosure. It usefully notes that existing columns shift right and explains the recalculate/LibreOffice recompute behavior, but it omits any mention of the backup parameter, permission requirements, reversibility, or failure modes. This is partially transparent but leaves significant gaps for a mutation tool.

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

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

The description is front-loaded with the tool's effect and uses a clean Args structure. The only minor inefficiency is that the recalculate behavior is described twice, once in a separate note and again in the Args list, but this is not severely wasteful.

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 mutation complexity, the absence of annotations, and an output schema that covers return values, the description is mostly complete for the core parameters. However, it fails to explain the backup parameter at all and provides no safety or permission context, leaving an agent without guidance on a potentially important option.

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 0%, so the description must compensate. It documents five of six parameters (path, sheet, start_column, count, recalculate) with meaningful details like '1-based column index to insert before' and the purpose of recalculate. The backup parameter is left completely undocumented, which is a notable omission.

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 ('Insert blank columns') and immediately clarifies the effect ('shifting existing columns right'), which distinguishes it from sibling tools like insert_rows and delete_columns. An agent can tell what the tool does without opening the schema.

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

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

The description gives no explicit guidance on when to use insert_columns versus alternatives such as insert_rows or write_cells. The only conditional advice concerns the recalculate parameter, not the tool's overall use case. This is similar to the calibration example update_drive, which received a 2 for lacking when-to-use guidance.

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

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

No annotations are provided, so the description must carry the behavioral burden. It does state the key side effect (rows shift down) and that a LibreOffice recompute pass runs by default, plus the consequence of skipping it (unrecomputed formulas). It does not disclose backup behavior, atomicity, or the return value, but it goes well beyond a bare verb.

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

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

Front-loads the action and side effect, then gives a key usage note, then the Args list. Reasonably tight, though the recalculate note is a bit long and repeats information already implied by the parameter name.

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

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

An output schema exists so return values need not be explained, and the description covers the core mutation semantics plus the recompute tradeoff. The omission of the backup parameter and any mention of permission or undo behavior keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It documents path, sheet, start_row (1-based), count (default 1 implied), and recalculate. However, the backup parameter present in the schema is never mentioned in the description, leaving one of six parameters undocumented.

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 (insert) and resource (rows) plus the side effect of shifting existing rows down. This distinguishes it from insert_columns and delete_rows in the sibling list.

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

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

The recalculate=False guidance is a form of usage guidance for one parameter, but there is no explicit when-to-use/when-not-to-use framing vs. append_rows or write_cells. The user must infer that this is for structural insertion rather than appending.

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 carries full burden. It discloses the data source (XLSX_MCP_FILES env var), startup behavior, and that no filesystem search is needed. It stops short of explicitly stating the tool is read-only, but 'List' makes this obvious enough.

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 crisp sentences with the verb and core purpose front-loaded. Every clause earns its place—no wasted words, yet it conveys usage context and cross-tool integration.

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 with no parameters and an output schema exists, so the description only needs to cover purpose and usage context. It fully explains when to call it and how its output feeds into other tools, making it complete for the agent.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline for this dimension is 4. The description adds useful context by explaining how the returned file names integrate with other tools' `path` parameter, but since there are no parameters to describe, it cannot go higher.

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 'List files preloaded at server startup' with a specific verb and resource, and distinguishes this tool from all sibling tools (which operate on sheets/cells, not file inventory).

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

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

Explicitly instructs 'Call this first if unsure which files are available' and explains how the result relates to every other tool's `path` argument, including the optional omission behavior. Provides clear when-to-use guidance with no ambiguity.

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 carry the transparency burden. It adds detail about being approximate and covering every sheet, but does not explicitly state read-only behavior, hidden sheet inclusion, or ordering. This is adequate but lacks depth.

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

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

The description is two sentences plus a parameter block, front-loading the main purpose. No filler words; every sentence adds value.

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

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

For a simple listing tool with an output schema and one optional parameter, the description covers purpose, parameter, and output content. No crucial gaps; however, it could mention whether hidden sheets are included or if there are prerequisites, but these are 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?

The schema has zero description coverage, but the description fully explains the path parameter: path to .xlsx or preloaded file, and when to omit. This adds significant semantic value beyond the schema.

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

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

The description clearly states the tool lists every sheet in a workbook with approximate row/column counts. The verb 'list' and resource 'sheets' distinguish it from sibling tools like read_sheet or get_workbook_info.

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 compare this tool to alternatives or state when to prefer it. It gives context about omitting the path when only one file is configured, which implies usage conditions but does not address 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, so the description carries the full behavioral burden. 'Merge' implies a mutation, but the description never says the file is modified, whether the operation is reversible, whether it requires a backup, or what happens to the non-anchor cell values. It also omits the undisclosed 'backup' parameter entirely.

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 one-line purpose is front-loaded and the Args block is compact and scannable. Slight inefficiency in leaving an undocumented parameter, but no wasted prose.

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

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

An output schema exists, so return values need not be explained. Still, for a destructive document mutation with no annotations, the description should disclose at least the file-modification side effect and the meaning of the backup flag; those omissions leave the definition incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It documents path (including the 'omit if only one file is configured' nuance), sheet, and cell_range with a concrete A1-style example, which is genuinely useful. However, the fourth parameter, backup, is completely undocumented, and no format details beyond the single example are given.

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

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

States a specific verb+resource: merges a rectangular range into one cell. An agent can immediately distinguish it from read_sheet or write_cells. It does not explicitly contrast with unmerge_cells, its obvious inverse sibling, but the operation is unambiguous.

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

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

No guidance on when to use this versus siblings such as unmerge_cells, set_cell_style, or clear_range. Nothing about prerequisites (e.g., a range must contain more than one cell) or what happens if the range is already merged. The only context is the parameter 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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether the tool reads the entire sheet (performance), whether profiling a large sheet has limits, whether it requires the file to be open/unlocked, or any side effects. The argument hints are documented but add little behavioral context.

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

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

Front-loaded with the return payload then a short Args block. Minimal and efficient, though the summary sentence is a terse fragment rather than a full description of what the tool does.

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 annotations and 0% schema coverage, the description does a fair job naming parameters and output fields. But it leaves behavioral questions (full-sheet scan cost, error conditions for a missing sheet, whether the file must be configured first) unanswered, and there is no output schema detail for the profile object shape.

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

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

Schema description coverage is 0%, so the prose args section is the only source of parameter meaning. It explains path (xlsx path or preloaded file name, omit if only one file is configured) and sample_rows (non-null sample values per column), which is helpful, but it omits what 'sheet' accepts and never mentions that sample_rows has a default of 3.

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

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

States a specific verb (profile) and resource (sheet) and enumerates what is produced: metadata, inferred types, null counts, min/max, sample values. That distinguishes it from siblings like get_workbook_info, read_sheet, and aggregate_sheet, though the description never explicitly names those alternatives.

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

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

No when-to-use guidance beyond the implicit 'call it to get profile data'. There is no mention of when to prefer read_sheet or aggregate_sheet, no prerequisites, and no cost or performance context for a profiling operation that likely scans the whole 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?

No annotations are provided, so the description carries the full burden. It usefully discloses a behavioral trait beyond the schema (it avoids loading the whole sheet into context) and states the max_rows default, but it says nothing about read-only safety, behavior on invalid pandas expressions, or error handling for missing sheets/files.

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 purpose sentence is front-loaded before the Args list, and the parameter list is compact with no filler. Slightly docstring-conventional but every line 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 6-parameter query tool with an output schema (so return values need not be described) and no annotations, the description covers purpose, token-efficiency rationale, and all parameters. The main gap is the absence of any safety/permission or failure-mode context, which the missing annotations leave unaddressed.

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 0%, so the description must compensate, and it does: the Args block documents all six parameters, gives a concrete filter_query example ('status == ''PAID'' and amount > 500'), and clarifies path can be a preloaded file name and cell_range restricts reading before querying. This meaningfully exceeds the bare 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 gives a specific verb (Query) and resource (sheet data) plus the mechanism (pandas expressions), and the phrase 'without returning the entire sheet into the LLM context' implicitly distinguishes it from read_sheet. It does not name the relevant siblings explicitly, but an agent can tell it is the filtered/expression-based read path rather than a bulk read.

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: the token-efficiency framing suggests it is preferred over read_sheet for large sheets, but there is no explicit when-to-use/when-not-to-use statement or named alternative. An agent must infer the trade-off against read_sheet and aggregate_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?

No annotations, so the description must carry the behavioral load. It discloses several traits: default format is 'array', max_rows bounds response size, offset_row skips data rows (0-indexed), and cell_range can be omitted for full area. While it doesn't disclaim side effects (implied read-only by verb), this is significant context beyond the schema.

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

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

Well-structured with a clear first sentence stating purpose, followed by a bullet-like Args section. No wasted words; front-loaded purpose statement.

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

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

An output schema exists, so return value explanation is not needed. The description covers all parameters and their semantics, making the tool invocation clear. It could add a note about error conditions or sibling relationships, but for a 6-parameter read tool with full param disclosure, it is largely complete.

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

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

Schema coverage is 0%. The description compensates well: it explains path ('.xlsx file or preloaded file name', and when it can be omitted), cell_range (A1-style example given), max_rows (purpose: 'bound response size'), offset_row (0-indexed from first data row), and format enum options with their meanings. This is substantial added meaning beyond bare property 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?

Specific verb+resource: 'Read cell values from a sheet'. Clearly distinguishes from siblings like get_cell (single-cell read), query_sheet (filtering), aggregate_sheet (computation) by describing a range/full-sheet read.

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 when-to-use guidance or comparison to siblings. The parameter descriptions (e.g., 'Omit to read full used area') imply usage scenarios but do not proactively route the agent, such as telling it to use get_cell for a single cell or query_sheet for filtering.

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 must carry the behavioral burden. It reveals that the operation is headless and reports errors, but it does not disclose whether the workbook file is modified/saved, runtime implications, or any prerequisites. This is a meaningful 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 extremely concise: two sentences plus a compact Args list. It is front-loaded with the action and outcome, and every sentence earns its place.

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

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

For a simple tool with one optional parameter and an output schema, this description covers the operation and parameter semantics adequately. However, it omits explicit guidance on when to invoke the tool and the potential side effects of recalculation. These are minor 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?

Although the schema has 0% description coverage, the Args section thoroughly explains the 'path' parameter, including handling of preloaded files and the omit-if-only-one-file behavior. This fully compensates for the schema's lack of detail.

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

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

The description uses a specific verb ('Force') and resource ('LibreOffice headless recalculation pass') and states the outcome ('report any formula errors found'). It clearly distinguishes from sibling tools, none of which perform recalculation.

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

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

The usage is implied: you would call this when you want to recalculate formulas and check for errors. However, no explicit when-to-use or alternative guidance is provided, and no exclusions are mentioned.

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

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

With no annotations, the description carries the full behavioral burden. It discloses a genuinely valuable non-obvious side effect: formula references to the old sheet name are NOT updated and will break. However, it omits other behavioral traits such as what the mutation requires from the file, and the presence of a `backup` parameter is never explained.

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

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

Front-loaded with a one-line purpose, followed by a high-priority warning and an Args section. Every element earns its place; core purpose and the critical caveat are not 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?

An output schema exists, so return values need not be described. For a mutation tool with no annotations, the description covers the most important risk (broken formulas) but leaves the `backup` parameter unexplained and gives no indication of file/permission requirements, leaving meaningful gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully documents `path`, `old_name`, and `new_name` (including the "1-31 chars, valid Excel sheet name" constraint that the schema lacks), but it completely ignores the fourth parameter `backup`, leaving its semantics unexplained.

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 ("Rename") and resource ("an existing sheet"), which cleanly separates it from sibling mutations like create_sheet, copy_sheet, and delete_sheet. It is clear and non-tautological, though it does not explicitly name a sibling it could be confused with.

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

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

There is no guidance on when to use this tool versus alternatives (e.g., copy_sheet to preserve the old name, or create_sheet). The formula-breaking warning is a caveat about consequences, not a when-to-use/when-not-to-use routing rule, so usage guidance is largely absent.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose two important traits: the operation is atomic, and the target is destructively overwritten. However it is silent on whether the backup file is consumed or left in place, whether a pre-restore snapshot is taken, permission/auth requirements, and failure/rollback 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?

Front-loaded one-line summary carries the essential action and the atomicity constraint; the Args block is compact and adds direction semantics rather than padding. Slightly machine-generated in layout and the param list partly duplicates the schema, keeping it out of 5 territory.

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?

Return values need not be explained since an output schema exists, and both parameters are meaningfully described. But for a destructive, unannotated mutation tool, the description omits prerequisites, side effects on the backup file, and failure semantics an agent would need before invoking 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 0%, so the schema offers only bare 'Backup Path'/'Target Path' titles. The description compensates by giving direction (restore *from* vs. overwrite) and expected file types (.bak vs. .xlsx/.xlsm), which is real meaning the schema lacks. It stops short of documenting path format or relative-vs-absolute resolution.

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 precise verb and resource ('Restore a backup file over a target workbook'), plus the atomicity guarantee. No sibling tool performs a restore or backup operation, so an agent can immediately distinguish this from workhorse siblings like write_cells or create_workbook.

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 says what the tool does but never states when to reach for it, what precondition must hold (e.g. target file must already exist, backup must have been produced by this server), or what alternative to use for non-restore recovery. Nothing about when-not-to-use is offered.

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 transparency burden. It discloses the substring matching behavior, the ability to search one or all sheets, the case-sensitive option, and the limit to bound response size. It does not explicitly state that the operation is read-only, but 'Search' strongly implies non-mutating behavior, making this a solid, though not exhaustive, disclosure.

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 perfectly concise: a single-sentence summary followed by a compact Args list. Each parameter gets exactly one line with clear intent and no redundant information. Every sentence earns its place.

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

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

Given the presence of an output schema (which handles return values), the description covers all necessary input semantics, usage context, and behavioral details. It explains how to handle multiple files, sheet restriction, case matching, and response size, making it complete for this search 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 0%, so the description must fully explain each parameter. The Args section provides meaningful semantics for all five parameters: path (file or preloaded name), query (substring), sheet (restriction or all), match_case (case sensitivity), and limit (response size bound). This goes well beyond the schema's titles and 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?

The description begins with 'Search cell values across one or all sheets for a substring match,' which uses a specific verb (Search), resource (cell values across sheets), and scope (substring match). It clearly distinguishes from sibling tools like read_sheet or get_cell by emphasizing search semantics.

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

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

The description provides clear context on when to use the tool: whenever substring search across sheets is needed. It explains how to restrict to one sheet ('Restrict the search to one sheet; omit to search every sheet') and mentions omitting path when only one file is configured. No explicit alternatives are listed, but the search-focused purpose inherently guides 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?

No annotations are provided, so the description carries the full behavioral burden. It never states that this mutates the file, whether existing formatting on the range is overwritten or merged, or what the 'backup' parameter actually does — a parameter that exists in the schema but is entirely absent from the description. For an unannotated mutation tool this is a meaningful 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?

Front-loaded with the one-line purpose, then a tight Args block with no filler. The style-key enumeration is dense but every line is useful. Slightly list-heavy rather than prose, but appropriately sized for a 5-parameter tool.

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

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

An output schema exists, so return values need not be explained, and the style-key documentation fills the biggest schema gap. However, for an unannotated mutation tool the description should at least mention mutability/reversibility and document the undocumented 'backup' parameter; those omissions keep it at a minimum-viable level.

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 0% and the style object is only typed as a free-form object, so the description does the real work: it enumerates all valid style keys (bold, italic, font_size, font_color, bg_color, horizontal, vertical, border, number_format) and even gives hex format examples. It adds substantial meaning beyond the schema. It loses a point for omitting the 'backup' parameter entirely.

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

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

The description opens with a specific verb+resource: 'Apply formatting to a range of cells.' This clearly distinguishes it from value-writing siblings like write_cells or clear_range. It stops short of naming any sibling explicitly, so it does not reach the top score.

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 or when-not-to-use guidance, no note about style vs. value siblings, and no prerequisite information. The Args block documents parameters but never says when this tool is the right 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?

No annotations are provided, so the description carries full behavioral burden. It signals a mutation (undoing a merge) but says nothing about whether existing content in the merged range is preserved, what happens if the range is not merged, permissions, or reversibility.

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

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

One-sentence purpose followed by a clean Args block; front-loaded and free of filler. Slightly verbose in the args prose but every line adds meaning.

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

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

An output schema exists, so return values need no explanation, and the core params are covered. However, for a mutation tool with zero annotation coverage, the absence of any error/reversibility guidance and the missing backup param leave real gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It documents path (including the preloaded-file case and the omit-if-single-file rule), sheet, and cell_range in useful detail, but the fourth parameter, backup, is entirely undocumented in both the schema and the description.

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

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

The description opens with a specific verb+resource ("Undo a merge on a range of cells"), which is immediately distinguishable from the sibling merge_cells. An agent knows exactly what this does without reading the schema.

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

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

Usage is implied by the name and the phrase "previously merged," but the description never states when to use it versus merge_cells, nor any precondition (e.g., the range must currently be merged). No alternatives or exclusions are named.

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

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

No annotations are provided, so the description carries the full burden. It describes the recalculation side effect, the opt-out behavior, and reveals a return field (errors_found), which is valuable behavioral context. However, it does not mention auth, backup semantics, or whether writes are destructive/reversible.

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

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

Front-loads the core purpose, then uses a structured Args/Returns layout. The recalculate conditional is called out early. Some duplication of schema parameter names is necessary given the 0% coverage, so it is appropriately sized with minor 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?

For a mutation tool with no annotations and partial parameter documentation, the description covers the key behavior (write + recalculate) and return behavior (errors_found). The gaps are the two undocumented boolean parameters, which leaves the definition slightly incomplete for its complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It documents path, sheet, cells (with format examples), create_sheet_if_missing, and recalculate. It omits backup and allow_external_formulas, so it does not fully cover all seven 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?

States a specific verb (write values/formulas) and resource (specific cells) plus the recalculation behavior. It is clear what the tool does. It does not explicitly distinguish itself from siblings like append_rows or clear_range, which a stronger definition would call out.

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 a conditional usage hint: set recalculate=False for structurally complex workbooks. This implies when to use an argument but not when to choose write_cells over append_rows or query_sheet. Usage context is implied rather than explicit.

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