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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds little behavioral context beyond the transform nature of the tool; it says nothing about determinism of output formatting or handling of malformed paper objects.

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 sentence, front-loaded with the action and followed by the accepted output formats. No wasted words.

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?

An output schema exists, so return values need no explanation, and the tool is a simple deterministic transform. The description is nearly complete, only omitting the bibtex default and any hint about the expected paper object shape.

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 description must carry the load, and it does: it enumerates the three valid format values (bibtex, ris, csl-json), which the schema does not provide as an enum, and explains where the papers array comes from. It does not mention the default of bibtex, but the key semantics are supplied.

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 (format/export) and resource (papers) plus the concrete output formats, so the agent knows exactly what this produces. It does not explicitly contrast itself with siblings like verify_citation, but the transform-vs-retrieve distinction is obvious from the phrasing.

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?

"as returned by the search tools" implies the input should come from prior search results, which is useful context. However, there is no explicit when-to-use or when-not-to-use guidance, and no named alternative for citation-related tasks.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds only the data source (OpenAlex), which is mildly useful, but says nothing about how relatedness is computed, determinism of results, or result volume.

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?

It is a single short sentence fragment with no padding, which is good. However it is under-specified rather than concise, and the fragment form gives the agent no structured entry point.

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?

An output schema exists, so return values need not be explained. But for a tool with a required, undocumented identifier parameter and three adjacent sibling retrieval tools, the definition omits the input format and routing guidance an agent needs to call it correctly.

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 description carries the full burden for the identifier and limit parameters. It never states what identifier format is accepted (DOI, OpenAlex ID, PMID?) nor what limit controls — a real risk for the single required parameter.

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 phrase names a specific resource ('Papers OpenAlex considers related to this one') and, by resting on relatedness rather than citations, implicitly separates itself from get_citing_papers and get_referenced_papers. It stops short of a verb-led statement of what the tool does, so it is clear but not maximally explicit.

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?

There is no when-to-use guidance and no mention of alternative tools, even though get_citing_papers, get_referenced_papers, and search_literature all occupy nearby territory. The agent must infer that 'related' means OpenAlex's similarity signal rather than citation links.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond that: the result ordering (most cited first) and the provenance source (OpenAlex). It does not mention pagination, auth requirements, or rate 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?

A single tight sentence with zero waste, front-loading the resource and appending ordering and source as compact parenthetical detail. Nothing to trim.

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?

An output schema exists, so return values needn't be described, but the tool has 0% schema coverage on two parameters and no usage guidance for distinguishing it from get_referenced_papers. The identifier format gap is the most consequential omission for correct invocation.

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 description must compensate and does not. The critical 'identifier' parameter type (DOI, OpenAlex ID, PMID, etc.) is never specified, and 'limit' is untouched — the mention of OpenAlex is the only weak hint about acceptable identifiers.

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 resource and direction: papers that cite this one. The name plus description clearly contrast with the sibling get_referenced_papers, though the description itself doesn't explicitly name the inverse relationship. An agent can tell what it returns 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?

No when-to-use or when-not guidance, and no alternative is named despite get_referenced_papers being the obvious sibling for the opposite direction. Only the ordering ("most cited first") and source (OpenAlex) are given, which is not usage guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds meaningful behavior: the failure mode (`available: false` plus an open-access link) and a prompt-injection warning about third-party content. It omits truncation behavior around max_chars and any rate-limit or coverage caveats.

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 primary behavior followed by the fallback and the safety note. No filler, though the layout with the fallback as a separate paragraph is slightly fragmented.

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?

An output schema exists, so return-value explanation isn't strictly required (and the description helpfully adds the failure shape anyway). The major completeness gap is identifier format guidance, which an agent needs in order to call this correctly given 0% schema coverage.

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 description must carry parameter meaning, but it never explains what `identifier` accepts (PMID? PMCID? DOI?) — a critical ambiguity for a PMC-specific tool. `max_chars` is likewise unmentioned, leaving both parameters undocumented.

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 ('Open-access full text as plain text') plus the scope condition ('when PubMed Central has it'). It clearly differs from metadata-oriented siblings like get_paper_details, though it does not name any sibling explicitly.

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: an agent can infer this is for when full text (not just metadata) is needed. There is no explicit guidance on when to prefer it over get_paper_details or search_literature, and no stated prerequisites for the identifier.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety and retry profile is fully covered. The description adds the accepted identifier namespaces (which is really parameter help) but nothing else behavioral, such as error behavior for an unresolvable id or the record's scope.

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, with the scope ('one paper') front-loaded ahead of the accepted identifier forms. Every clause 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?

An output schema exists, so the description need not explain the returned record, and the one required parameter is disambiguated. The only missing piece for an agent choosing among nine siblings is explicit routing guidance.

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 0% and the single parameter 'identifier' is undocumented in the schema, so the description carries the full burden — and it does: it enumerates DOI, PMID, PMCID, arXiv id and OpenAlex id as accepted forms. It stops short of giving formatting examples or namespace prefixes (e.g. 'doi:10.…'), so it is strong but not exhaustive.

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+resource: retrieves the 'full record for one paper'. This clearly separates it from the search_* siblings and from get_fulltext (full record vs full text), though it does not explicitly name any sibling to route against.

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 implied rather than stated: the tool is for looking up a single known paper. It never says when to prefer it over get_fulltext or verify_citation, nor what to do if you lack an identifier (use search_literature). With nine siblings, a routing hint would have been cheap and valuable.

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

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

Annotations already declare this a read-only, idempotent, non-destructive, open-world operation, so safety is covered. The description adds genuine behavioral facts beyond them: the data source (OpenAlex) and a hard ceiling of 100 results, which tells the agent the result set is bounded.

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 sentence fragment with zero filler, and the citation direction is front-loaded before the source/limit qualifiers. Slightly telegraphic, but nothing is wasted.

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?

An output schema exists, so return values need not be explained, and the 100-result cap plus source give useful framing. However, for a tool whose only required input is an identifier, the silent schema and the absence of any identifier-format guidance leave a real gap.

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% for both parameters. The description contributes only 'up to 100', which loosely bounds limit, while the required identifier parameter is never defined (DOI? OpenAlex ID? PMID?). With a required identifier and no schema text, the description fails to compensate.

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 direction of traversal ('papers this one cites') against a specific resource ('its reference list'), which cleanly separates it from the sibling get_citing_papers. An agent can pick correctly 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?

Usage is implied by the citation direction, but the description never states when to use this versus get_citing_papers, find_similar_papers, or get_paper_details, nor any prerequisite about the input paper. Adequate but the routing must be inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that – no note on rate limits, coverage scope, or result freshness – so it contributes little beyond the structured annotations.

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 short sentences with the core purpose front-loaded and no filler. Efficient, though the brevity is partly the cause of the missing parameter guidance.

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?

An output schema exists, so return values need not be described, and the tool is conceptually simple. Still, for a 0%-coverage schema the description should explain what `query` matches against and how `limit` interacts with results, which it omits.

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 description must compensate, and it only partially does: it gives examples for `status` (RECRUITING, COMPLETED, TERMINATED) but says nothing about what `query` accepts (keyword, condition, drug?) or how `limit` behaves. Two of three parameters remain unspecified.

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 gives a specific verb and resource ('Search ClinicalTrials.gov'), and naming the source registry implicitly separates it from sibling search tools like search_pubmed and search_literature. It does not explicitly state how it differs from those siblings, so it falls short of 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?

There is no guidance on when to choose this tool over search_pubmed, search_literature, or the other siblings. The only usage-adjacent content is example status values, which is parameter detail rather than when-to-use guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description adds the non-obvious mechanics: de-duplication by DOI/title and ranking by cross-source agreement. It also discloses the side effect that `country` silently restricts to OpenAlex only, which a caller could not infer from the schema. No rate limits or latency expectations are given, keeping 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?

Front-loaded with the headline capability, then dedup/ranking behavior, then per-parameter constraints; every line carries information and there is no filler. Minor cost: the parameter lines with inline backticks read as terse fragments rather than prose.

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?

An output schema exists, so return values need no explanation, and the federated-search mechanics are well covered. The remaining gap is the four undocumented parameters against a 0%-coverage schema, which for a 7-parameter tool leaves an agent guessing on date-range and open-access semantics.

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?

With schema description coverage at 0%, the description must carry all parameter meaning, and it documents only three of seven: the five valid `sources` values, `country` as two letters plus its OpenAlex-only effect, and `limit`'s 1-50 range. `query`, `year_from`, `year_to`, and `open_access_only` are left entirely to their self-explanatory names, so compensation is partial.

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?

Opens with a specific verb (Search) and enumerates the exact resource set (OpenAlex, Crossref, Europe PMC, PubMed, arXiv at once), which immediately separates it from the single-source sibling search_pubmed. An agent can pick this for a broad federated query without opening any 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?

Gives clear operating context: `sources` narrows the federation, `country` implicitly switches to OpenAlex-only, and `limit` is bounded 1-50. It never states when to prefer a sibling like search_pubmed or search_clinical_trials, so it stops short of the explicit alternatives/exclusions a 5 requires.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds that abstracts are included, which is useful scope information beyond annotations, but does not mention pagination, result format, or rate limits. An output schema exists, so return values need not be explained.

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 short sentences, front-loaded with the verb and resource, with zero wasted words. Appropriately sized for a simple search tool, though it could have used that space to document the year/limit parameters.

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?

Annotations cover the safety profile and an output schema exists, so the remaining burden is lighter. However, with 0% schema coverage on four parameters (limit, year_from, year_to undocumented), the description leaves clear gaps for an agent trying to call the tool correctly.

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 description must compensate but largely does not — it explains the query syntax ('[MeSH Terms]') but says nothing about limit, year_from, or year_to. The syntax hint is the only real parameter value added, leaving three parameters undocumented in both schema and description.

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+resource ('Search PubMed') and scope ('alone, with abstracts'). Implies differentiation from siblings (search_literature, search_clinical_trials) via the word 'alone', but never names an alternative, so sibling routing is only hinted at rather than explicit.

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 'PubMed alone' implies this is the PubMed-specific search versus a broader literature search and sibling tools like search_literature or search_clinical_trials, but no explicit when/when-not or named alternative is given. Usage is only weakly implied.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: the possible result states and the warning that NOT_FOUND is not proof of fabrication, which materially changes how an agent should report results.

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 core action, then the result vocabulary, then the critical caveat. No filler or repetition.

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?

An output schema exists and annotations are rich, so the return-value gap is partly covered, and the description usefully summarizes the state vocabulary. However, with four undescribed optional parameters and no guidance on input matching semantics, the definition is incomplete for correct invocation.

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% and all four parameters (doi, year, title, authors) are undocumented and optional. The description says nothing about which combination to supply, the matching/precedence logic, or that at least one identifier is presumably needed, so it fails to compensate for the coverage gap.

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 ('Check that a citation is real and matches its record') and no sibling tool in the set covers verification, so the agent can distinguish it immediately. Enumerating the four outcome states further pins down what the tool actually does.

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 implied by the purpose (verifying bibliographic references) but the description never states when to reach for this versus get_paper_details or search_literature, nor any prerequisites. It does add interpretive guidance on the NOT_FOUND result, which is useful but not a when-to-use rule.

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