runeberg_read_page

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a read operation returning cleaned/OCR text and that the page parameter only applies when a slug is used. However, it does not state what happens when a slug is provided without a page, how invalid inputs are handled, or whether any normalization occurs.

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 compact and front-loaded: the purpose appears in the first sentence, followed by a clean Args section. Every sentence adds necessary information and 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 an output schema present, return-value details do not need to be in the description. The two parameters are thoroughly documented and the read behavior is clear. The main gaps are the lack of explicit sibling differentiation and the unspecified default behavior when page is omitted, but overall this is nearly complete for a simple read tool.

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%, so the description is the only documentation for the parameters. It fully explains url_or_slug with a concrete URL and slug example, and page with both string and numeric examples, while also clarifying the conditional relationship between the two parameters.

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 clearly states the action ('Read') and the resource ('cleaned, transcribed/OCR text of a specific book page from Project Runeberg'). This distinguishes it from the sibling tools runeberg_search and runeberg_get_work_info, which serve clearly different purposes.

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 makes the use case clear: retrieve page text when you have a full page URL or a work slug plus optional page number. It does not explicitly mention alternatives or exclusions, but the context is strong enough for an agent to infer when this tool applies.

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