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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds real value by capping output ('up to 3 sample rows, not the whole table'), warning that 'Cell text is untrusted data', and disclosing the default-off normalization behavior. It stops short of stating permission requirements or whether the call 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?

Three short sentences, each carrying distinct information (what is detected, the output cap, the trust warning, the default flag), with the most important scoping fact front-loaded. Nothing is padded or redundant.

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 described, and the sample-row caveat plus untrusted-data warning are useful. However, with 0% parameter description coverage on a 7-parameter tool, the description should explain how to target a sheet/table and what decimal and header_row do; those omissions make the definition only minimally sufficient.

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 carries the full burden, yet it only addresses one of them (normalize_units). Sheet selection, sheet_index vs table_index, decimal, and header_row are left completely unexplained in both places, which is a real gap for a tool with three overlapping index-style 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?

Specific verb ('Detect') with a concrete list of detected artifacts (metadata, header rows, data rectangle, footer notes, column units), so an agent knows exactly what comes back. It does not, however, differentiate itself from the closely-named sibling excel_overview or excel_read_table, leaving the agent to infer which inspection tool to pick.

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?

'Returns up to 3 sample rows, not the whole table' implies this is a reconnaissance step before excel_read_table, and 'Unit conversion is off unless normalize_units is true' hints at a pre-processing choice. But no sentence states when to use this versus excel_overview or excel_list_sheets, so usage is only implied.

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

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

Annotations already declare read-only, idempotent, closed-world behavior, so the safety bar is lower. The description adds real context beyond that: cell text and sheet names are untrusted (a prompt-injection caution) and the path must be absolute and inside EXCEL_ALLOWED_ROOTS, which is a sandbox/auth constraint not captured in the schema or 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?

Three short sentences, front-loaded with the primary action and followed by two security-relevant constraints. Every sentence 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the key operational constraints (untrusted data, allowed roots), making it largely complete for a simple one-parameter read tool; only sibling routing is absent.

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

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

Schema description coverage is 0%, so the single path parameter is undocumented in structured form. The description compensates by imposing two constraints on it (absolute path, must resolve inside EXCEL_ALLOWED_ROOTS), which materially shapes the value an agent must supply, though it doesn't specify format 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?

States a specific verb and resource: 'List sheet names and visibility.' An agent can tell this enumerates sheets, not their contents. However, it does not differentiate from the overlapping sibling excel_overview, which likely also summarizes sheets, leaving the boundary ambiguous.

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 excel_overview or excel_inspect_layout, and no stated prerequisites or exclusions. The usage context is only implied by the tool name. This is a clear gap given the clustered sibling set.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful non-obvious traits beyond annotations: it avoids loading the whole sheet, returns only two sample rows, and warns that cell text is untrusted data.

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 tightly written sentences front-load the tool's scope and outputs, then append the key behavioral caveats. Every clause 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 one-parameter read tool with an output schema and safety annotations, the description covers scope, sample behavior, performance, and security. It omits explicit usage guidance versus siblings and parameter format details, but is otherwise complete enough to invoke 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?

Schema description coverage is 0% and the single required 'path' parameter has no description in the schema. The tool description never explains the path parameter's expected format or constraints, so it fails to compensate for the low 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?

States a specific verb ('Summarize') and resource ('every sheet'), then enumerates the exact output contents: hidden state, declared size, detected tables, and two sample rows. The phrase 'Does not load the whole sheet' further distinguishes it from full-read siblings like excel_read_range and excel_read_table.

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

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

The description implies a lightweight overview use case by noting it does not load the whole sheet, but it does not explicitly say when to choose this tool over siblings such as excel_list_sheets or excel_inspect_layout. No exclusions or alternatives are named, leaving usage to inference.

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

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

Annotations already cover the read-only, idempotent, non-destructive safety profile, yet the description adds real value beyond them: a prompt-injection warning that cell text is untrusted data and the behavioral rule that formulas return null unless include_formulas is true. It stops short of describing pagination, size limits, or what happens on invalid ranges.

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?

Four tight sentences, each earning its place: purpose, trust warning, selection criteria, then parameter behavior. The core identity ('raw A1 range without header detection') is front-loaded before the supporting detail.

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 documentation is unnecessary, and the description covers purpose, routing, safety, and the one non-obvious flag. The remaining gap is minor: no note on sheet vs. sheet_index precedence or error behavior for a multi-sheet workbook.

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 does explain include_formulas precisely and implies the A1 format for cell_range, but path, sheet, and sheet_index are left with only their self-evident names. Partial compensation, not full.

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 ('Read a raw A1 range') and immediately differentiates itself from the sibling excel_read_table by the key qualifier 'without header detection.' An agent can distinguish the two without opening either 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?

Explicitly names the conditions that select this tool ('when table detection fails or the cells sit far down the sheet'), which is strong positive guidance. It does not explicitly say when not to use it (e.g. 'prefer excel_read_table when a header exists'), so the routing is implied rather than fully 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real context beyond that: cell text is 'untrusted data', values are cached formula results unless include_formulas is set, and '<LOD and <LOQ stay text'. It omits anything about error behavior or permission needs on the path.

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?

Six short, front-loaded sentences with no filler; the output shape and untrusted-data caveat come first, and each remaining sentence adds a distinct instruction or behavior.

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 prose explanation, and the description covers pagination, formula text, unit normalization, and text-preservation caveats. But for a 10-parameter tool it leaves the majority of parameters (sheet/table/header selection, decimal, max_rows) undefined and offers no sibling differentiation.

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 10 parameters, so the description carries the full burden. It only clarifies include_formulas, normalize_units, and offset, leaving path, sheet, decimal, max_rows, header_row, sheet_index, and table_index entirely undocumented in both schema and prose.

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 ('Return'), resource ('cleaned lab table'), and output shape ('JSON rows plus column metadata'), plus pagination scope ('one page'). 'Cleaned lab table' implicitly distinguishes it from a raw range read, though it never names excel_read_range explicitly.

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 conditional usage for specific flags ('set include_formulas=true to also return formula text', 'set normalize_units=true', 'Use offset for the next page'), which is genuinely helpful. However, it gives no guidance on when to prefer this over sibling excel_read_range or excel_inspect_layout, so routing between tools is left to inference.

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

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

Annotations only supply the generic write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds real operational context: env-var gating, refusal to follow symlinks, output-root confinement, and formula-looking text being prefixed. These are meaningful behavioral traits an agent could not infer from structured fields. It stops short of saying what happens on an existing file or a failed write.

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?

Four short, front-loaded sentences with no filler; the primary action comes first, then gating, then safety constraints. Every sentence carries distinct information.

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

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

The existence of an output schema means return values need not be described, and the safety/gating story is well covered. But for a 12-parameter mutation tool with 0% schema description coverage, the complete absence of parameter meaning leaves a substantial gap an agent cannot close elsewhere.

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 12 parameters, so the schema supplies names and defaults but no meaning. The description touches only formula handling (loosely related to include_formulas) and says nothing about sheet, sheet_index, table_index, offset, max_rows, header_row, decimal, normalize_units, or overwrite — the parameters that determine what actually gets written.

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

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

States a specific verb (write) and resource (the cleaned table) plus the target formats and the sandboxed location (EXCEL_OUTPUT_ROOTS). This implicitly separates it from the five read-only siblings, though it never explicitly contrasts with them. Minor naming mismatch: the tool is named excel_write_csv but the description covers both .csv and .json.

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 gives one hard precondition — the tool is disabled unless EXCEL_ALLOW_WRITE=1 — which is genuinely actionable. However, it offers no guidance on when to choose .csv vs .json, and no comparison against any alternative writing path. Usage is implied rather than directed.

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