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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The phrase 'one line at a time' adds a genuine behavioral clue beyond the annotations, namely that the tool paginates a reading into discrete cards. It does not, however, disclose how many cards exist, what happens for out-of-range 'n', or how 'for voice' affects the output.

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 first clause merely restates the title, and the second sentence is a broad product blurb enumerating unrelated features (plans, search, original text lookup, whole books from the Library) that do nothing to help invoke get_card. Only the fragment 'one line at a time' earns its place.

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?

For a zero-required-parameter, read-only tool with full schema coverage and no output schema, the description is minimally adequate: annotations carry the safety profile and the schema carries the inputs. It still leaves the core concept of a 'card' and its relationship to a reading and to sibling get_reading unexplained, which is the main gap.

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%, so each parameter is fully documented in the schema (n, date as YYYY-MM-DD defaulting to today UTC, reading id from list_readings). The description's 'one line at a time' loosely corresponds to 'n' but adds no format or constraint detail beyond the schema, so the baseline 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 title/description 'Today's reading one line at a time, for voice' hints at retrieving a single line from today's reading, and the parameter 'n' (which card) supports that reading. However, it never states plainly that it returns one card/chunk of a reading, and it gives no signal to distinguish it from sibling get_reading, which plausibly returns the whole reading. The second sentence is a server-wide catalog blurb ('Talmud: daily readings, plans, search and original text lookup; whole books from the Library...') rather than a description of this tool.

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?

Nothing says when to use get_card instead of get_reading, get_today, or search_readings, even though those siblings clearly overlap on the same daily-reading domain. There are no stated prerequisites, ordering, or exclusions – the agent must infer the intended call site from the name alone.

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