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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the description's job is to add context — which it does by disclosing the payload components: index entry, source file, notes, terms evidence, and the install command. It does not cover failure behavior for a bad id, which keeps it 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?

One front-loaded sentence with an efficient colon list; every clause names concrete returned artifacts and nothing is repeated from the title or annotations.

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 return contents, which is the main completeness burden for a single-item read tool. It stops short of noting behavior on a missing or invalid recipe id, the one gap an agent might hit.

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 the single parameter is documented as 'Recipe id from search_recipes'; the description adds no format, casing, or lookup-failure detail beyond that. Baseline 3 is appropriate where the schema carries the parameter semantics.

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 (Read) and resource (one registry recipe) and scopes it with 'one', which implicitly distinguishes it from the sibling search_recipes that returns many. The colon list enumerates exactly what is retrieved, so an agent knows precisely what it gets.

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?

Usage is only implied: the schema note 'Recipe id from search_recipes' hints that this follows a search, but the description itself never says when to use this versus search_recipes or search_records, nor what happens with an unknown id. An agent can infer the workflow but is given no explicit routing.

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