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

With no annotations, the description must carry the full behavioral burden, and it does disclose two critical traits: the tool is DRY RUN BY DEFAULT, and name is validated for length, forbidden characters, and case-insensitive uniqueness. However, it punts on the semantics of output, overwrite, and allow_loss by deferring to set_cells, so the agent cannot tell from this definition what gets overwritten or lost.

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 definition is dense and front-loaded, leading with the action before constraints, with no filler sentences. The terse 'work as in set_cells' clause trades clarity for brevity, which is the one place where compression costs the reader.

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 description covers validation and the dry-run default well. For a 7-parameter, zero-annotation tool it is still incomplete: the overwrite/allow_loss behavior determines whether data can be destroyed, and that is left entirely to another tool's 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% across 7 parameters, so the description has to compensate, and it partially does: name validation rules and position's 1-based indexing plus default are genuine additions beyond the schema. But three of the seven parameters are explained only by cross-reference to another tool, which is a real gap for a mutation-adjacent operation.

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 and resource: 'Add an empty sheet.' This is unambiguous and clearly distinct from siblings like rename_sheet or set_cells, though it never explicitly names those alternatives to reinforce the distinction.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no named alternative for cases where the agent should modify an existing sheet instead. The only implicit routing signal is the dry-run default, which tells the agent the call is a no-op unless dry_run is disabled.

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

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

With no annotations, the description carries the full burden and does so well: dry run is the default, number formats and styles are copied from the row above, rows start in the first used column, table ranges grow, and the call warns when data validation or conditional formatting ranges will not cover new rows. These are exactly the side effects an agent must know before invoking a mutation.

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 and the dry-run warning, then organized as compact per-parameter notes with no filler sentences. The 'work as in set_cells' line offloads detail to a sibling rather than explaining it, which is efficient but leaves a small gap.

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 behavioral risks of a mutation tool thoroughly. Remaining gaps are the meaning of path (does the workbook need to exist?) and sheet, plus what a dry run actually returns.

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% across 8 parameters, so the description must compensate. It explains the tricky ones in depth: rows coercion rules (formula, leading quote, ISO dates, null = empty cell), table semantics plus failure conditions, dry_run via 'DRY RUN BY DEFAULT', and output/overwrite/allow_loss by reference to set_cells. It never describes path or sheet, and the cross-reference to set_cells assumes knowledge of that sibling's 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 target: 'Append rows after the last data row (or to the bottom of an Excel table).' The scope, the insertion point, and the table-extending alternative are all named, so it is distinguishable from set_cells, which it explicitly references for shared 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?

Gives concrete conditions and refusal cases: refuses when the last data row belongs to a table and table= is omitted, refuses tables with a totals row, refuses if the space below is not empty. It does not draw an explicit 'use append_rows instead of set_cells when…' contrast, but the append-at-end framing makes the choice reasonably clear.

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

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

No annotations are supplied, so the description carries the full burden, and it does substantial work: 'nothing is calculated' signals pure read-only analysis with no side effects, and it discloses that results are grouped per kind and truncated by max_issues. It stops short of stating error conditions (e.g. non-xlsx files) or whether issues are deduplicated.

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 lead sentence states the action and the crucial non-calculation caveat first, then the long list of detections follows. The parenthetical examples are dense but each clarifies a category; the enumeration is lengthy yet nearly every item 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 three-parameter read-only audit tool with an output schema already documenting the return shape, the description covers what is detected, the scope control, and the result cap. Nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for two of three parameters: sheet= restricts scope to one sheet and max_issues caps results per kind. The path parameter is left implicit, but its meaning is self-evident from the other file-based siblings.

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 ('Audit formulas structurally') and immediately scopes it with 'nothing is calculated', which distinguishes it from read_range or find_cells. The enumeration of detected problem classes makes the tool's domain unmistakable.

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 it (structural formula auditing rather than value inspection) and adds one concrete usage hint, 'Use sheet= to check one sheet', but never explicitly contrasts it with siblings like find_cells or read_range, nor states 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?

With no annotations, the description carries the full burden and does well: it states that a wrong encoding raises an error rather than silently garbling data, that existing output is refused unless overwrite=true, and that leading-'=' fields are deliberately kept as text to avoid formula injection. It omits permission/side-effect details such as whether the source CSV is modified or what happens with sheet_name conflicts.

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, then dense per-parameter notes with no filler. The notes run as continuous wrapped prose rather than discrete items, which slightly hurts scannability, but essentially every sentence 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?

An output schema exists, so return values need not be described; against that, the description covers the risky behaviors (encoding errors, overwrite refusal, type inference rules and formula safety) that an agent needs before calling a 7-parameter conversion tool. Only minor gaps remain (sheet_name semantics, source file 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%, so the description must compensate, and it supplies genuine meaning for encoding, delimiter, infer_types and overwrite, including concrete value examples and edge-case rules (leading zeros, 15-digit cap, ISO dates). It leaves sheet_name and the path parameters unexplained, but csv_path/output are self-evident from their names.

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

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

The opening line gives a specific verb and both source and target formats: 'Convert a CSV/TSV file into a new .xlsx.' The word 'new' plus the overwrite rule makes the direction and effect unambiguous, and it is clearly distinct from the sibling xlsx_to_csv.

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 useful situational guidance embedded in the parameter notes (e.g. semicolon delimiters are common in Turkish/German Excel exports, set infer_types=false to force all text), but the description never explicitly says when to choose this tool over an alternative or states exclusions/prerequisites. Usage is implied rather than prescribed.

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 behavioral burden and does well: it discloses the profiling output, header auto-detection, range defaults, and formula/constant/mixed detection. However, it does not mention max_rows truncation, performance characteristics, or read-only/error behavior.

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

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

The description is front-loaded with the core purpose, then moves into compact parameter notes. Every clause contributes profiling detail or non-obvious input semantics, with no wasted wording.

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

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

Given that an output schema exists, the description need not explain return values, yet it still adds useful output context. It covers the most non-obvious input behaviors, but leaves gaps around max_rows and sibling-tool selection.

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 carry parameter meaning. It documents header_row very well and explains range's default, but it omits path, sheet, and especially max_rows, which can affect how much data is profiled.

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: "Profile the columns of a sheet or range like a data table." It also enumerates the profile dimensions clearly. It does not explicitly distinguish this tool from overlapping siblings such as read_range or check_formulas, so it falls 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite sibling tools that could overlap, especially check_formulas and read_range. The header_row and range notes are parameter guidance, not routing 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 does disclose useful traits: search is case-insensitive by default, it folds Turkish dotted/dotless i and marked letters, and each hit reports sheet, address, value and formula. It omits what happens when there are no matches, how results are truncated at max_results, and whether scanning is expensive on large workbooks.

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 one-line purpose, then breaks mode/search_in into labeled lines, which is easy to scan. The Turkish case-folding paragraph is longer than strictly necessary for most callers, but it is placed last so it does not obstruct the core instruction.

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-field explanation is a bonus rather than a necessity, and the description still names the fields per hit. For a 7-parameter search tool the only real gap is truncation/limit behavior and the semantics of path, which keeps it out of the top band.

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% across 7 parameters, so the description must compensate. It well explains mode (with examples: substring, Python regex, numeric equality) and search_in (values/formulas/both), and implies sheet scoping, but says nothing about path, max_results, or case_sensitive as an explicit parameter (the Turkish-folding note only hints at the default).

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

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

States a specific verb and resource ('Find cells') plus scope ('across all sheets (or one)') and the return form ('return their addresses'). It does not explicitly contrast itself with read_range or describe_columns, so the agent must infer the read-vs-search distinction from the sibling names.

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 concrete usage contexts for mode and search_in, including a worked example ('find every cell that uses VLOOKUP') that makes the intent of 'formulas' unambiguous. It stops short of naming alternatives or exclusions (e.g., when to use read_range or describe_columns instead, or whether to prefer a sheet-scoped search for large workbooks).

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

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

With no annotations, the description carries the full burden and does so well: it discloses clamping beyond the used range, that formulas are never calculated and missing cached values are reported rather than blanked, that merged ranges are enumerated, and that responses carry date-format and number-format notes. Gaps remain around failure modes (missing path, unknown sheet name) and any size limits beyond max_cells.

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 leading sentence states the action immediately and each subsequent line maps to a parameter or a concrete output behavior, so nearly every sentence earns its place. The formatting is a bit dense and run-on in the trailing paragraph, but nothing is 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?

For a six-parameter read tool with an output schema, this covers the decision-relevant surface: how to address a range, what mode returns, output format, and the truncation ceiling. Since an output schema exists, the description needn't explain return shape, yet the extra notes on dates, number formats, and merged cells are exactly the surprises an agent would otherwise misreport.

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 documents four of six parameters in real depth — A1-style range variants including whole rows/columns, the three mode semantics with cached-value caveats, the three format values (which the schema does not even enumerate), and the max_cells cap with its overflow behavior. Only path and sheet are left unexplained, which are largely self-evident but leave questions like relative-vs-absolute paths and sheet-name matching unanswered.

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?

"Read cells from one sheet" gives a specific verb plus resource, and the parameter block makes the read-only, range-scoped nature unambiguous against siblings like set_cells or append_rows. It stops short of explicitly contrasting itself with workbook_overview, find_cells, or describe_columns, which would have made selection trivial.

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 reader can infer you use this to fetch cell contents once you know the sheet, and "Omit for the whole used range" guides in-tool behavior. There is no explicit guidance on when to reach for this versus find_cells (to locate data) or workbook_overview (to orient), which are the most likely confusion points.

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 and does well: it discloses the cascade scope, the string-literal exclusion (a real correctness trap), the dry-run default, and that overwrite/allow_loss can cause loss. Gaps remain on reversibility, whether the input file is modified in place vs written to 'output', and behavior for references in other workbooks.

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 dense sentences, front-loaded with the operation and its cascade scope, then the critical dry-run default, then parameter pointers. Every clause carries information; nothing is 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 7-parameter mutation tool with no annotations, the description conveys scope, defaults, and risk-relevant flags, and an output schema exists so return values need not be explained. The main shortfall is relying on cross-references to sibling tools for three parameters instead of spelling out their effect in this 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 description coverage is 0% across 7 parameters, so the description must compensate. It adds meaning for dry_run, new_name (validated like add_sheet), and bundles output/overwrite/allow_loss via reference to set_cells, but leaves 'path' and 'sheet' entirely unexplained and defers three parameters to another tool's documentation rather than describing them here.

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 ('Rename a sheet') plus the non-obvious scope of the operation: cascading updates to formulas, defined names, validation/conditional-format formulas, and internal hyperlinks. This is clearly distinguishable from siblings like add_sheet or set_cells, which do not touch sheet names.

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 states the default workflow ('DRY RUN BY DEFAULT: lists each formula that would change'), which tells the agent to preview before committing. It also routes the agent to sibling semantics ('validated like add_sheet', 'work as in set_cells'). It stops short of naming when to prefer this over manual edit-then-rename approaches, but the operation is largely unique in the toolset.

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 supplied, the description carries the full behavioral burden and does so thoroughly: default dry run, writes go to a new '.edited.xlsx' file, overwrite and allow_loss gating, refusal on merged-cell interiors, array formulas, missing-sheet references and lossy-workbook features, plus the loss of cached formula results on save. These are exactly the side-effect and safety facts an agent needs before invoking a mutation.

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 two highest-value facts (single-cell scope, dry-run-by-default) before the coercion detail, and the bulleted coercion list is easy to scan. It is dense but nearly every sentence carries a distinct rule; a minor amount of the quoting guidance could be tightened.

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 7-parameter mutation tool with no annotations, the description covers write targets, side effects, refusal conditions, output file behavior and value typing, and an output schema exists so return values need no further explanation. Nothing an agent needs in order to call this correctly is missing.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate, and it does: it specifies the shape of each change object, the optional per-change "sheet" override, and detailed value-coercion rules for formula strings, quoted literals, numbers, booleans, nulls and ISO dates. It also clarifies output, overwrite, dry_run and allow_loss semantics, leaving only the obvious path/sheet names implicit.

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 concrete verb and resource ("Write single cells") and immediately bounds the scope with "changing nothing else", which implicitly contrasts with bulk-append siblings like append_rows. An agent can tell what this does and what it does not touch without opening the schema.

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

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

Gives explicit procedural guidance: the tool is a dry run by default and the agent must repeat with dry_run=false to actually save, and it explains when to use output= vs. overwrite=true with output equal to path. It does not explicitly name sibling alternatives (e.g. append_rows for row insertion), which keeps it short of a 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?

With no annotations at all, the description carries the full burden and does well: it declares the operation is non-mutating, discloses a pre-flight safety scan (zip bombs, XML entity attacks), and warns that saving would lose features like charts, images, pivot tables and macros. It does not mention cost or latency on large workbooks, which is the main remaining behavioral gap for an agent deciding whether to call it.

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 'Start here' and the core action, followed by a dense but purposeful enumeration where each clause is distinct information. The single run-on sentence listing a dozen features is heavy to parse and the trailing '...' is imprecise, but no sentence is 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 one-parameter inspection tool, the description covers action, safety profile, return content, and path resolution. An output schema exists, so the informal enumeration of returned fields is a bonus for tool selection rather than a missing spec, and nothing an agent needs in order to call this correctly is absent.

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

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

Schema coverage is 0% and the single param is undocumented in the schema, but the description compensates: it restricts the accepted formats to .xlsx or .xlsm, explains that the path is resolved relative to the server's --dir, and that absolute paths must remain inside that directory. This is genuine semantic value, only slightly short of complete since it does not cover error behavior for a nonexistent path.

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 ('Summarise a workbook') and then enumerates precisely what the summary contains: sheet visibility states, used ranges, tables, named ranges, merged cells, validations, conditional formats, comments, formula counts, uncached formulas, error cells, and lossy-save features. This is far more distinguishing than sibling names like read_range or describe_columns, which it clearly is not.

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?

'Start here' is an explicit entry-point instruction that routes the agent before any other tool, and 'without changing it' signals the read-only counterpart to set_cells/append_rows. It stops short of naming a specific sibling to prefer for follow-up work or stating when this tool is overkill versus read_range, so it is strong but not fully explicit about alternatives.

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 present, the description carries the full behavioral burden and does well: it discloses that formula cells lacking a cached value are written empty and tallied in a warning, that dates are ISO 8601, that unrepresentable characters under the chosen encoding are an error rather than silently transcoded, and that overwriting is refused by default. It stops short of saying whether missing directories or missing extensions on the output path are created or appended.

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 lead sentence front-loads purpose and formats, and the indented mode block is efficient. The phrase 'encoding/delimiter as in csv_to_xlsx' outsources semantics to a sibling's description, which is terse but slightly fragile for an agent that has not read that 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 no explanation, and the mutation/overwrite risk is covered. However, with eight parameters at 0% schema coverage and no annotations, leaving path and output entirely undescribed makes the definition incomplete for a function that writes a new file to disk.

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% and no parameter has a description, so the description must supply meaning. It does so for mode, encoding, delimiter, overwrite, and the sheet/range scope, but path and output remain undocumented in both places—for a write tool the output path semantics (extension handling, directory creation, path relative to what) are exactly what an agent needs.

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 and resource, 'Export one sheet (or a range) to CSV/TSV', and enumerates the accepted output formats, so an agent can tell immediately what it produces. The direction of the operation (xlsx in, delimited text out) contrasts cleanly with the inverse sibling csv_to_xlsx.

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 explains how to choose between mode='values' and mode='formulas', and warns that an existing output blocks the call unless overwrite=true. It gives no guidance on when to prefer this tool over read_range or describe_columns for inspecting a sheet, so tool selection versus siblings is only implied by the name.

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