get_literature_records

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

With no annotations at all, the description carries the full burden, and it does disclose the key default behavior: cached abstract and references are returned from the session, and refresh is an opt-in escalation. It omits the cost dimension of refresh (extra provider calls/latency) and never says what happens when no identifiers are supplied, which matters because zero parameters are required.

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, both front-loaded with the operative fact: the first establishes what the tool does and its main advantage, the second establishes the default versus the refresh exception. Nothing is redundant.

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 7-parameter tool with no annotations and no output schema, the description covers the retrieval model well but leaves gaps: it does not say which parameter takes precedence when recordIds, dois and searchId are combined, nor what a response contains. Adequate but not sufficient for the tool's branching surface.

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 only 14%, but the description compensates for the most consequential parameters by explaining record_id hydration, DOI resolution, the session-cached default, and the refresh escalation path. searchId, includeAbstract, includeReferences and fetchReferences are left to the schema, so coverage is partial rather than complete.

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?

"Hydrate stored search results by record_id, or resolve DOIs, without re-running discovery" names a concrete verb and resource and clearly separates this from the search_* discovery siblings. The one ambiguity is the DOI-resolution path, which overlaps with sibling get_paper_by_doi without being distinguished.

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 usable when-to-use rule for the refresh flag ("only when fresh provider metadata is required") and implies use after a search has already been run. But it never states when to pick this over get_paper_by_doi for DOI lookups, or over get_citations/expand_citation_graph for reference data, so the agent must infer the boundary.

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