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 disclose several non-obvious traits: the 20 MB size ceiling, the exact output shape (Markdown plus character, word and token counts), and a paid x402 price of $0.005 USDC on Base. It does not cover failure modes (unsupported format, non-public URL, >20 MB behavior), which keeps it short of a 5.

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

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

Two sentences, zero filler, and the core purpose is front-loaded ahead of constraints and pricing. Every clause (formats, size cap, return fields, cost) carries information an agent needs before calling.

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

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

Since there is no output schema, the description usefully spells out what comes back (Markdown plus counts), which is exactly the gap it needs to fill. The one-parameter schema is fully documented, so the only real omission is error/edge-case behavior for unsupported or oversized documents.

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?

Placeholder — replaced below by the correct value.

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

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

States a specific verb+resource ('Convert a document at a URL to Markdown') and immediately scopes it to an LLM use case, then enumerates exactly which document types qualify. An agent can distinguish this from the nearby web_extract or ai_* siblings because the description is document-format-scoped rather than page- or prompt-scoped.

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 supported-format list (PDF, DOCX, XLSX/XLS, ODT/ODS, CSV, XML) and the 20 MB cap implicitly tell the agent when the tool applies, and the format list also implicitly excludes HTML pages. However, no alternative is ever named, so the agent gets no explicit routing instruction against siblings like web_extract.

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