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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that content is read 'a passage at a time' / 'line by line', which is a modest behavioral detail about granularity, but nothing about rate limits, auth, or return shape. Appropriate for the lowered bar set by 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?

The title is restated verbatim twice ('Scroll the Lore. One reading or plan, line by line') before any new information arrives, and the final sentence is a comma-spliced list of corpus names that does not help an agent call the tool. Structure is back-loaded with marketing rather than front-loaded with operational content.

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 no output schema, the description should orient the agent on what comes back; 'line by line' gives a partial hint but the rest is corpus trivia. For a one-parameter, annotation-covered read tool this is minimally adequate, but it spends its budget on titles and book names rather than the retrieval behavior.

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 100% for the single 'id' parameter, and the schema already explains that the id comes from list_readings or may be a plan name such as 'japji'. The description adds no syntax or format guidance beyond that, so the baseline of 3 applies.

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 first two sentences convey that this retrieves a single reading or plan ('One reading or plan, line by line'), which roughly matches the name. However, the trailing sentence collapses the whole product surface into the description ('daily readings explained line by line, plans, search, and the whole Theogony...'), so it reads like a corpus blurb rather than this tool's specific function and even name-checks 'search', which is the job of the sibling lore_search_readings. Sibling differentiation is weak.

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?

There is no explicit when-to-use guidance or comparison to alternatives like lore_get_today, lore_get_card or lore_read_book. The only routing hint ('id from list_readings') lives in the schema, not the description. Usage must be inferred entirely.

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