Skip to main content
Glama

Speed-read with EyeStill

read_with_eyestill
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
urlNoAddress of a public web page, article or .txt file
wpmNoStarting speed in words per minute; 300 if omitted
bookNoTitle and/or author of a public-domain book, e.g. "Moby Dick Melville"
textNoText to read, e.g. from the conversation or an answer written for the reader; shown as it streams in
titleNoOptional title shown above the reader (for text)
start_atNoA phrase to start reading from, e.g. a chapter heading like "CHAPTER 30"
start_wordNoWord number to start reading from, e.g. where the reader stopped

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.