EyeStill Speed Reader

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that this is reader-view loading and supports a next part, but it does not cover auth, rate limits, or return format; with annotations present, this is adequate but not rich.

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 front-loaded sentence with no wasted clauses. Its brevity is structurally efficient, though it contributes to under-specification elsewhere.

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 an openWorld text-fetch tool with three undocumented optional parameters and no output schema, the description is too thin. It never explains when to use url versus book, how pagination works, or what the returned text looks like, leaving the agent to guess.

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 0% for three optional parameters (url, book, offset), and the description only loosely implies page/book and next-part concepts. It never explains what url versus book do, how offset is interpreted, or what happens when no parameter is supplied, so it does not compensate for the missing schema documentation.

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 ('load the text') and resource ('page or book, or its next part') and names the consuming view. It does not clearly distinguish this tool from the sibling read_with_eyestill, so it stops short of full sibling differentiation.

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 phrase 'Used by the EyeStill reader view' gives an implied calling context, but there is no explicit when-to-use/when-not-to-use guidance and no comparison to read_with_eyestill. Usage is inferable but not spelled out.

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

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

Annotations only declare read-only/idempotent/open-world; the description adds substantial behavior beyond that: streaming display so reading can start before the text is complete, that the text appears only in the view while the result reports title and word count, that the view shares current position and passage as context, and that Markdown/tables/code render as raw text. These are non-obvious operational traits an agent could not infer from the 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 action and the mode-selection rule before the finer details, and nearly every sentence carries information. It is on the long side for a single tool and repeats the view/streaming idea in a couple of places ('shown as it streams in' appears in both description and schema), but there is no filler.

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 7 optional parameters, no output schema, and a non-trivial rendering surface, the description covers what an agent needs: mode selection, defaults, rendering limits, streaming behavior, and what the result reports. Nothing material about invoking the tool correctly is left unstated.

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 already 100%, so the baseline is 3, but the description adds real meaning: url must be public and the server extracts readable text, book is resolved against Project Gutenberg, text streams into the view, wpm spans 100–1,000, and start_at is for a phrase like a chapter heading. This goes well past 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?

Names a concrete verb and resource ('Opens text in EyeStill, a speed reader shown in the chat as an interactive view') and then specifies the mechanism (RSVP, one word at a time on a 3D drum) so the agent knows exactly what effect the call has. The 'takes exactly one of url / book / text' clause makes the tool's input contract distinctive rather than a generic fetch.

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?

Explicitly enumerates the three mutually exclusive modes and when each applies: url for a public web article/page/plain-text file, book for a public-domain title fetched from Project Gutenberg, and text for conversation content or an answer composed for reading. It also gives guidance on choosing start_word ('as reported by the reader's context') versus start_at (a chapter heading), which is exactly the kind of when-to-use routing an agent needs.

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