Server Quality Checklist

Tool Scores

• reindexA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate the tool is not read-only and not destructive, so the description need not restate those. It adds useful scoping (local, downloaded papers), but it does not disclose the default behavior of clear_existing (default true) or potential side effects like deletion of the existing index before rebuild. This is a moderate addition beyond 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 entire description is a single sentence that directly states the action and scope without unnecessary words. It is concise and well-structured.

  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?

  For a simple tool with one optional parameter and no output schema, the description covers the basic function. However, it omits important context such as the default clear_existing behavior, expected use cases, and potential time cost, making it minimally adequate but lacking full completeness.

  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 schema fully describes the only parameter, clear_existing, including its type and default value. The description adds no further parameter-level details, so it does not compensate beyond the schema's coverage.

  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 the specific verb 'Rebuild' and identifies the resource 'local semantic index' for 'downloaded papers', which clearly defines the tool's scope. This distinguishes it from siblings like search_papers and semantic_search, which operate on the index rather than rebuild it.

  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?

  The description gives no guidance on when to use this tool or alternatives. It does not mention prerequisites (e.g., after adding new papers) or contrast with other maintenance operations. Users are left to infer the appropriate context.

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

• check_alertsA
  3.9/5.0
  Behavior1/5

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

  The description contradicts the annotations: it states that the tool 'Updates each watch's last_checked timestamp after running,' which is a write operation, yet the annotations declare readOnlyHint=true. This is a serious inconsistency that could mislead an agent into thinking the tool has no side effects. Per the rubric, this contradiction forces a score of 1.

  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 concise yet complete. Every sentence contributes value: purpose, parameter behavior, side effect, prerequisite, and return format. It is well-structured and front-loaded with the primary action, making it easy for an agent to quickly understand the tool.

  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 simplicity (one optional parameter, no output schema), the description covers all essential aspects: what it does, how parameters affect behavior, side effects, prerequisite knowledge, and the nature of the return value (summary with counts and metadata). It is fully contextual for an agent to use the tool correctly.

  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 schema already documents the topic parameter with 100% coverage, providing the baseline of 3. However, the description adds meaningful semantics beyond the schema: it explains the behavior when omitted (all watches), when provided (exact match required), and the side effect of timestamp updates that affect subsequent calls. This added context elevates the score to 4.

  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 with a specific verb and resource: 'Check all saved topic watches for newly published papers since the last check.' It also distinguishes itself from siblings by focusing on saved watches and the since-last-check behavior, which is unique among the listed tools like search_papers or semantic_search.

  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 explicit usage context: it explains the default behavior (check all watches) versus the optional topic parameter, and it names the prerequisite tool (watch_topic) to register topics. However, it does not explicitly mention when not to use this tool or compare it to alternatives like search_papers or semantic_search, which would warrant a 5.

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

• citation_graphA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds that it returns both citing and referenced papers, which is useful. However, it does not disclose potential network latency, output size limits, or pagination behavior. With annotations covering the read-only nature, a score of 3 is appropriate.

  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?

  A single, well-structured sentence that states the tool's function without superfluous detail. Every word contributes to clarity.

  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 simple one-parameter read-only tool with no output schema, the description covers the essential behavior: it returns citing and referenced papers. It could be slightly more explicit about whether results include metadata, but the level of detail is sufficient for selection and invocation.

  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 schema provides 100% coverage for the single parameter, including an example arXiv ID format. The description adds no additional parameter semantics, so the baseline of 3 applies.

  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 returns papers citing an arXiv paper and papers it references, using Semantic Scholar's citation graph. This specific verb+resource combination distinguishes it from sibling tools like search_papers or read_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 a clear use case: to get citation relationships for a specific arXiv paper. It does not explicitly compare with alternatives or state when not to use it, but the context is strong enough to infer appropriate usage.

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

• download_paperA
  4.2/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, but the description adds specific behavioral details: it stores the paper locally (a side effect), tries HTML first then falls back to PDF, and supports start/max_chars pagination. This goes beyond the annotations to clarify the tool's non-read-only nature and practical behavior.

  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, front-loaded with the main purpose, and each sentence earns its place by covering core behavior, fallback strategy, storage side effect, and pagination. No redundant or filler content.

  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 tool with no output schema, the description adequately states the return type ('text content'), explains side effects (local storage), and covers pagination for large papers. It lacks details on error behavior, rate limits, or output format nuances, but the openWorldHint annotation mitigates this, making the description reasonably complete.

  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 100%, so the schema already documents all three parameters. The description adds minimal value by mentioning 'start/max_chars pagination,' but this concept is largely already stated in the schema (e.g., 'Zero-based character offset' and 'Maximum raw paper characters'). It provides no new details about paper_id beyond what's in 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 a specific verb+resource: 'Download a paper from arXiv and return its text content.' It clearly distinguishes from siblings like read_paper by mentioning it stores the paper locally and uses HTML/PDF fallback extraction, making the tool's unique purpose evident.

  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 on when to use this tool (for downloading and obtaining text content with pagination) but does not explicitly compare it to alternatives like read_paper. It implies usage for full paper retrieval and handling large papers, which is a clear situational context, yet lacks explicit 'when not to use' guidance.

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

• watch_topicA
  4.4/5.0
  Behavior4/5

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

  The description adds meaningful behavioral detail beyond annotations: it is persistent, returns only new papers since last check, and updates existing watches. It also explains the query syntax compatibility with search_papers. This goes beyond the minimal readOnly/destructive hints provided.

  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 concise and well-structured. It front-loads the core purpose, then adds usage context, examples, and an important behavioral caveat (update vs duplicate). Every sentence contributes essential information without repetition.

  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 that this is a stateful tool with no output schema, the description does a good job explaining the persist-and-poll workflow, query syntax, and update behavior. It lacks explicit error conditions or return format, but the 'returns only papers published since the last check' covers the key output behavior.

  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 input schema fully describes all three parameters, but the description adds value by explaining the 'same query syntax as search_papers' and giving concrete examples. It also clarifies the update semantics of the topic parameter, which is not in 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 a specific verb+resource: 'Save or update a persistent research topic watch.' It clearly distinguishes from sibling tools like check_alerts (which polls) and search_papers (which performs one-off searches) by framing it as a standing alert mechanism.

  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 explicitly explains when to use it (to create a standing alert) and pairs it with check_alerts. It also clarifies that calling with the same topic updates rather than duplicates. It does not explicitly say when not to use it versus search_papers, but the context is clear.

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

• get_abstractA
  4.5/5.0
  Behavior4/5

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

  With readOnlyHint=true already providing the safety profile, the description adds context by emphasizing the tool does not download the full paper and returns listed metadata fields. This goes beyond annotations and helps the agent understand the tool's behavior, though it does not cover error cases or rate limits.

  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 concise and well-structured: a clear opening sentence, usage guidance, return summary, and a workflow tip. Every sentence adds value, with no wasted words or redundancy.

  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?

  For a simple one-parameter tool with good annotations, the description is complete. It explains the purpose, usage context, returned data, and workflow placement, leaving no significant gaps. The lack of an output schema is mitigated by the explicit list of returned fields.

  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 100% and the single parameter paper_id is well described. The description only restates that the tool fetches by ID, adding no extra syntax or format details beyond what the schema already provides, so a baseline score of 3 is appropriate.

  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 ('Fetch') and identifies the resource ('abstract and metadata of an arXiv paper by ID'), clearly distinguishing it from download_paper by explicitly stating it does NOT download the full paper. It also names the metadata returned, making its purpose unmistakable.

  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 tells the agent when to use this tool: 'Use this before download_paper to assess relevance and save tokens.' It also provides a concrete workflow (search_papers -> get_abstract -> download_paper -> read_paper), making the usage context and alternatives very clear.

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

• read_paperA
  4.6/5.0
  Behavior5/5

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

  Annotations provide readOnlyHint=true, and the description adds substantial behavioral context: it returns markdown, supports start/max_chars pagination for large papers, and fails with a clear error if the prerequisite download is missing. This goes well beyond annotation-only information.

  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?

  Three sentences, each contributing: purpose, return format and pagination, and prerequisite workflow. Information is front-loaded and there is no redundancy.

  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 tool is moderately simple, but with no output schema, the description compensates by stating return format (markdown) and pagination. It lacks details on what the markdown includes (e.g., figures, references) but is otherwise complete for the workflow.

  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?

  Input schema covers 100% of parameters with clear descriptions for paper_id, start, and max_chars. The description mentions pagination but adds no new meaning beyond the schema; it is a fair baseline given full schema coverage.

  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?

  ‘Read the text content of a paper’ clearly states the verb and resource. It explicitly distinguishes from siblings like download_paper (which fetches) and get_abstract (which reads only the abstract), and specifies the markdown output and pagination support.

  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 says to call download_paper first and gives a workflow: search_papers -> download_paper -> read_paper. It also warns about failure if the paper is not downloaded, making the usage context crystal clear.

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

• list_papersA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, but the description adds useful behavioral details: it returns only arXiv IDs and returns an empty list if no papers are downloaded. This goes beyond the annotation without contradicting it, though it stops short of describing rate limits or other edge cases.

  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, front-loaded with the main purpose, then detailing return format and edge case. Every sentence adds value, and there is no redundancy.

  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?

  For a simple zero-parameter read-only tool, the description fully covers purpose, output format, empty-list case, and its position in the workflow. An output schema is absent, but the return description is sufficient for the tool's simplicity.

  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 schema has zero parameters, so there is no parameter information to convey. The baseline for a no-parameter tool is 4, and the description appropriately focuses on behavior rather than parameters.

  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 papers downloaded via download_paper, specifies the scope (local storage), and clarifies the return type (arXiv IDs only). It explicitly distinguishes from siblings by referencing read_paper for content and search_papers in the workflow.

  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 an explicit workflow (search_papers -> download_paper -> list_papers -> read_paper), establishing exactly when this tool fits. It also tells the user to use read_paper for content access, which is a clear alternative.

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

• semantic_searchA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate read-only and closed-world hints, but the description adds critical context: it only searches the local downloaded collection, returns empty results if no downloads exist, and requires pro dependencies with an install command. This goes beyond the annotations and provides valuable behavioral expectations.

  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 concise and well-structured: the first sentence states purpose, the second flags a critical limitation, and the third provides workflow and installation context. Every sentence earns its place with no redundancy or fluff.

  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?

  For a read-only search tool with no output schema and high-quality annotations, the description covers purpose, scope, limitations, prerequisites, and usage workflow. It is complete enough for an agent to select and invoke the tool 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 coverage is 100%, so parameter descriptions already provide clear semantics. The description adds an example query and frames query vs. paper_id as alternatives, but does not significantly extend beyond the schema. It meets the baseline for a covered schema without adding substantial new 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 tool performs semantic similarity search over papers already downloaded locally via download_paper, using specific verbs and identifying the resource. It distinguishes itself from siblings by contrasting with search_papers (arXiv-wide search) and download_paper (fetching papers).

  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?

  Usage guidance is explicit: the tool only searches the local collection, returns empty if no papers are downloaded, and provides a concrete workflow (use search_papers, then download_paper). It also states the pro dependency prerequisite. This clearly explains when to use it versus alternatives.

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

• search_papersA
  4.8/5.0
  Behavior5/5

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

  With readOnlyHint and openWorldHint already provided, the description adds significant behavioral context: arXiv's 3-second rate limit is handled automatically, and if a rate limit error occurs, the agent should wait 60 seconds rather than retrying in a loop. It also discloses default sort behavior and the fact that results are ordered by relevance. This goes well 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?

  Though lengthy, the description is well-structured with clear headings (QUERY CONSTRUCTION GUIDELINES, ADVANCED SEARCH PATTERNS, CATEGORY FILTERING, EXAMPLES, DATE FILTERING, RESULT QUALITY, RATE LIMITING, TIPS). It front-loads the main purpose and each section provides actionable, non-redundant information. The length is justified by the tool's complexity.

  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?

  For a tool with 6 parameters, no output schema, and a rich search domain, the description is exceptionally complete. It covers query syntax, field filters, categories, date filtering, sort options, rate limiting, and gives multiple concrete examples. It even provides tips for foundational research, ensuring the agent can effectively use all parameter combinations.

  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?

  Although the schema already covers 100% of parameters, the description greatly enriches the query parameter with detailed query construction guidelines, field-specific syntax, examples, and category code meanings. It also clarifies date format usage and sort_by semantics, adding far more value than the schema alone.

  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 'Search for papers on arXiv with advanced filtering and query optimization,' clearly identifying the specific verb (search), resource (arXiv), and advanced filtering capability. This distinguishes it from sibling tools like list_papers or semantic_search, which serve different purposes.

  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 extensive usage context: when to use quoted phrases, OR, field-specific searches, category filtering, date filters, and when to choose relevance vs. date sorting. It offers clear guidance on constructing effective queries and recommends categories for relevance. However, it does not explicitly mention when to use an alternative sibling tool or when not to use this tool, 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.