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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the description doesn't need to cover safety. It adds genuinely new behavior: the HTML-first/PDF-fallback extraction path and the paged-truncation model. It stops short of noting rate limits or extraction quality 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?

Two sentences, front-loaded with the core action and followed by the one operational caveat an agent must know. Nothing is wasted and nothing important is buried.

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 no output schema, the description usefully names the `truncated` and `next_offset` fields an agent will see in the response, which is otherwise undocumented. Complete enough to call correctly, though the unexplained field names could cause brief confusion on first response.

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%, so the baseline is 3, but the description adds paging workflow semantics the schema lacks: how truncation connects to continuing via offset. Minor friction from naming `truncated` and `next_offset`, fields not present in the input schema, though it explains mapping next_offset to offset.

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 ("Return the full text of an arXiv paper") plus the output format ("as plain text") and the source fallback (HTML rendering, otherwise PDF). This clearly separates it from sibling arxiv_get_paper, which an agent can infer serves paper metadata.

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 guidance is limited to the paging case: check `truncated` and pass `next_offset` as `offset`. There is no explicit when-to-use/when-not guidance relative to arxiv_get_paper or biorxiv_get_full_text, so the agent must infer that full text is for deep reading rather than metadata lookup.

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. Beyond that the description adds little behaviorally: nothing about what happens with an invalid ID in a batch, whether partial results are returned, rate limits, or whether the abstract can be absent for withdrawn papers.

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, purpose front-loaded, followed by the input formats that actually matter. No filler and nothing buried at the end.

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 read tool with no output schema and strong annotations, the description covers what is needed to call it correctly, and the format enumeration removes the main failure mode. It would be complete at 5 with a short note on batch error/partial-result behavior and roughly what metadata is returned.

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%, so baseline is 3, but the description earns an upgrade by enumerating concrete accepted identifier forms (new-style, versioned, arXiv:-prefixed, old-style hep-th/9901001, and abs/pdf/html URLs) that the schema's generic 'identifiers or URLs' does not spell out. Only the batch cap is left to the schema's maxItems.

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 specific verb and resource ('Fetch metadata and abstract for ... arXiv papers by ID') and supports batch retrieval ('one or more'), which implicitly separates it from arxiv_get_full_text and arxiv_search. It does not name a sibling outright, so differentiation is inferable 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?

Usage is implied: this is the lookup path when you already hold identifiers, as opposed to search-based discovery. There is no explicit when-to-use/when-not guidance and no alternative named, so an agent must infer that arxiv_search precedes this for unknown papers.

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 value beyond that by disclosing the return payload (metadata and abstracts) and by handing off to a different tool for full text. No mention of rate limits or result-cap behavior, but the schema covers the cap.

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 purpose, then query semantics, then the combination rules, then the hand-off. Every sentence carries information the agent needs; the prefix list and examples are dense but earn their place. No filler or restatement of the title.

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 an 8-parameter, no-output-schema search tool, the description covers the hardest part (query syntax) and tells the agent what comes back. What's missing is modest: guidance on paging behavior across offsets and a pointer that only metadata/abstracts come back rather than full text is present but thin on result volume.

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 63% schema coverage, the description substantially compensates: it explains that bare terms are AND-ed across title/abstract/authors, enumerates the field prefixes (ti, au, abs, cat, all), and gives concrete boolean examples that the schema's one-line `query` description does not. It also clarifies how `query`, `category`, and the date window combine. It does not explain sort_by/sort_order/max_results, though those are self-documenting via enums and defaults.

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+resource ("Search arXiv papers") and immediately states what the tool returns ("metadata and abstracts"), which implicitly separates it from the single-paper lookup sibling. It also explicitly routes full-text reading to arxiv_get_full_text, so an agent can distinguish this tool from at least one sibling without opening either 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 in-context guidance on when to use plain text vs. raw arXiv syntax, and names the alternative arxiv_get_full_text for reading a paper. It stops short of explaining when to prefer arxiv_get_paper (single known paper) over this search, or when the biorxiv siblings are the better choice.

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 the description adds real value on top: the text is sourced from Europe PMC as JATS XML with PDF fallback, availability is delayed, and the failure mode is a descriptive error. It also discloses paging behavior via `truncated` and `next_offset`, fields that no output schema documents. It does not mention rate limits or typical response size beyond max_chars.

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?

Four sentences, each carrying distinct information: what is returned, accepted inputs, availability timing and failure mode, then paging. The most decision-relevant facts (output format and accepted identifiers) are front-loaded with no filler.

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 no output schema, the description must cover return values, and it does: plain text, source format, paging markers, and truncation handling. Combined with 100% parameter coverage and annotations covering safety, an agent has everything needed to call it correctly and to resume a truncated read.

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%, so the baseline is 3; the description earns above that by explaining the paging loop — inspect `truncated`, then feed `next_offset` back into `offset` — a relationship the schema alone cannot express. The three accepted id forms are restated from the schema rather than adding new meaning.

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 precise verb and resource ("Return the full text of a bioRxiv or medRxiv preprint as plain text") and names the underlying source, so an agent knows exactly what comes back. It distinguishes itself from the metadata-oriented sibling biorxiv_get_preprint only implicitly via "full text"; no sibling is named explicitly, which keeps it just 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?

Gives concrete usage conditions: full text usually appears a few days after posting, and an error is raised if it is not yet available. Also explains how to continue reading long papers. It stops short of directing the agent to biorxiv_get_preprint for abstract/metadata or arxiv_get_full_text for arXiv items, so routing to alternatives 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is low; the description still adds real value by naming the authoritative upstream API and disclosing version-suffix handling and server auto-detection. Gaps remain on rate limits, not-found behavior for an invalid DOI, and error shape, which matter for an open-world network call.

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 dense sentences with zero filler: the payload contents lead, and input-format and auto-detection rules follow. Nothing is repeated and nothing is buried.

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 only two parameters and no output schema, the definition covers what an agent needs: accepted inputs, server resolution, and the shape of the returned record. The only omissions are failure modes for an unresolvable or malformed DOI, which are minor for a simple read 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 coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds concrete format examples for `doi` and notes that a trailing version suffix is honoured, which is genuine semantics beyond "Preprint DOI or URL", but the `server` behavior is simply a restatement of 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?

States a specific verb and resource ("Fetch a preprint by DOI from the official bioRxiv/medRxiv API") and enumerates exactly what comes back: title, authors, category, license, abstract, versions, published journal version. It never names a sibling, though, so an agent must infer that this is the metadata lookup rather than the full-text (biorxiv_get_full_text), search, or listing tool.

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 spells out accepted input forms (bare DOI, doi.org link, content URL with v2 suffix) and the auto-detect-unless-`server`-given rule, which is useful orientation. It gives no explicit when-to-use guidance relative to biorxiv_search or biorxiv_get_full_text, leaving the selection to inference from the 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?

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: default window of today, fixed page size of 30 records, and the cursor-continuation pattern, including the implied `next_cursor` value returned in results despite there being no output schema. It stops short of noting any result ordering or whether an empty window returns an empty page, which keeps it from 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?

Four compact sentences: purpose and filter first, then defaults, then pagination, then sibling routing. Every sentence carries information an agent needs, and nothing is repeated from annotations or 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?

For a zero-required-parameter listing tool with no output schema, the description covers the things an agent would otherwise have to guess: the time window default, page size, how to continue paging, and when to prefer search. Annotations plus schema plus this text leave no material gap 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 67%, so some compensation is required, and the description supplies it: concrete category values for both servers, the 'defaults to today' behavior for the date window, and the mechanics of passing the cursor back in. It does not explain the `days`-versus-`date_from` alternative or the `server` switch, but both are documented in the schema itself.

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?

Brevity is not the issue here: the description states a specific verb ('List preprints'), the two resources (bioRxiv/medRxiv), the scoping dimension (a date window) and the optional category filter. It also explicitly distinguishes itself from biorxiv_search, so an agent can choose between browsing and querying without inspecting either 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 final sentence gives an explicit when-to-use ('browsing what is new') and a named alternative with its selecting condition ('use biorxiv_search for keyword queries'). The default (today) and the alternative date parameters are also flagged, leaving little to inference for the primary routing decision.

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 read-only, idempotent, open-world, non-destructive, so the safety profile is covered; the description earns credit for going further by disclosing the underlying Europe PMC index (which explains coverage of both servers and likely indexing gaps) and by stating what comes back — abstracts, DOIs, and whether a published journal version exists. It stops short of describing pagination mechanics or result-count limits beyond what the schema shows.

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?

Four sentences, front-loaded with the core capability, then syntax examples, then filtering/sorting/returns, then sibling routing. No sentence is redundant and the parenthetical about Europe PMC is placed where it explains rather than interrupts.

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 seven parameters, no output schema, and only 57% schema coverage, the description does the necessary work: it explains query syntax, filter scope, sort options, and the shape of results. The main residual gap is `page_size` and cursor-based paging mechanics, though `cursor` is documented in the schema itself.

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 57%, so the description must carry some weight — and it does, most valuably by showing that `query` accepts Europe PMC syntax with two concrete example expressions (`TITLE:"single-cell" AND AUTH:"Regev A"`, `(organoid OR spheroid) AND ABSTRACT:"drug screening"`), which the schema only labels generically. It also clarifies that server filtering and dates apply to first-posted date and enumerates the sort modes. `page_size` is left undocumented, a minor 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?

The description opens with a specific verb and resource, 'Keyword search over bioRxiv and medRxiv preprints', and immediately qualifies the scope by noting it goes through the Europe PMC index. It then explicitly separates this tool's job from biorxiv_get_preprint (version history) and biorxiv_get_full_text (reading a paper), so an agent can route correctly without consulting schemas.

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 names two concrete alternatives and the conditions that select them: use get_preprint for version history and get_full_text to read a paper. The guidance is clear but incomplete as a routing map — it says nothing about when to prefer this search over biorxiv_list_recent or the arxiv_search sibling, which an agent comparing tools would want.

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