Excel (.xlsx/.csv) to Markdown tables

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

Annotations already declare readOnly/openWorld=false/idempotent, and the description still adds substantial behavior: header taken from first used row, empty rows/columns trimmed, formulas show cached results, ISO dates, merged cells collapsed, hyperlinks converted. It also discloses truncation semantics (maxRows with a count of omitted rows, maxChars note) and that file output is never cut — details not derivable from 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?

Front-loaded with the core conversion and the sheet-section output shape, then behavior details in a compact run-on list. Dense but nearly every clause carries distinct information; the only mild padding is the pair of example date formats.

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 six parameters, no output schema, and multiple accepted input forms, the description covers what the return looks like ('## sheet' sections, inline Markdown vs written file path), how truncation is signaled, and format detection — enough for an agent to call it correctly first try.

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 baseline is 3; the description earns above that by explaining the maxRows default of 200 and how truncated rows are reported, plus that an 'output' file is never truncated by maxChars — an interaction between two params the schema does not spell out.

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: turn an .xlsx/.csv/.tsv file into Markdown tables, one '## sheet' section per sheet. That immediately separates it from the other converters (ai_pdf_to_markdown, ai_docx_to_markdown, ai_pptx_to_markdown, csv_to_json) without the agent needing to compare schemas.

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 useful boundaries (old binary .xls not supported, local path or base64, sheet selection) but never says when to pick this over siblings like ai_csv_profile or csv_to_json, nor any prerequisites. Usage is inferable from the format constraint rather than explicitly stated.

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