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

The description adds substantial behavioral context beyond the readOnlyHint/openWorldHint annotations: the multi-source fallback order (PMC → Europe PMC fullTextXML → Unpaywall), the result formats per source (JATS, HTML-as-Markdown, PDF-as-text), and how quality/budget behaviors vary by source. This is exactly the kind of disclosure that helps an agent predict what it will receive and explains the open-world nature of the tool's 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?

The description is front-loaded with purpose, then the fallback chain, then input modality. It is long, but every clause earns its place given the genuine complexity of a three-layer fallback system. Dense but well-ordered; minor deduction only because some orchestration detail overlaps with what the per-parameter schema descriptions already state.

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 high-complexity tool with nine parameters and a fallback chain, the description covers the orchestration comprehensively: purpose, source routing per ID type, and result formats. The output schema exists and documents return values, so that burden is offloaded. The only minor gap is environmental prerequisites (UNPAYWALL_EMAIL is mentioned in the schema but not surfaced in the description), which is a small omission for an otherwise complete definition.

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 the schema's per-parameter descriptions are already rich (covering resolution, fallback, and applicability). The tool description adds orchestration framing — which source each ID type lands on — but no per-parameter detail beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the full burden and the description adds modest framing value.

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 first sentence states a specific verb and resource ('Fetch full-text articles from PubMed Central with structured sections and references') and immediately adds a strong differentiator — the transparent fallback chain through Europe PMC and Unpaywall. This clearly distinguishes the tool from siblings like pubmed_fetch_articles and pubmed_europepmc_fetch without needing to open 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?

The description gives explicit, actionable guidance on which of the three mutually exclusive ID parameters to provide ('Provide exactly one of pmcids, pmids, or dois') and explains the auto-resolution behavior of each (e.g., DOIs auto-resolve via the ID Converter, preprints fall through to Europe PMC/Unpaywall). The only gap is that it does not state when an agent should prefer a sibling tool (e.g., using pubmed_fetch_articles when only metadata/abstracts are needed), but the input-mode selection guidance is strong.

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