reading_time

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does state the outputs (word/char counts, minutes, mm:ss) and mentions WPM configurability, which is helpful. However, it does not mention assumptions about input text (e.g., plain text vs markup), edge cases like empty text, or the exact return format, leaving some gaps.

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 a single, well-structured sentence that front-loads the core purpose and immediately follows with the output types. No redundancy or wasted words.

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 tool is simple, and the schema fully documents both parameters. The description explains the return values (word/char counts, minutes, mm:ss) since there is no output schema. Minor gaps remain, such as not indicating whether text length is limited or if HTML tags are stripped, but for a straightforward utility this is 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 100% for both parameters, with text and wpm already described, including wpm's default of 200. The description adds little beyond the schema, only using 'blob of text' and 'default WPM,' which the schema already covers. Baseline 3 is appropriate since the schema handles parameter semantics.

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 uses a specific verb ('Estimate') and resource ('a blob of text'), clearly stating the tool computes reading time with word/char counts, minutes, and mm:ss. This distinguishes it from all sibling tools, which are other utility functions like word_freq or diff_text, so purpose is unambiguous.

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 the tool is for measuring reading time, but it does not explicitly state when to use it versus alternatives or provide exclusions. No guidance on when not to use it or how it compares to other text utilities (e.g., word_freq). Usage is implied rather than explicit.

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