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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful scope information: only 'published' overviews are retrievable, and compound overviews may surface medication-interaction evidence. It says nothing about what happens with an unknown slug or a wrong type, so the added behavioral context is real but limited.

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?

Three short sentences, front-loaded with the retrieval action and keying dimensions, followed by content caveat and exclusions. No repetition or filler, though 'Use for general research' is a soft sentence that could be sharper.

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 two-parameter, read-only lookup with an output schema and full annotation coverage, the description covers purpose, prerequisite, content caveats, and misuse boundaries. The main remaining gap is enum semantics for 'type', which the schema leaves undefined and the description only gestures at.

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 schema documents only types and constraints, not meaning. The description names both parameters and hints that 'type' selects the overview kind, but it never explains the seven enum values (e.g. compoundReport vs doseSummaryReport) or the slug format. It partially compensates for the coverage gap without fully closing it.

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 states a specific verb and resource ('Retrieve a published Blossom overview') and the keying dimensions ('by type and slug'), which is far more than a restatement of the name. It also implies the distinction from the search sibling by positioning this as the lookup step after search_overviews. It stops short of distinguishing itself from get_paper or get_latest_research, which is why it is not a 5.

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?

It gives a sequencing prerequisite ('after search_overviews'), a positive use case ('Use for general research'), and explicit exclusions ('Do not use it to assess an individual's medications or dose, or ask for personal health details'). The positive guidance is somewhat generic, but the when-not guidance is unusually concrete and safety-relevant.

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