Server Quality Checklist

Tool Scores

• resolve_paperB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint and openWorldHint, so the description's behavioral disclosure burden is lower. It adds that the output is 'normalized', but does not detail errors, caching, or external lookups.

  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?

  Single sentence with clear verb and object, front-loaded. Efficient but could benefit from brevity around parameter usage without becoming verbose.

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

  Completeness2/5

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

  Despite having an output schema, the description does not explain what a 'normalized paper candidate' includes or how parameters like year and authors affect resolution. Lacks completeness for a 4-parameter tool.

  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%, so description must compensate. It mentions DOI, URL, or title query, but parameters include separate fields (query, title, authors, year) without mapping or usage hints. Adds only minimal value over 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?

  Description clearly states the tool resolves a DOI, URL, or title query into a normalized paper candidate. It specifies the verb 'resolve' and the resource type, distinguishing it from siblings like 'fetch_paper' or 'batch_resolve'.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool vs alternatives like 'fetch_paper' for full details or 'batch_resolve' for multiple queries. Missing prerequisites or context for choosing this tool.

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

• browser_preflightA
  3.8/5.0
  Behavior4/5

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

  Beyond the annotations, the description discloses that the tool 'opens publisher pages' and 'may update filtered storage-state,' which are important side effects not captured in the annotations. It also explicitly states what it does NOT do (run PDF fallback, automatic authentication). This adds meaningful behavioral context about external network access and state mutation.

  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 two sentences and front-loaded: the first sentence states the core purpose, and the second adds side effects and exclusions. Every word contributes value, with no redundancy or filler.

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

  Completeness3/5

  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 details are covered. The description adequately conveys purpose, side effects, and non-behaviors. However, for a tool with 7 parameters and a diagnostic role, it lacks usage guidance (when to invoke vs. siblings) and parameter semantics. It is not fully complete for an agent to confidently select and use it in all contexts.

  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 provides no details about the individual parameters (detail, provider, test_url, timeout_ms, etc.). The only hint is the mention of 'may update filtered storage-state,' which vaguely relates to storage_state_path/save_storage_state, but it fails to explain the role of parameters like detail or test_url. With zero schema coverage, the description should compensate more.

  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 ('Live-check') and a clear resource ('the shared browser HTML path') with scope ('for one provider or all browser providers'). It also distinguishes itself from sibling tools by explicitly stating it 'never runs PDF fallback or automatic authentication,' which clarifies its diagnostic role versus fetch/resolve tools.

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

  Usage Guidelines3/5

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

  The description implies usage for verifying browser access to publisher pages before fetching, but it does not explicitly state when to use this tool versus alternatives or name any sibling tools. The exclusion of PDF fallback and automatic authentication hints at boundaries, but there is no direct guidance on when to prefer this over fetch_paper or resolve_paper.

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

• batch_fetchA
  3.9/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true, so the description's mention of 'access remote services' and 'write the same cache, artifacts, or Markdown' adds useful context beyond the annotations. It also discloses the behavioral nuance of detail=bounded ('returns only a batch-wide bounded text sample') and notes persistence options. This is a solid addition without contradicting any annotations.

  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 three sentences with no unnecessary words. It front-loads the core action and scope, then adds key parameter guidance. Every sentence provides distinct value, making it both concise and well-structured.

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

  Completeness2/5

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

  Despite having an output schema and annotations, the description is too brief for a tool with 20 parameters and nested objects. It fails to mention many critical aspects like modes, strategy, concurrency limits, or how batch results are returned. While the output schema covers return values, the tool's breadth demands more context to be considered complete.

  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?

  The schema is large (20 parameters) and has 0% description coverage, so the description must compensate. It only explains detail, run_manifest, resume, and overwrite, leaving the remaining 16 parameters (e.g., modes, strategy, concurrency, no_download) completely unexplained. This is a significant gap for a complex tool with nested objects and many options, so the description adds only minimal parameter-level meaning.

  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 function: 'Fetch 1..50 papers with bounded concurrency and input-ordered compact manifest/acceptance results.' It uses a specific verb ('Fetch') and resource scope (papers), and distinguishes itself from related tools by mentioning it shares effects with fetch_paper but operates as a batch process. This makes its purpose unambiguous and differentiated from siblings.

  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 provides usage context by noting it 'may access remote services and write the same cache, artifacts, or Markdown as fetch_paper,' implying it's an alternative for batched fetches. It also gives parameter-level guidance (e.g., 'Set run_manifest or resume for auditable persistence'). However, it does not explicitly state when to use this tool over others, nor does it list exclusions or specific scenarios, 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.

• get_cachedA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral details: 'without touching the network' (no network calls), and explains the behavior of detail and preferred_only parameters (compact vs full, preferred entries). It does not contradict annotations, and the added context about network-free operation is useful beyond what annotations provide.

  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 extremely concise, consisting of two sentences with no filler. The first sentence immediately states the purpose and key constraint (no network), and the second sentence elaborates on parameter details. Every sentence adds value, and the structure is front-loaded.

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

  Completeness2/5

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

  Given the tool's complexity (8 parameters, nested objects, has output schema), the description is incomplete. It only covers the purpose and two parameters. It fails to explain the strategy object, max_tokens, download_dir, modes, and include_refs, which are essential for proper use. The output schema exists but is not referenced; the description should guide the agent on what to expect, but does not.

  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%, so the description must compensate. It only explains two parameters: detail (compact vs full) and preferred_only. The other six parameters (doi, modes, strategy, max_tokens, download_dir, include_refs) are not described, including the complex strategy object. This leaves the agent with insufficient understanding of how to use most parameters, especially the nested strategy input.

  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's purpose: 'Look up DOI-proven cached files within one download_dir without touching the network.' This specifies the verb (look up), resource (cached files), and key constraints (DOI-proven, within one download_dir, no network). It differentiates from siblings like fetch_paper (which accesses network) and list_cached (which likely lists all cached items).

  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 implies usage for cached file lookups without network access, providing clear context. However, it does not explicitly state when to use this tool over alternatives like fetch_paper or list_cached, nor does it mention when not to use it. A clear usage context is present, but no exclusions or direct comparisons are made.

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

• has_fulltextA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint. The description adds useful context about using cheap metadata and landing-page signals, and the word 'likely' reinforces the open-world nature. No contradiction.

  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 a single, front-loaded sentence that captures the tool's purpose and method with no 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?

  Given the tool's simplicity (one parameter, output schema exists), the description adequately covers what the tool does and its behavioral traits. The missing parameter documentation is a minor gap, but overall the tool's action and use case are clear.

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

  Parameters1/5

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

  The only parameter 'query' has no description in the schema (0% coverage), and the tool description does not explain its format or expected values (e.g., DOI, title). This is a significant gap for a single 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 clearly states the tool probes whether a paper likely has full text using cheap metadata and landing-page signals. It uses specific verb 'probe' and resource 'paper full text', distinguishing it from siblings like fetch_paper which retrieve full text.

  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 provides clear context that the tool is a cheap preliminary check, implying it should be used before more expensive fetches. However, it does not explicitly name alternatives or state when not to use it.

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

• batch_resolveA
  4/5.0
  Behavior4/5

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

  Annotations already mark it as read-only and open-world. The description adds behavioral traits: shared transport reuse (implying network efficiency) and optional cross-host concurrency. No mention of rate limits or side effects, but these are adequately covered by annotations.

  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?

  Single sentence, front-loaded with action, no superfluous words. Every phrase (shared transport reuse, optional cross-host concurrency) adds value.

  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 simplicity (2 params, output schema exists), the description covers the key aspects. It doesn't mention max/min items (in schema) or error conditions, but these are reasonable omissions for this complexity level.

  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?

  With 0% schema description coverage, the description compensates by explaining that queries can be DOIs, URLs, or titles, and that concurrency is optional and cross-host. This adds meaning beyond the raw schema (array of strings, integer).

  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 it resolves multiple DOI, URL, or title queries with specific optimizations (shared transport reuse, concurrency). It differentiates from siblings like resolve_paper (single) and batch_fetch (likely fetches full text) by emphasizing batch resolution of identifiers.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this vs alternatives like fetch_paper or batch_fetch. It does not mention that single queries should be handled by resolve_paper, or that batch_fetch is for fetching full text. The agent must infer usage context.

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

• list_cachedA
  4/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, so the description adds value by detailing the modes and their effects on the manifest and cache. However, it does not explicitly state that no data is modified, which is already implied by readOnlyHint.

  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 two sentences with front-loaded purpose. Each sentence earns its place: the first states the core action, the second explains the parameter options. No redundant information.

  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 presence of an output schema and annotations, the description covers most necessary information. The only minor gap is the insufficient explanation of the download_dir parameter, which is not critical but could be clearer.

  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 explains the cache_mode enum values in detail, compensating for the 0% schema description coverage. However, download_dir is only vaguely described as 'within the selected download_dir', leaving its purpose and default behavior unclear.

  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 lists cached downloads without network access, and explains three modes (index, refresh, rescan) with distinct behaviors. This distinguishes it from sibling tools like fetch_paper that access the network.

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

  Usage Guidelines3/5

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

  The description implies usage for offline listing but does not explicitly state when not to use it or provide alternatives (e.g., use fetch_paper for fresh data). The sibling tool names are available but not referenced.

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

• batch_checkA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint and openWorldHint. The description adds that success items keep only lightweight provenance fields, and mentions concurrency capability, providing useful context beyond the annotations.

  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 two concise sentences with no wasted words, front-loaded with the main purpose and then specific details.

  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 presence of an output schema and moderate complexity, the description covers the return format and concurrency. It could be more complete by mentioning error handling or behavior on partial failures.

  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%. The description partially compensates by hinting at the concurrency parameter via 'cross-host concurrency', but the mode and queries parameters are not explained.

  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 checks multiple papers without returning full bodies, returning lightweight provenance, with optional concurrency. This distinguishes it from siblings like batch_fetch and fetch_paper.

  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 implies when to use (when only lightweight provenance is needed) and hints at alternative use of batch_fetch for full bodies, but does not explicitly state when not to use or list alternatives.

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

• provider_statusA
  4.3/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description adds a meaningful behavioral trait: it never opens Chrome/CDP or publisher pages. This tells the agent the tool has no live browser side-effects. It also implies 'static' and 'local' behavior, which complements the read-only annotation without contradicting it.

  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?

  Two sentences, front-loaded with the primary action in the first sentence, and the second sentence adds an important caveat and alternative. Every word earns its place; there is no fluff or repetition of schema details.

  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?

  For a status inspection tool with an output schema and read-only annotations, the description is fairly complete: it states the core purpose, the non-browser behavior, and directs to the appropriate live tool. However, the lack of any parameter explanation leaves a gap, since the schema's enum values are not self-explanatory for all users. Still, the tool is simple enough that this is a minor shortcoming.

  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%, so the description bears full responsibility for explaining parameters. However, it only says 'filtered' without explaining what group, detail, or provider mean. The enums in the schema are self-explanatory to some degree, but the description adds no guidance on how to choose values like 'official' vs 'browser' or 'compact' vs 'full'.

  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 uses a specific verb ('Inspect') and names the resource ('filtered static provider configuration and local dependency readiness'). It clearly distinguishes itself from sibling tools by explicitly stating 'This never opens Chrome/CDP or publisher pages' and pointing to browser_preflight for live health, making its unique scope very 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 provides explicit when-to-use and when-not-to-use guidance: use this tool for static configuration and local readiness checks, but use browser_preflight for live health. It names the alternative tool directly, which is exactly what this dimension asks for.

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

• fetch_paperA
  4.6/5.0
  Behavior5/5

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

  The description discloses significant behavioral traits beyond annotations: it may access remote services, write provider artifacts/assets/MCP cache sidecar, and clarifies that no_download suppresses writes while save_markdown is a separate write. It also mentions access controls and auth boundaries, adding value beyond the readOnlyHint=false and openWorldHint=true annotations. No contradiction.

  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 and lengthy but every sentence carries technical value, covering defaults, side effects, and option behaviors. The structure is a compact paragraph with semicolons, which is efficient for a tool with many options, though it could be more scannable with bullet points.

  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 12 parameters, nested objects, and an output schema, the description is remarkably complete. It covers defaults, side effects, cache semantics, asset behavior, a resource link for provider catalog, and access control guarantees. The output schema exists, so return values need no explanation. The description rounds out the tool's operational context fully.

  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?

  With schema coverage at 0%, the description compensates by explaining key parameters: modes, include_refs, max_tokens, prefer_cache, no_download, artifact_mode, save_markdown, and asset_profile. It clarifies semantics like save_markdown returning a path instead of inline text and asset_profile controlling local assets. Some parameters (e.g., download_dir, markdown_filename) remain undocumented, but the description covers the most complex ones.

  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 ('Fetch one paper') and the resource (paper), while enumerating output formats (structured article, Markdown, metadata). This distinguishes it from siblings like batch_fetch or resolve_paper, making the purpose unambiguous.

  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 offers clear contextual guidance on defaults and option semantics (e.g., 'no_download=true suppresses writes', 'Use prefer_cache=true only with matching request semantics'). It does not explicitly name sibling tools for exclusion, but the usage context is sufficiently clear for an agent to decide when to invoke this tool.

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