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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description implies mutation (appending a sheet) but doesn't state whether it overwrites an existing sheet with the same name, whether file locking is needed, whether there's an error if the file doesn't exist, or what happens on failure. For a mutation tool with zero annotation coverage, the behavior around edge cases is undocumented.

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, efficient sentence with zero waste. Every word earns its place by clarifying the operation (append), the resource (empty sheet), and the precondition (existing file). It's appropriately front-loaded and concise.

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

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

For a simple 2-parameter tool with 100% schema coverage and no output schema, the description is mostly adequate. However, because this is a mutation tool with no annotations, it would benefit from mentioning failure behaviors (e.g., duplicate sheet name error, nonexistent file error) or confirming the action is non-destructive to existing sheets. The simplicity of the tool keeps this at a 3 rather than lower, but there's room to add error-handling context.

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

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

Schema coverage is 100%, so both filePath and sheetName are fully documented in the schema with descriptions including path format examples and character restrictions. The description adds minimal value beyond the schema (it clarifies the tool appends an empty sheet), but since the schema already does the heavy lifting for parameter documentation, the baseline 3 is appropriate.

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

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

The description '在已有文件中追加一张空工作表' clearly states the verb (append) and resource (an empty sheet in an existing file). It differentiates from siblings like list_sheets, delete_sheet, and rename_sheet, though it doesn't explicitly distinguish from create_workbook (which creates a new file). The purpose is clear and specific enough.

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 ('在已有文件中' - in an existing file) which distinguishes it from create_workbook (which creates a new file). However, there's no explicit when-to-use or when-not-to guidance naming alternatives. The sibling tools like read_range/write_range operate on ranges, so the distinction is somewhat implied but not explicitly spelled out.

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 burden. It discloses the critical safety behavior: failing rather than overwriting an existing file ('文件已存在时会失败（防误覆盖），不会清空已有文件'). It confirms write intent through '新建'. Covers key behavioral traits for a file-creation tool.

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

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

Two concise sentences with zero waste. Every sentence earns its place: first states the core action and sheet-name flexibility; second discloses the anti-overwrite safety behavior. Front-loaded with the primary purpose.

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

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

For a 2-param creation tool with no output schema, the description covers purpose, the one optional param (sheets), and the destructive-safety behavior. Minor omission: doesn't specify return value, but for a creation tool this is low-stakes given no output schema and the tool's simplicity.

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 50% (filePath is documented in schema; sheets is documented but the description adds the ability to specify initial sheet names via '可指定初始工作表名列表'). The description adds minimal meaning beyond schema, matching the baseline-3 score for moderate coverage.

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

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

Description states a specific verb+resource ('从无到有新建一个 .xlsx 文件') and clearly distinguishes the create/initialize behavior from siblings like add_sheet and rename_sheet. It explicitly scopes creation to 'from scratch' and notes the file-creation 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 implies when to use (when you need to create a new workbook) and distinguishes from file-modification siblings. It mentions the failure behavior when a file already exists, which guides usage, though it does not explicitly name alternative tools for existing-file scenarios.

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

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

With no annotations provided, the description carries the full burden and does well: it explicitly discloses that the file IS modified ('会修改文件'), that rows are deleted by becoming blank rather than removed (space-preserving, preventing content shift), and that content outside the range is untouched. This is rich behavioral disclosure, though it doesn't mention effects on merged cells or formatting.

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

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

Three sentences, zero waste. The core action is front-loaded in the first sentence, followed by precise edge-case behavior. Every clause earns its place and communicates critical side effects the agent must know.

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

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

For a mutation tool with no annotations and no output schema, the description covers the essential operational aspects: mutation behavior, blank-vs-delete semantics, and range scoping. The only notable gap is hasHeader handling, but overall the description is complete enough to select and invoke this tool correctly among 14 siblings.

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

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

Schema description coverage is 40%. The description explains the semantics of keyColumns (rows identical across those columns are deduped) which adds meaning beyond the schema. However, it doesn't explain hasHeader's effect on deduplication logic, despite hasHeader being a present boolean parameter. Description only partially compensates for the uncovered parameters.

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

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

The description clearly states specific verb+resource: '删除区域内 keyColumns 完全相同的重复行' (delete duplicate rows in range with identical keyColumns), plus concrete behavior details like '只保留第一次出现的行' and '会修改文件'. It distinguishes from sibling sort/filter/merge tools by focusing on deduplication of rows within a specific range.

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 context (deduping within a delimited area of a spreadsheet) and explicitly notes the range scope ('区域外的内容不会被移动'). However, it does not state when NOT to use this versus alternatives, or when to prefer read_range/write_range or sort_range instead. No exclusions or explicit alternative 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 carries the full burden. '删除' (delete) clearly implies destructive behavior, and '不能删除最后一张' adds a meaningful operational constraint. However, it doesn't disclose whether deletion is reversible, whether confirmation is needed, what happens to data in the sheet, or the return value on success/failure.

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 at one sentence with two clauses. Both carry meaning: the action and the critical constraint. Zero wasted words.

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

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

For a 2-parameter tool with a fully-covered schema and no output schema, the description is adequate but could be richer. The destructive nature combined with no annotations means the behavioral context (irreversibility, data loss) is left unsaid. The last-sheet constraint is documented, which is the most operationally important caveat, but the risk profile of the operation is under-emphasized.

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

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

Schema description coverage is 100%, so both parameters (filePath with path format examples and supported extensions, sheetName with character and length constraints) are well-documented in the schema. The description adds minimal parameter-level detail beyond what the schema already provides, meriting the baseline 3.

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

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

The description states a specific verb+resource ('删除指定工作表' - delete specified worksheet) and adds a critical scope constraint ('不能删除最后一张' - cannot delete the last one). It distinguishes from siblings (add_sheet, rename_sheet, list_sheets) clearly as the deletion operation, though it doesn't explicitly name 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?

The description includes one key usage constraint (cannot delete the last sheet), which is valuable operational guidance. However, it doesn't explicitly explain when to use this vs alternatives like add_sheet or rename_sheet, nor mention any prerequisites or conditions beyond the last-sheet restriction.

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 discloses that the tool is non-destructive ('不修改文件' = doesn't modify file), which is valuable. However, it doesn't describe the return format (does it return matched row indices, values, or both?), behavior with headers vs. without, or edge cases like no matches. For a tool with zero annotation coverage, more behavioral disclosure would be expected.

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 concise sentences, front-loaded with the primary action and the critical non-modification guarantee. Every sentence earns its place; no filler. Could arguably add a note about return values but remains tight and efficient.

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

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

The tool has 5 parameters with 40% schema coverage, no output schema, and no annotations, creating moderate complexity. The description explains the non-destructive nature and AND-condition semantics but leaves open: how results are returned, handling of hasHeader, and column referencing convention. This is a filtering operation that should be fairly predictable given the sibling context, but the missing return-format information is a notable gap.

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 40%, with some parameters documented (filePath, range) but sheetName and hasHeader lacking schema descriptions, and the tool title is Chinese while descriptions are partial. The description adds 'AND' semantics for the conditions parameter, which isn't in the schema. However, it doesn't explain what 'column' refers to (header name vs. column letter), the meaning of hasHeader, or how conditions map to columns, leaving gaps in parameter understanding.

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

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

The description states the verb ('按条件筛选' = filter by conditions), resource ('区域中的行' = rows in range), and adds a key behavioral note ('不修改文件' = doesn't modify file). It's clear it filters rows in a range, distinguishing it from siblings like sort_range and dedupe_range which also operate on ranges but with different actions. However, it doesn't explicitly name a sibling alternative for differentiation.

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

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

The description notes that multiple conditions are joined with 'AND' logic, which is useful selection guidance. However, it doesn't state when to choose this over alternatives like sort_range, read_range, or dedupe_range, nor does it offer exclusions or prerequisites. The usage context is implied by the tool name and sibling set but not explicitly articulated.

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 transparency burden. It discloses the partial-update behavior (only passed fields are changed) and the csv limitation, which is useful. However, it doesn't disclose what happens to existing styles, whether the operation is reversible, any formatting constraints (e.g., color format expectations like hex vs names), or any side effects. For a mutation tool on files, some risk disclosure would help, but the description covers the most important behavioral aspects.

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

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

Three short sentences, each earning its place: the purpose, the key partial-update rule, and the csv limitation. Front-loaded with the verb+resource purpose, then trailing with usage-critical caveats. Zero waste.

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

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

This is a moderate-complexity tool with 4 params and nested style objects. The description explains the partial-update semantics and csv constraint, which are the two most important behavioral aspects. The nested style schema is self-documenting, and there's no output schema to worry about. It could benefit from noting color format examples or what 'style' default behavior is, but overall it's reasonably complete for a formatting 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 50%, so the description partially compensates by enumerating what style categories can be set (font, fill, border, alignment, number format) and explaining the partial-update semantics. It adds the 'don't pass what you don't want to change' meaning beyond the raw schema. However, it doesn't explain color format requirements (hex?) or the nested structure specifics, though the nested style schema is fairly self-explanatory.

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

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

The description clearly states the verb 'set' + specific resource (cell styling for font, fill, border, alignment, number format), with a clear purpose of making spreadsheets look better. It distinguishes from sibling tools—none of the read/write/data manipulation siblings handle visual formatting, so this is uniquely positioned.

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

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

It explicitly states a key usage rule: '只传想改的项，没传的不动' (only pass what you want to change; unpassed items are untouched), which is critical usage guidance for partial style updates. It also mentions that csv files don't support styles, which is a proper exclusion/limitation note. It doesn't explicitly name alternative tools for when-to-not-use, but the purpose is distinct enough that this isn't a major gap.

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

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

No annotations are provided, so the description carries the burden. It does disclose the default 300x200 sizing behavior and the csv limitation, which is good. However, it doesn't disclose behavioral details like whether insertion overwrites existing content, what happens if anchorCell is occupied, whether the operation mutates and saves the file, or any permission/format constraints beyond csv.

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

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

Three concise sentences, front-loaded with the core action. Each sentence earns its place: action+format, sizing defaults, csv caveat. Slightly compressed but efficient.

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

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

With no output schema and no annotations, the description must carry completeness. It covers formats, defaults, and csv caveat well. But for a mutation tool (inserting into a file), it omits details like: does it save the workbook? What if anchorCell is invalid or occupied? Are there size limits on the image? What happens to existing overlapping content? These gaps matter for a tool with no annotation safety net.

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 low (33%), with only filePath and anchorCell having descriptions. The tool description compensates well by explaining semantics for key params: width/height are pixels with a 300x200 default, anchorCell is where the image's top-left corner anchors. However, imagePath and sheetName lack any schema or description elaboration beyond what their names imply, though these are fairly self-explanatory.

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 inserts a local image (png/jpg/gif) into a worksheet, anchored at anchorCell. It distinguishes from siblings (none of which are image-related) and specifies the file types. However, it doesn't explicitly differentiate across the full sibling set since no other tool inserts images, though it's clear enough in its own right.

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 useful practical guidance: explicit mention that csv doesn't support images, and that width/height should be passed explicitly when aspect ratio matters. However, it doesn't provide explicit 'when to use vs not use' guidance or mention prerequisites like the file/sheet needing to exist, or when this tool would be preferred over alternative approaches.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It transparently indicates the tool is read-only ('动手读/写之前可以先调它确认') and discloses it returns worksheet names and dimensions (行/列 counts). It doesn't mention file-format handling details or error behavior, but for a simple list operation this is adequate.

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

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

Single, compact sentence that conveys both purpose and usage guidance without verbosity. It's front-loaded with the core purpose and ends with practical usage advice. Slightly more could be trimmed, but it's efficient and wastes no words.

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

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

For a simple single-parameter read-only tool, this is complete. It specifies what it returns (sheet names, row/column counts), the use case (pre-flight check), and supports the correct schema. Mutation tools would need more disclosure, but for a listing operation the description is well-aligned with 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 100%, so the schema documents the single filePath parameter thoroughly (absolute path, format support, examples). The description adds marginal value by framing the parameter's purpose in context but doesn't go beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: view which worksheets exist in an Excel file and their row/column counts. It uses a specific verb+resource (查看/match worksheets in a file), and distinguishes it from siblings like add_sheet, delete_sheet, rename_sheet by making clear this is a read-only inspection tool.

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

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

The description gives explicit usage context: call this tool before read/write operations to confirm sheet names. This is clear contextual guidance. While it doesn't explicitly name alternatives (like read_range for reading data), the 'confirm before read/write' framing is a strong usage guideline that separates it from mutation siblings.

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

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

No annotations are provided, so the description carries the disclosure burden. It does disclose the key behavioral trait (content retained from top-left, other cells' content lost or discarded). However, it doesn't disclose whether the merge is destructive to other cells' values, whether there are limitations (e.g., cannot merge across sheets), or whether it can be undone. The top-left value behavior is the most critical disclosure and is present.

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?

Single efficient sentence that conveys purpose, behavior, and a common use case in compact form. No wasted words. Could arguably add a bit more behavioral detail, but it's appropriately sized for the 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?

Moderate complexity tool with no annotations and no output schema. The description covers the core operation and behavior but lacks important context: what happens to values in non-top-left cells (destroyed vs preserved silently), whether merge is reversible, and file format caveats given .csv support (csv may not support merged cells). For a tool that modifies a workbook, more edge-case context would improve completeness.

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 67% (range and filePath have descriptions, sheetName does not). The description adds the 'top-left value retained' semantics that matter for understanding the range parameter, but doesn't add information about filePath or sheetName beyond the schema. It partially compensates for the sheetName gap but doesn't fully cover it.

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

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

Clear verb+resource: merges a rectangular range into one cell, with explicit behavior (keeps top-left value). The mention of '常用于标题行' adds typical use context. It doesn't explicitly distinguish from sibling tools like format_cells or sort_range, but the operation is distinct enough that 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?

Implies usage for creating header/title rows ('常用于标题行'), which gives some context. However, it doesn't provide exclusions or when-not-to-use guidance—e.g., no mention that merging may affect other operations, or when to prefer format_cells for styling instead. Guidance is adequate but minimal.

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

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

With no annotations provided, the description carries full burden. It discloses key behaviors well: empty cells return null, dates are ISO strings, return type is 2D array. These are precisely the behavioral quirks (null handling, date formatting) that would trip up an agent. Minor gap: doesn't mention authorization/permissions or what happens with out-of-range requests, but the core runtime behavior is well covered.

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

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

Three short sentences, front-loaded with the core purpose, then pragmatic usage advice, then return-format notes. Every sentence adds value. Could perhaps trim, but it's tight and well-ordered. No fluff 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?

For a read tool with 3 params and no output schema, the description handles the main edge cases (empty cells, dates, large sheets). The null/ISO-date contract partially substitutes for an output schema. It doesn't explain sheetName default behavior, and performance limits aren't quantified, but for a moderately simple read command the completeness is strong.

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 67% (filePath and range have descriptions; sheetName only has minLength). The description compensates by explaining the range parameter's semantics (optional, whole-sheet when omitted, partial read recommendation) beyond the schema's terse '矩形区域'. The date/null return semantics add meaning to what's expected. Slight gap: sheetName behavior when omitted isn't explained.

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

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

Description clearly states '读取一张工作表的内容，返回二维数组' (read worksheet content, return 2D array), with a specific verb+resource. It distinguishes scope clearly (whole sheet vs range) and is conceptually distinct from siblings like write_range or sort_range. The title matches the function precisely.

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?

Description gives explicit guidance: '不传 range 则读整张表；表很大时建议先传 range 读一部分（如前 50 行）了解结构' — tells the agent when to omit range (small sheets) and when to include it (large sheets, read first 50 rows). This is practical, concrete usage direction that directly distinguishes the read operation from write/format/sort siblings.

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

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

No annotations are provided, so the description carries the burden of disclosure. It states the core action (rename) but doesn't disclose behavioral traits like whether oldName must match exactly/case-insensitively, or what happens if the target name already exists.

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 efficient sentence ('修改工作表名称。') with zero waste. It is appropriately brief, though it borders on under-specification.

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

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

For a mutation tool with no annotations and no output schema, the description should do more: clarify what happens on collision (renaming to an existing sheet name), whether Excel formula references are updated, and confirm the file must already exist. The description is minimal for a tool with 3 required parameters.

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 67% (newName and filePath have descriptions, oldName does not). The schema itself describes the newName constraints well, but the description adds nothing beyond restating the action. The oldName parameter's semantics are only implied by the tool name.

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 it modifies a sheet name (修改工作表名称), which is clear and specific. It distinguishes from siblings like add_sheet/delete_sheet, though it doesn't explicitly reference them.

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

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

There is no guidance on when to use this tool vs alternatives. It doesn't mention that the sheet must exist, whether renaming affects formulas/references, or distinguish from add/delete operations.

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 disclosure burden. It discloses default units (8.43 chars width, ~15 points height) which is useful context. However, it doesn't explain return values, whether this is a mutating operation requiring save, or what happens on partial failures. The defaults disclosure is helpful but the mutation consequences aren't fully spelled out.

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

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

Three tightly-scoped sentences that front-load the purpose, then add unit semantics, then the constraint and exclusion. Zero filler words, every sentence earns its place. The critical usage constraints (at least one of columns/rows) and format exclusion are placed last but clearly.

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

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

Given a mutation tool with no annotations, no output schema, and low schema coverage, the description provides the essential operational details: units, defaults, the at-least-one constraint, and the CSV exclusion. It's missing explicit behavior notes on mutations (e.g., whether changes persist immediately) but for a dimension-setting utility this is reasonably 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 low (25%), so the description must compensate. The description adds real meaning beyond the schema by explaining the units (character count vs points) and defaults, which the schema only implicitly references via examples. The nested params (rows/columns arrays) are well-documented in the schema itself, and the description clarifies the semantic meaning of the numeric values.

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

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

The description clearly states the verb+resource (set column widths and/or row heights for a worksheet) with specific units given for both dimensions (characters for width, points for height). It distinguishes itself from siblings like format_cells by focusing specifically on dimension layout rather than cell formatting. The scope is precise and actionable.

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

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

The description explicitly states the 'at least one of columns or rows must be provided' requirement and includes the key exclusion 'csv 不支持' (CSV not supported), which prevents the agent from attempting this on unsupported file types. While it doesn't name alternative tools explicitly, the sibling context and clear scope make usage clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait: formulas aren't evaluated until opened in Excel/WPS, so reading the cell returns null. This is genuinely useful. However, it doesn't mention whether existing values in the cell are overwritten, required file-open state, or permission needs — moderate gaps for a mutation tool with zero annotation support.

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

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

Two sentences, front-loaded with the core purpose and example, followed by one critical behavioral note. Zero wasted words 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 4-param mutation tool with no output schema, this is fairly complete. The critical behavioral caveat (formula not evaluated until opened, returns null on read) is disclosed, which is the main thing an agent needs to know. The main gap is that sheetName receives no description in either schema or description, and there's no mention of what happens on write or error conditions, but the core semantics are well covered.

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

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

Schema description coverage is 75%, so most parameters (filePath, cell, formula) are already described in the schema. The description adds meaningful value by explaining the optional leading '=' for the formula and the null-read behavior, which the schema's formula description doesn't capture. The sheetName has minimal schema description, and the description doesn't compensate for it, but overall the value-add over schema is notable.

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 writes an Excel formula into a specified cell, with a concrete example (SUM(A1:A10)). It's specific about the verb (write) and resource (Excel formula in a cell). However, it doesn't explicitly contrast with siblings like write_range or format_cells, though 'formula' is reasonably distinctive given write_range is a sibling — the distinction is somewhat implicit rather than 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?

The description provides a critical usage context: the formula won't be calculated until opened in Excel/WPS, and reading the cell returns null. This gives strong guidance on when to use this tool (vs. expecting immediate values) and warns about expected behavior. It doesn't name explicit alternatives but the context signal about formula evaluation is valuable and informative.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that the operation '会修改文件' (will modify the file) and that content outside the range is untouched ('区域外的内容不动'). This is meaningful behavioral disclosure for a mutation, but it doesn't clarify whether sorting is reversible, what happens to formulas/formatting within the range, or the default ordering direction beyond the enum. Decent but not rich 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?

Two sentences, entirely functional, zero filler. Slightly longer than the TDQS high example due to two distinct clauses but each earns its place. Front-loaded with the core purpose then adds behavioral and usage notes efficiently. Very compact for the guidance it delivers.

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?

No output schema and no annotations means the description must carry a lot. For a mutation tool with 6 parameters and 33% schema coverage, it covers the essential behaviors (sort, file modification, header handling, safe column referencing) quite well. However, it doesn't address edge cases like missing header handling, whether sort is stable, or behavior with merged cells/blank key cells. Adequate but leaves room.

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 only 33% (only filePath and range have schema descriptions). The description compensates by explaining the hasHeader parameter's role ('用表头名指定列更稳妥'), which adds value beyond the plain boolean schema. keyColumn semantics ('按某列排序') are clarified implicitly. Good compensation for low schema coverage, though keyColumn format could be more explicit.

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

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

Description states '对一个区域按某列排序' (sort a range by a column), with a specific verb+resource. It distinguishes sorting (reorders rows) from siblings like filter_range and dedupe_range via the phrase '会修改文件' and '区域外的内容不动'. However, it doesn't explicitly contrast with the closest siblings, so it stops short of 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?

Provides clear use context: mentions '有表头时传 hasHeader: true 并用表头名指定列更稳妥' (when header exists, use hasHeader:true and specify column by header name is safer). This gives practical guidance on when to set flags. However, it doesn't explicitly say when NOT to use this tool or name alternative tools for other scenarios, slightly short of 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: null values clear cells (not just write null), strings are not auto-interpreted as formulas, and there's a dependency on sheet existence. It doesn't describe return value or whether writes are committed/appended, but given no output schema and no annotation, the disclosed behavioral traits are substantial and helpful.

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

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

The description is compact (4 sentences) and front-loaded with the core write operation, then adds the single/multi-cell nuance, null semantics, formula caveat, and sheet prerequisite in efficient order. Every sentence earns its place with no fluff or repetition.

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

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

The tool is moderately complex (2D array input, multiple formats via filePath, a sheet-dependency). The description addresses the key complexity: how to shape values, null handling, formula distinction, and sheet existence prerequisite. It doesn't cover format-specific behaviors (e.g., .csv quirks) or return values, but with 14 sibling tools and no output schema, it covers the essential decision points an 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 coverage is 75% (values, filePath, startCell have descriptions; sheetName lacks one). The description adds meaning beyond the schema: it explains row-major ordering, the [[value]]/multi-row/col shapes for values, and clarifies the null semantics and formula behavior. The mostly-undocumented sheetName param dependency (must exist) is partially addressed. This adds genuine value over 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?

Description states a specific verb (write) + resource (a 2D array starting from startCell, row-major order). It clearly distinguishes from siblings: explicitly contrasts with set_formula ('字符串不会被套公式——要写公式请用 set_formula') and mentions empty-cell handling via null. This differentiates it well from read_range and set_formula.

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

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

Provides explicit when-to-use guidance: single cell pass [[value]], a region pass multi-row/col, null clears cells, formulas require set_formula instead, and the target sheet must already exist (use add_sheet otherwise). These are concrete usage instructions that an agent can act on, including a named alternative tool (set_formula, add_sheet).

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