Server Quality Checklist

Tool Scores

• render_reportA
  4.3/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the output format (HTML and base64), the pure re-render behavior, that nothing is re-scored, the session-finalization requirement, and that the cache does not survive a server restart. This is a rich behavioral context that goes well beyond what schema or annotations could convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, followed by output handling details and limitations. Every sentence adds distinct, non-redundant information: what it renders, how the output is delivered, what it does not do, and when it can be used. No filler or wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, output format, workflow context (relation to submit_answers), and constraints (session finalization, cache volatility). It offers enough context for an agent to decide when to call it. However, the lack of explicit parameter documentation leaves a noticeable gap, especially given that the schema also provides no descriptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explicitly explain the roles of `title` or `result_id`. The context implies `result_id` identifies the finalized assessment, but `title` is completely unexplained. The agent must infer parameter meanings from the tool name and general context, which is insufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Re-render a finalized assessment as a self-contained HTML page' and enumerates the exact content included (meta panel, six-domain summary, per-domain judgement, algorithm trail, evidence, style, provenance). It distinguishes from siblings by explicitly noting 'pure re-render of the artifact submit_answers already stamped — nothing is re-scored.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear when-to-use guidance: the assessment must have been finalized this session, and it clarifies that this is a re-render only, not re-scoring, implying other tools handle scoring or modifications. It also advises how to handle output (display inline or publish as artifact). However, it does not explicitly name alternative tools for export or scoring, so the alternative distinction is implied rather than fully explicit.

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

• get_specA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description takes full responsibility. It discloses that calling this tool alongside assess_result duplicates payload, that the spec descriptions are this implementation's own wording and not the redistributable published text, and that published question IDs ensure interoperability. These are meaningful behavioral traits beyond a simple 'return spec'. It doesn't explicitly mention permissions or side effects, but 'Return' suggests a read-only operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is organized into three focused paragraphs: what it returns, usage guidance, and a legal/behavioral caveat. The first sentence front-loads the core purpose, and every subsequent sentence adds distinct value—no filler. Despite being longer than some tool descriptions, this length is justified by the need to cover copyright and duplication warnings.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and the presence of an output schema (which handles return-value details), the description covers the essential context: purpose, usage, parameter semantics for detail, and licensing limitations. The only gap is the unexplained spec_version parameter, though its name and default make it reasonably clear. Overall, the description provides a complete picture for an optional introspection tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description thoroughly explains the detail parameter: 'detail="compact" (default) gives question ids, own-words labels, response options and evidence modes; detail="full" adds every intent and assessor note.' However, it does not explain the spec_version parameter, which is only inferable from its name and default value. With schema description coverage at 0%, this partial compensation is adequate but not complete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Return the encoded ROBINS-I V2 specification' and enumerates its contents (preliminaries, signalling questions, response vocabularies, etc.), which is a specific verb+resource. It also distinguishes itself from assess_result by explicitly labeling itself as 'OPTIONAL in the assessment flow — introspection only', making the tool's role clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: 'OPTIONAL in the assessment flow — introspection only. assess_result already carries the rubric for the domain in hand, so calling both duplicates the payload.' This tells the agent when to use it, when not to, and names the alternative. It also explains the difference between compact and full detail, guiding parameter selection.

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

• export_robvisA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden. It discloses session-scoped behavior, that `losses` reports unratified records, mixed C4 variants, equal weighting, and differing algorithm transcriptions. It also explains the V2-to-V1 slot mapping, the relabeling in generic layout, and the limitation with 'Low, except for concerns about uncontrolled confounding'. This is exceptional transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but well-structured: front-loaded purpose, bolded warnings, and bulleted layout details. Each section earns its place given the complexity. It is not overly verbose for the amount of critical behavioral and layout information it conveys.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description thoroughly covers the core workflow (records, layout, losses) and important caveats. It lacks explanation of the remaining parameters, but overall it is highly complete for a complex tool with no annotations. An output schema exists, so return values are already specified elsewhere.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so description must compensate. It provides deep, valuable semantics for `records` (the object from submit_answers) and `layout` (difference between robins_i and generic). However, it does not mention `labels`, `weights`, `review_id`, or `result_ids`, leaving four of six parameters undocumented. This is a partial but incomplete compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear, specific verb and resource: 'Combine assessment RECORDS from any number of runs into a CSV for robvis'. It also names the exact output (robvis CSV) and distinguishes it from siblings by focusing on exporting assessment records for the risk-of-bias figure tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly explains when to pass `records` vs. omit it ('Omit records to use only what was assessed in THIS session'), when to read `losses` before publishing, and which layout to prefer ('Prefer 'robins_i' over 'generic'). It also clarifies when to use `layout='generic'` as an alternative.

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

• parse_pmcidA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries the burden and does so well: it discloses the raising behavior when no open-access full text exists, the meaning of supplement_status, and that absence of retrieval does not prove absence of a supplement. These are non-obvious and important behavioral details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but each sentence adds value: purpose, usage alternative, edge-case behavior, and citation override. It is slightly longer than necessary, but well-structured and front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has an output schema, so return structure need not be repeated. The description provides error behavior, supplement semantics, citation override, and sibling-tool differentiation, making it complete for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 explicitly explains the citation override parameter and implies include_supplements behavior through the supplement-fetching context, but it never names or fully clarifies include_supplements as a boolean toggle. Partial compensation with a clear gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves an open-access article from Europe PMC by PMCID and parses it into a source-tagged bundle. It immediately distinguishes itself from parse_document, making it specific and actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says to use this when no file is in hand or to auto-fetch an open-access supplement, and directs users with a manuscript to parse_document instead. This is clear when-to-use and alternative guidance.

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

• assess_resultA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does well. It discloses the per-domain design, the default domain=0 overview, the refusal condition for domain 1 until P1 is set, and the fact that the server (not the agent) computes judgement. These are non-obvious behavioral traits that help avoid misuse.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense paragraph, front-loaded with the main purpose and packed with necessary caveats (per-domain, unreachable questions, refusal, workflow). It is somewhat long but each sentence adds essential context, so it earns its place rather than being wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (per-domain scaffolds, conditional refusal, workflow), the description covers the key usage steps, domain semantics, and behavioral constraints. An output schema exists, so return values are covered by that; the description fills in the strategic context (work one domain at a time, then submit answers, server judges).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It clearly explains domain: default 0 returns overview, 1..6 return scaffolds, and 1 is refused until P1 is set. For result_id, it is referred to as 'this bundle' in the context of cue searches, implying it identifies the result bundle, though not as explicitly as domain.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Return the assessment scaffold for ONE domain' and enumerates the scaffold's contents (questions, intent, vocabulary, evidence, cue searches). It also distinguishes this from a hypothetical flat 41-question rubric, making it clear this is per-domain only.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says when to use: 'Work a domain at a time' and then 'submit_answers' as the next step. It also gives a when-not-to-use: 'There is no flat 41-question rubric to fetch' and explains why asking for one would be wrong. This is clear contextual guidance with an alternative workflow.

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

• set_prespecified_confoundersA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavioral traits: the blocking nature, the definition of 'important', and the ratification queue behavior ('the assessment then carries P1 in its ratification queue and is explicitly not final until they do'). It also clarifies scoping by review_id, adding meaningful context beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than typical but every paragraph adds necessary context: purpose, blocking, importance definition, scoping, and ratification. It is well-structured and front-loaded with the core action, though it could be slightly tightened without losing key information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, no annotations, and an output schema present, the description is complete. It covers when to use, why it's blocking, how to handle ratification, and scoping. With no annotations, it fully carries the burden of behavioral and contextual explanation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 explains 'confounders' (the list of important factors), 'review_id' (scoping to a review), and 'ratified_by' (human acceptance). Only 'rationale' is not mentioned, but it's optional with a default, so the compensation is strong.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Supply P1') and the resource (confounding factors for a review) with context ('before any study is assessed'). It distinguishes itself from per-study tools by emphasizing that P1 belongs to the review, not a single study.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when this must be used ('THIS IS BLOCKING. Domain 1 will not be scored without it'), what counts as important confounders, and how to handle ratification (leave ratified_by empty unless a human accepts). It also warns against substituting the paper's covariate list, providing a clear when-not.

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

• specify_resultA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries full weight and does so excellently. It discloses that accounts_for_deviations 'swaps domain 1's entire question set and algorithm', that getting it wrong 'means answering five questions that do not apply', and that b2/b3 Y/PY 'sends the result straight to critical'. These are meaningful behavioral consequences beyond simple operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but dense and well-structured. It starts with a crisp purpose statement, then prioritizes the most important parameter (accounts_for_deviations) with examples and consequences, followed by concise definitions of remaining fields. Every sentence contributes workflow-critical information; there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (ROBINS-I workflow), the description is remarkably complete. It covers purpose, prerequisite position, key decision logic, parameter semantics, and screening behavior (b1-b3). With an output schema present, the lack of return-value explanation is acceptable. The description enables correct invocation and understanding of downstream effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  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 does. It explains accounts_for_deviations with specific values ('no_itt'/'yes_pp') and its impact, maps result_assessed to A1, outcome to A3, result_location to A2, target_trial to C1-C3, information_sources to D1, and defines b1-b3 roles. This adds substantial meaning to most parameters, far exceeding the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Name the ONE numerical result being assessed, and settle C4', a specific verb+resource+action. It clearly states the tool's role as a required prerequisite ('Required before any domain can be scored'), distinguishing it from siblings like assess_result or submit_answers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear workflow context: this tool must be used before any domain scoring, and each result/analysis should be run separately via its own result_id. It also stresses that accounts_for_deviations cannot be deferred because it changes domain 1's question set. However, it does not explicitly name when-not-to-use alternatives, so it falls short of a 5.

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

• submit_answersA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses tool behavior: the three enforced invariants (quote resolution, server-run absence search, algorithm-computed judgement), the requirement for override justification, the visibility of overrides in the report and ratification queue, and the distinction that incomplete calls require re-calling. It also warns that unratified items mean the assessment is not final. This is rich, honest context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long (roughly 250 words) but every sentence carries operational weight, covering modes, answer format, enforcement, overrides, escalation, and finalization. It uses clear paragraph breaks and a numbered 'three things are enforced' list for readability. While it is more verbose than necessary for a simple tool, the complexity of the tool justifies the density; it loses a point only for being on the longer side.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (12 parameters, two modes, override and escalation logic) and the complete absence of schema descriptions or annotations, the description is remarkably thorough. It covers the answer item structure, the three enforcement mechanisms, the incomplete status and retry behavior, override justification and visibility, the finalization flow, and how to handle the returned report. Output schema exists, so the description doesn't need to detail return fields, but it still explains the meaning of the report and ratification queue.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 explains the structure of `answers` in detail (fields per question, evidence-mode-specific requirements), clarifies `support` as the narrative, and defines the behavior of `override_judgement`, `override_justification`, `domain` (0 finalizes), and `overall_escalate`. However, it omits explicit explanations for parameters like `render`, `direction_of_bias`, `overall_override`, and `overall_direction_of_bias`, though these are less central and somewhat self-explanatory.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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: 'Submit one domain's signalling-question answers and get back the COMPUTED domain judgement, or (domain=0) finalize the assessment.' This clearly distinguishes the tool's two modes and sets it apart from siblings like render_report or assess_result. The resource is well-defined and the outcome is explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides extensive usage guidance: instructing to answer only questions the algorithm reaches, explaining the incomplete status and retry flow, detailing override and escalation requirements, and stating when to use domain=0 for finalization. It also clarifies what not to do (e.g., answering NA) and that the returned report is the artifact of record, not a custom table. This gives the agent clear decision rules for invoking the tool correctly.

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

• parse_documentA
  4.9/5.0
  Behavior5/5

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

  Without annotations, the description discloses error behavior (server-unreadable paths raise), defaults (supplement_status), and the foundational property that all later citations resolve against this parse. It also explains the return value's structure (section map, text hash, cue survey).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Although lengthy, every paragraph is dense with necessary operational details (alternatives, defaults, error handling). The critical 'PRIMARY entry point' is front-loaded, and there is no redundant or filler text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's role, parameter handling, error conditions, return values, and relationship to later calls. Given the output schema exists and the tool is complex, this is fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds detailed semantics for citation, document, supplements, and supplement_status, which are absent from the schema. However, manuscript_id is not mentioned at all, creating a gap in understanding for that parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'PRIMARY entry point' and a specific verb-object: 'parse a study report into a bundle with character-offset, source-tagged section spans.' It explicitly contrasts with parse_pmcid, distinguishing the tool's scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: pass citation for APA reference, use text directly if files are local, use parse_pmcid for open-access, pass supplements when available, and set supplement_status to 'none_exists' when appropriate. This clearly indicates when to use this tool vs siblings.

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