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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description nevertheless adds a real behavioral trait — 'deterministic' — signaling a pure, side-effect-free, reproducible computation, and it enumerates exactly what the call yields despite there being no output schema. It says nothing about behavior on input over the 100 KB limit or error cases.

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?

A single front-loaded sentence with no filler; every clause names a distinct returned artifact. Nothing could be removed without losing 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?

For a one-parameter, read-only computation tool with annotations and no output schema, the description sufficiently covers what comes back (statistics, tokens, reading time, SHA-256 hash). It is slightly thin on what 'text statistics' concretely includes and on behavior for oversized input.

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?

There is a single parameter with 100% schema description coverage, and the schema already documents it as the text to analyze with a 100 KB cap. The description adds no syntax, encoding, or formatting guidance for the input, so the baseline 3 applies.

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') and enumerates the concrete resource it produces: text statistics, token estimates, reading time, and a content hash. It is clear what the tool computes, but it does not differentiate itself from the overlapping sibling hash_generate, which also produces hashes.

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 only lists outputs; it never says when to reach for this tool rather than hash_generate or json_extract, nor does it state prerequisites or exclusions. An agent must infer the use case purely from the output list.

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