eyestill_fetch_textUsed 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 |
Changes observed during successful MCP inspections.
Input 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"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.
Add one secure layer between your agents and this server.