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

Annotations already establish this is a safe read (readOnlyHint=true) over a closed corpus (openWorldHint=false), so the bar is lower. Beyond that the description adds real behavior: results come back 'best first' (ranked) and enumerate the returned fields including the credibility label when a check was performed. It omits pagination behavior and the default result count (only in the schema), so it stops short of a 5.

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?

Front-loaded with the corpus definition, then the return shape — a sensible order with no filler sentences. It is dense, with one long embedded clause about the notes, but every clause carries information rather than restating the name or title.

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 usefully enumerates the returned fields (headline, summary, type, tags, desk, source, address, date, credibility label), which is exactly what the agent needs to judge relevance. The remaining gap is that query syntax is delegated to a sibling rather than described, so a reader must consult search_news for the format.

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% and all four parameters (desk, limit, query, since) are documented in the schema with enums, defaults, and formats. The description's only parameter-relevant contribution is deferring query syntax to search_news, which adds no concrete syntax detail. Baseline 3 applies when the schema carries the load.

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?

States a specific verb and resource ('Search the Book: every note the Observatory's desks have written since late September 2026') plus the scope that defines the corpus, including it being unpublished notes that never reached an issue. That corpus definition implicitly separates it from the published-issue tools (get_issue, latest_issues, search_news), so an agent can tell which set of content this searches without opening the schema.

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 only routing hint is 'Same query syntax as search_news,' which signals the two tools are parallel corpora but never states when to pick this one over search_news or get_issue. Usage is left to inference from the corpus description rather than an explicit when-to-use rule or exclusion.

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