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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so safety is covered. The description usefully adds what the returned document actually contains and explicitly bounds its scope against full text/abstracts, but says nothing about error behavior for unknown IDs or result limits.

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?

Two sentences, no filler: the retrieval scope and payload come first, with the exclusion clause as a tight qualifier. Every sentence 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?

With a fully documented single parameter, complete annotations and an output schema, the description carries only what structure cannot: document contents and content boundaries. The one remaining gap is the absence of any cue distinguishing this record fetch from get_citation, which returns a closely related field.

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 coverage is 100% and the single parameter already documents the numeric-string format and that it is not a DOI or URL. The description only echoes 'one search ID', adding no format or derivation detail beyond the schema, 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 description names a specific verb (Retrieve) and resource (public metadata document for one search ID) and enumerates the payload (source links, publication status, citation). It also scopes out what it is not (publisher full text or abstract), which is stronger than a bare restatement, though it never names the sibling tools it differs from (e.g. get_citation).

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 phrase 'for one search ID' makes the intended workflow clear: call after search and pass a single result ID. The negative clause ('not the publisher full text or abstract') tells the agent when not to expect content from this call, but there is no explicit routing to get_citation or search for alternative needs.

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