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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the authentication requirement and where to obtain a key, but says nothing about rate limits, failure modes, or result shape (partially mitigated by the existing output schema).

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, purpose front-loaded and the prerequisite second. No filler or repetition of the schema. It is efficient, though not maximally information-dense for its length.

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 search tool with full schema coverage and an output schema, the definition covers purpose and the one non-obvious operational requirement (API key). The missing piece is sibling routing among the many drug/pubmed tools, which is a genuine but not fatal 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?

With 100% schema description coverage on both parameters, the schema already documents the query format ('metformin', 'aspirin') and the max_results range (1-50). The description adds no syntax, matching, or defaulting detail beyond that, so the baseline 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?

States a specific verb (search) and resource (DrugBank) and enumerates what the results cover (targets, enzymes, interactions), which implicitly differentiates it from the openFDA drug siblings. It stops short of explicitly naming which sibling to use for which drug-information need, so it lands at a strong 4 rather than 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?

The description gives a setup prerequisite (DRUGBANK_API_KEY env var with a signup link) but no guidance on when to choose this over openfda_drug_label, openfda_adverse_events, or pubmed_search. The agent must infer the selection context entirely from the tool name.

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?

No annotations are provided, so the description carries the full behavioral burden. It identifies the data source (FAERS) but omits important context such as spontaneous reporting limitations, lack of causality, or any access constraints. For a data retrieval tool with no annotations, this is a significant gap.

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?

The description is a single, well-structured sentence that front-loads the core purpose. Every word earns its place with no redundancy.

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?

The tool has low complexity (2 parameters, no nested objects) and an output schema, so return values need not be explained. The description is nearly complete for a simple query tool, though it could mention when to use this versus sibling FDA or DrugBank tools.

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%, so both parameters (drug_name and limit) are already documented in the schema. The description adds no parameter-specific detail beyond what the schema provides, which is the baseline case for high coverage.

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 clear verb ('Query') and a specific resource ('FDA Adverse Event Reporting System (FAERS) for drug side effects'). It distinguishes the tool from siblings such as openfda_drug_label and openfda_drug_enforcement by focusing on adverse events rather than labels or recalls.

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 description provides no explicit when-to-use guidance, no prerequisites, and no alternatives. It implies the tool is for drug side effects, but an agent must infer that openfda_drug_label or openfda_drug_enforcement are different use cases.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it offers only a one-line purpose statement. It says nothing about authentication, rate limits, or pagination behavior for what is presumably a public API. The 'limit 1-25' cap lives in the schema but no corresponding behavioral caveat is surfaced.

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 front-loaded sentence with no filler, and the parenthetical adds scoping value rather than bloat. It could be slightly richer without harming conciseness.

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 the input schema is fully documented, so return values and parameters need no description coverage. However, for a tool sitting among several OpenFDA/PubMed siblings, the absence of any routing guidance leaves a real gap for correct tool selection.

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%, so the two parameters (limit range and optional drug_name filter) are fully documented in the schema. The description adds no parameter-level detail, which is acceptable given the high coverage, so baseline 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?

States a specific verb ('Query') and resource ('FDA enforcement reports') and parenthetically enumerates the content types (recalls, warnings, market withdrawals). It does not differentiate itself from close siblings like openfda_adverse_events or openfda_drug_label, but the resource is unambiguous on its own.

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, no exclusions, and no reference to the sibling OpenFDA tools. An agent must infer from the resource name alone that this is for recall/enforcement data rather than adverse events or labeling.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Get' weakly implies a read-only lookup, but there is no mention of rate limits, API key requirements, or whether results are paginated or truncated; the section list is the only extra context offered, and an output schema already exists to cover returns.

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 compact sentence with the core action front-loaded and no filler. It is appropriately sized for a one-parameter lookup, though the phrase 'information: indications, warnings, dosage, mechanism' is slightly list-heavy for a description whose return shape is governed by the output schema.

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 simple one-param lookup with a full output schema, the essentials of what is returned and what to pass are covered. What is missing is the guidance an agent actually needs to choose this tool over its FDA and drug siblings, which is the main open 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 100% for the single drug_name parameter, including brand/generic and examples, so the schema does the heavy lifting. The description adds no format, casing, or synonym guidance beyond that, which is the expected baseline 3.

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 ('Get') and resource ('FDA drug label information') and enumerates the content covered (indications, warnings, dosage, mechanism). However, it never differentiates itself from close siblings like openfda_adverse_events, openfda_drug_enforcement, or drugbank_search, so an agent must infer which source fits the query.

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 guidance, no exclusions, and no routing to alternatives. With three other drug-related tools in the sibling list, the description leaves entirely to inference whether label data, adverse events, enforcement reports, or DrugBank should be called.

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?

No annotations are provided, so the description carries the full burden. It only notes the minimum-field requirement and the matcher backend; it discloses nothing about rate limits, matching failures, or how ambiguous matches are resolved.

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 core purpose and containing no filler. 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?

The output schema is present, so return values need not be explained. However, with no annotations and zero per-parameter documentation for a five-param tool, the definition leaves field-format expectations and failure behavior unaddressed.

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% across five parameters, so the description must compensate. It adds the useful combinatorial rule ('at least one', 'more fields = better match') but never explains expected formats for page, year, author, volume, or journal.

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: 'Resolve partial citation to PMID using NCBI's citation matcher.' This is clearly distinct from retrieval siblings like pubmed_fetch or pubmed_search, though it does not name an alternative 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?

'At least one field required. More fields = better match.' gives in-tool guidance about how to supply inputs, but says nothing about when to choose this over pubmed_search or pubmed_fetch, so routing is left to inference.

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?

No annotations are provided, so the description carries the full behavioral burden and does not meet it. It says nothing about pagination, result ordering, rate limits, or what the (existing) output schema returns, leaving only the bare fact that a search occurs.

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 front-loaded sentence with zero filler. It is efficient, though the brevity reflects under-specification rather than disciplined trimming.

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 all parameters are documented, so return values and inputs are covered elsewhere. What is missing is the routing context needed to place this tool among many similar search siblings, which a one-line description does not supply.

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%, so all four parameters (status, condition, max_results, intervention) are already fully documented with defaults and examples. The description adds no syntax, format, or combination guidance beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 ('Search') and resource ('ClinicalTrials.gov ... clinical studies'), which distinguishes it from pubmed_search and europepmc siblings that target different corpora. It stops short of explicitly naming those alternatives, so an agent must infer the registry boundary from the name alone.

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, no mention of when to prefer this over pubmed_search or pubmed_europepmc_search, and no prerequisites. With 17 sibling tools in the same domain, routing is left entirely to inference.

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?

No annotations are provided, so the description carries the full burden; it does disclose the meaningful PMC-indexing constraint, which is real behavioral information. However it says nothing about failure behavior for unmapped IDs, batch rate limits, or whether the PMC restriction applies equally to all three ID types.

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, zero filler, with the core operation stated first and the limiting condition immediately after.

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 parameters are fully documented in the schema. Purpose and the key applicability constraint are both present; only edge-case behavior (unresolvable IDs, rate limits) is missing.

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%, so both parameters (ids, input_type) are already documented in the schema, establishing a baseline of 3. The description restates the three convertible ID types, which loosely maps to input_type values, but adds no format or syntax detail beyond the schema.

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 (Convert) plus the three exact resource types (DOI, PMID, PMCID), which is unambiguous and clearly distinct from every sibling, none of which perform identifier translation.

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 supplies an explicit scope condition – only articles indexed in PubMed Central can be resolved – which tells the agent when the tool will and won't succeed. It does not name exclusions relative to siblings, but no sibling overlaps this capability, so the routing risk is low.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the content coverage (preprints, patents, Agricola), which is a genuine behavioral trait, but omits auth requirements, rate limits, and pagination behavior for a 5-parameter search tool.

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 front-loaded sentence with zero waste; the scope expansion is stated immediately after the action. Nothing needs trimming.

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 all params are schema-documented. However, with no annotations and no guidance on choosing between this and pubmed_search, the definition is adequate but thin for a multi-source search tool.

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%, so the schema already documents every parameter including sources and sort semantics. The description adds no parameter detail beyond what the schema provides, making the baseline 3 appropriate.

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 ('Search Europe PMC') and immediately differentiates scope from the PubMed siblings by noting it is 'broader than PubMed' with preprints, patents, and Agricola. It is clear what the tool does, though it does not explicitly name which sibling to prefer for PubMed-only searches.

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 context is only implied via 'broader than PubMed' — the agent can infer this tool is for extended coverage, but there is no explicit when-to-use/when-not statement or named alternative. No exclusions or prerequisites are given.

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?

No annotations are provided, so the description carries the full behavioral burden. It correctly signals a read-only fetch and the schema carries the 50-ID batch cap, but the description itself says nothing about rate limits, partial-result behavior, or what happens with invalid IDs.

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 front-loaded sentence with no filler. It is efficient, though arguably so terse that it omits routing context that would have earned 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 return-value explanation is not required, and the schema fully documents both inputs. For a simple lookup tool this is close to complete; only the sibling-routing context is absent.

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 both parameters are documented in the schema, including the 50-ID limit and the include_mesh default. The description adds no syntax or format detail beyond that, so the baseline 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?

States a specific verb (Fetch) and resource (article metadata) and the keying input (PubMed IDs). It is clearly distinguishable from pubmed_search and pubmed_find_related, but it never names a sibling or scoping condition to make the boundary 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?

"By PubMed IDs" implies the tool is used once IDs are already known, which is a reasonable usage signal. However, there is no explicit when-to-use versus pubmed_search/pubmed_summary routing and no note on what to do when PMIDs are unknown.

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?

No annotations are provided, so the description must carry the full burden. It discloses the fallback retrieval chain (PMC, Europe PMC, Unpaywall), which is useful behavioral context, but omits permissions/auth needs, rate limits, failure behavior when full text is unavailable, and whether the chain stops at first success.

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 mechanism. It is efficient and has no filler, though it may be too terse given the lack of usage and behavioral detail.

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?

Output schema exists, so return values need not be explained, and the input schema is fully documented. However, with no annotations and a sibling pubmed_fetch, the definition should at least clarify when to choose this tool and what limitations (e.g., paywalls, availability) exist.

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%, so the schema already documents the PMID list (up to 10), max_sections (default 20), and sections_filter. The description adds no additional parameter meaning, so baseline 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?

States a specific verb 'Fetch' and resource 'full-text articles', and names the retrieval chain PMC → Europe PMC → Unpaywall. This distinguishes it from the sibling pubmed_fetch (which likely retrieves abstracts/metadata) without needing 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 guidance on when to use this over pubmed_fetch or other siblings. The description does not state conditions (e.g., 'use when you need full text and only have PMIDs') or exclusions.

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?

No annotations are provided, so the description carries the full behavioral burden. It says nothing about read-only semantics, rate limits, pagination, or how results are ranked, leaving an agent to infer everything about execution behavior.

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 front-loaded sentence with zero filler. It is efficient, though the terseness contributes to the missing usage and relationship 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 explained. But for a tool with three relationship modes and a sibling that covers citation traversal, the description omits the guidance needed to choose 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 100%, so the schema already documents pmid, max_results, and the relationship enum. The description adds no meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 ('Find articles related to a source PubMed article') that is clearly distinct from sibling search/fetch tools. It does not, however, distinguish the three relationship modes, which is where ambiguity with pubmed_citation_search arises.

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 alternatives. The tool overlaps conceptually with pubmed_citation_search ('cited_by'/'references' modes), yet the description never tells the agent which to prefer or under what conditions.

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?

No annotations are provided, so the description must carry the full behavioral burden. It implies a non-mutating citation-generation operation but does not disclose read-only status, authentication needs, rate limits, error behavior for invalid PMIDs or styles, or whether data is fetched live.

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?

The description is a single, front-loaded sentence with no wasted words. It is efficient, though it remains somewhat under-informative for a tool with sibling alternatives.

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 the input schema fully documents both parameters, so return values and parameter details need not be explained in the description. However, with no annotations and no usage guidance, the description leaves selection among sibling citation-related tools incomplete.

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 both parameters (pmids and style) are documented in the input schema. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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 (Generate) and resource (formatted citations for articles), making the core purpose clear. However, it does not distinguish this tool from siblings like pubmed_citation_search or pubmed_fetch, nor does it mention the PMID-based input or citation styles.

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 description gives no explicit guidance on when to use this tool instead of alternatives such as pubmed_citation_search or pubmed_fetch. Usage is only implied by the name, with no preconditions, exclusions, or workflow context.

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?

No annotations are provided, so the description must carry the full behavioral burden. 'Search and explore' implies a read-only lookup, but the description does not explicitly state safety, idempotency, rate limits, or authentication needs. It also omits pagination behavior, which is relevant for a search tool with a max_results parameter.

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, front-loaded sentence with zero wasted words. It states the verb and resource immediately, making it easy for an agent to parse.

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 simple two-parameter lookup with full schema coverage and an output schema, the description is minimally viable but has clear gaps. It does not explain when to use this tool over siblings or disclose any behavioral traits, leaving the agent to infer read-only safety and usage context.

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%, so both parameters are fully documented in the input schema. The description adds no additional meaning beyond what the schema already provides, which matches the baseline of 3 for high coverage.

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 ('Search and explore') and resource ('MeSH (Medical Subject Headings) vocabulary'), which clearly distinguishes it from sibling tools that search articles rather than the MeSH vocabulary. The word 'explore' is slightly vague, but the core purpose is unambiguous.

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 description gives no guidance on when to use this tool versus alternatives such as pubmed_search or other PubMed siblings. It does not state prerequisites, exclusions, or scenarios where MeSH lookup is preferred over direct article search.

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?

No annotations are provided, so the description carries the full behavioral burden. It only states the operation and does not disclose rate limits, authentication needs, pagination, result format, or an explicit read-only safety profile.

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?

The single sentence is front-loaded and concise, but it is undersized for a seven-parameter search tool in a crowded sibling suite. It omits routing and scope details that would earn their place without adding fluff.

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 schema already documents parameters. However, with many sibling search tools, the description lacks the selection context needed to choose native PubMed search over EuropePMC, Semantic Scholar, or citation search, making it incomplete for agent routing.

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%, so all seven parameters are already documented in the input schema. The description adds no parameter meaning beyond that, which matches the baseline of 3 when structured data does the heavy lifting.

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 the verb 'Search' and the resource 'PubMed for biomedical articles', which is clear. However, it does not differentiate from sibling search tools such as pubmed_europepmc_search, pubmed_semantic_scholar, or pubmed_citation_search, nor does it define scope beyond PubMed.

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 guidance is given on when to use this tool versus the many sibling PubMed/search tools. Prerequisites, exclusions, and alternative-selection conditions are absent.

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?

No annotations are provided, so the description carries full behavioral burden. It discloses the two operational modes and the kind of analysis available, but says nothing about rate limits, authentication, or pagination behavior, and 'deep analysis' is left vague.

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, front-loaded with the core capability and followed by mode routing. No filler, though the second sentence mostly mirrors information already present in the schema.

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 all four parameters are schema-documented. The description covers both modes adequately; only the absence of any behavioral caveats keeps it from being fully complete.

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%, so the schema already documents each parameter and its modes, establishing a baseline of 3. The description largely restates the schema's mode semantics and paper_id hints without adding new format or constraint detail.

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 ('Search or analyze papers via Semantic Scholar API') and names the analytical outputs (citations, influence, references). The Semantic Scholar branding implicitly distinguishes it from pubmed_search and pubmed_europepmc_search, but the description never explicitly contrasts with those siblings.

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 mode-selection guidance: use search_mode='search' for keyword work and 'paper' with an identifier for deep analysis. It lacks any exclusion or routing advice relative to the many sibling search/analysis tools, so the agent must infer when this source is preferable.

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?

No annotations are provided, so the description carries the burden. It reveals the backing service (ESpell, an external NCBI call, hinting at network dependency), but says nothing about whether it returns corrections vs. suggestions, confidence levels, or failure behavior for non-biomedical input.

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 action, with no filler or redundancy. 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 return values need not be documented. For a one-parameter read-style lookup the description covers the essentials, though it could note input expectations or that it is non-mutating given the absence of annotations.

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 the single 'query' parameter. The description constrains the input as a 'biomedical query', which adds real meaning beyond the bare 'string' type, but gives no guidance on length, syntax, or how malformed queries are handled.

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 ('Spell-check a biomedical query') and names the underlying service (NCBI ESpell). It is clearly distinguishable from siblings like pubmed_search or pubmed_lookup_mesh, though it never explicitly frames itself against them.

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?

'Useful for query refinement before searching' implies a workflow position but is soft guidance ('useful for') rather than an explicit when-to-use rule. No alternatives or exclusions are named, so the agent must infer the routing.

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?

No annotations are provided, so the description carries the full burden. It discloses a useful operational constraint ('Up to 50 PMIDs per request') and a performance trait ('faster than pubmed_fetch'), but says nothing about read-only nature, authentication, or any other behavioral limits. The output schema covers return values, so that omission is acceptable.

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 core purpose and the key constraint. No filler; 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?

For a single-parameter lookup tool with an output schema, the description covers the essential purpose, the main alternative, and the batch limit. It could be more complete by stating what a summary contains or whether it is purely read-only, but the output schema and simple schema reduce the burden.

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. It adds meaning by identifying the parameter as PMIDs and imposing a maximum of 50 per request, but it does not specify the string format, whether duplicates are allowed, or behavior on invalid IDs. Partial compensation only.

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 clear verb and resource ('Get concise summaries of articles') and distinguishes itself from pubmed_fetch by speed. It does not specify what the summary contains, but the purpose is unambiguous and an agent can tell it apart from the named sibling.

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 description names pubmed_fetch as an alternative and implies this tool should be used when speed matters, but it does not explicitly state when to choose one over the other or any prerequisites. Usage is inferable rather than spelled out.

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