Speed-read web pages, public-domain books (Project Gutenberg) and Claude's answers in the chat, one word at a time on a 3D drum, with speed and position controls. The assistant knows your reading position. No account needed.
Scored across 2 tools
read_with_eyestill already accepts url/book/text and performs readable-text extraction, so eyestill_fetch_text overlaps with it substantially; the distinction (fetch = paginate the next part of an already-open text, read = open the view) is only implied by the descriptions. An agent could plausibly pick either for loading a URL, and the boundary is not stated in fetch's own description.
eyestill_fetch_text is product-prefixed verb_noun while read_with_eyestill is a verb_with_product pattern; both are snake_case and readable, but they follow different conventions and the two names don't signal the fetch/open split clearly.
Two tools for a narrowly scoped speed-reading server is defensible, but it is on the thin end — the second tool largely subsumes the first, making the pair feel like one capability split awkwardly rather than two earned tools.
The core lifecycle (load text, open view, paginate long texts, start position control) is covered, and the view handles playback and position reporting as context. Minor gaps remain: no explicit way to close or reload the view, and pagination is only reachable via the fetch tool.
Used by the EyeStill reader view to load the text of a page or book, or its next part.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Address of the public web page or .txt file to load | |
| book | No | Title and/or author of the public-domain book to load | |
| offset | No | Word number to continue from; the next part of the text starts here |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, open-world behavior and rule out destruction. The description adds that it loads text and supports continuation via the next part, but it does not mention error behavior, rate limits, authentication, or what happens with missing inputs.
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 words. It communicates the reader-view context and the load/continue action efficiently.
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 annotations plus schema cover safety and parameter meanings. Still, the description omits important invocation semantics: whether url and book are alternatives, whether at least one is required despite zero required parameters, and how this tool relates to read_with_eyestill.
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%, and the parameter definitions already explain url, book, and offset in detail. The description mirrors those meanings by mentioning page/book and next part, but it does not add constraints such as whether url and book are mutually exclusive or what to do if neither is provided.
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 action and resource: loading text for a page or book, including the next part. It is clear what the tool does, but it does not distinguish itself from the sibling tool read_with_eyestill.
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 a contextual cue by saying this is used by the EyeStill reader view and can load a page, book, or next part. However, it does not say when to use this instead of read_with_eyestill, nor does it give exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens text in EyeStill, a speed reader shown in the chat as an interactive view. The view shows one word at a time at a single point of focus (RSVP) on a 3D drum, with play, pause, speed (100 to 1,000 words per minute) and position controls. Takes exactly one of: url (a public web article, page or plain-text file; the server extracts its readable text), book (title and/or author of a public-domain book, fetched from Project Gutenberg), or text (any text, such as text from the conversation or an answer composed for reading in the view). Text is displayed while it streams in, so reading can start before it is complete. The text is shown only in the view; the result reports its title and word count. Plain prose reads best: Markdown, tables and code appear as raw text. A text can be opened at a word number (start_word, as reported by the reader's context) or at the first place a phrase appears, such as a chapter heading (start_at). While the user reads, the view shares the current position and passage as context.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Address of a public web page, article or .txt file | |
| wpm | No | Starting speed in words per minute; 300 if omitted | |
| book | No | Title and/or author of a public-domain book, e.g. "Moby Dick Melville" | |
| text | No | Text to read, e.g. from the conversation or an answer written for the reader; shown as it streams in | |
| title | No | Optional title shown above the reader (for text) | |
| start_at | No | A phrase to start reading from, e.g. a chapter heading like "CHAPTER 30" | |
| start_word | No | Word number to start reading from, e.g. where the reader stopped |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
eyestill_fetch_text3 fields changedInput schema / properties / book / descriptionAdded value: +"Title and/or author of the public-domain book to load"Input schema / properties / offset / descriptionAdded value: +"Word number to continue from; the next part of the text starts here"Input schema / properties / url / descriptionAdded value: +"Address of the public web page or .txt file to load"eyestill_fetch_textread_with_eyestill
Add one secure layer between your agents and this server.