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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial context: deterministic and offline execution, a 200 KB input limit, the returned fields (Unicode offsets, character/token estimates, totals), and pricing via x402 on Solana. This is exactly the kind of behavioral information an agent needs before invoking a paid text-processing endpoint.

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 dense but front-loaded: purpose and strategies first, then return values, execution properties, limits, and pricing. The first sentence is long and semicolon-heavy, but every clause carries useful information and none is gratuitous.

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?

There is no output schema, so the description carries the burden of explaining returns, and it does: chunks include Unicode start/end offsets, character and token estimates, plus totals. Combined with strategy, sizing, overlap, limit, and pricing details, an agent has enough information to invoke the tool 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 coverage is 100%, so the baseline is 3; however, the description adds meaning beyond the schema by specifying the recursive fallback order (paragraph > line > sentence > clause > word), explaining markdown heading-path retention and code-fence respect, and noting that include_text=false returns offsets only. These details help the agent choose parameter values rather than merely restating 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?

The description states a specific verb and resource (split text into retrieval-ready chunks) and enumerates the exact strategies: recursive, markdown-aware, sentence, and fixed windows. This is far more specific than the title or name alone and clearly distinguishes it from sibling text tools such as text_stats, text_diff, and html_to_markdown.

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 clear context for when this tool is appropriate: preparing RAG and embedding inputs, with sizing in tokens or characters and optional overlap. It does not explicitly name when not to use it or point to alternative tools (e.g., readability_extract or html_to_markdown for preprocessing), so it falls short of full alternative routing.

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