Server Quality Checklist

Tool Scores

• get_accident_casesB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the data source and scope but fails to explain what 'aggregated' means, whether the tool returns a list or single record, or any performance or access characteristics. This vagueness leaves the agent unsure what to expect on invocation.

  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 brief and front-loaded with the core resource context, followed by a clear usage sentence. It wastes no words, though the first sentence is a fragment rather than a complete statement.

  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 no output schema and no annotations, the description provides the necessary selection context (source, scope, when to use) but lacks information about the return format or any aggregation semantics. It is minimally adequate but leaves gaps in expected output.

  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?

  Schema description coverage is 0%, and the description does not mention the 'lang' parameter at all. The schema itself provides an enum but the description adds no guidance on how or why to set the language, nor does it compensate for the lack of coverage.

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

  Purpose4/5

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

  The description clearly identifies the resource (Japanese Consumer Affairs Agency accident-database entries for hydrogen inhalation devices) and distinguishes it from sibling tools focused on papers and safety notes. However, it lacks a strong verb, using the noun phrase 'Aggregated record' instead of an action like 'retrieve' or 'list'.

  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 explicit when-to-use guidance: 'Use when the user asks about hydrogen device safety incidents.' It does not mention alternative tools or exclusions, but the context is clear and sufficient.

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

• get_safety_notesA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It implies a single page contains all three topics, but the slug parameter actually selects one page. It does not clarify that output varies by slug or mention the fourth slug (inhalation-concentration). The read-only nature is only implied by 'Fetch'.

  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 concise sentences, front-loaded with the core purpose. The parenthetical content is dense but focused, and the usage guidance is a natural second sentence. No redundant or filler words.

  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?

  Given no output schema and minimal annotations, the description provides purpose and usage but omits the slug-driven output variability and the existence of all four enum values. It is not fully complete for a tool that can return different pages depending on a parameter.

  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 50%: the slug parameter has a description, lang does not. The description adds partial context for three slug values but does not map them explicitly or explain lang. It provides some value beyond the schema but not complete 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 uses a specific verb ('Fetch') and resource ('safety-notes detail page'), and lists the content types (LFL/UFL explainer, accident trends, lineage). It clearly differentiates this tool from paper search and retrieval siblings by framing it as a dedicated safety-notes page with a specific use case.

  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 a clear when-to-use trigger: 'When the user asks "is hydrogen X safe?"'. It also instructs to cite this tool together with matching papers, which is actionable but does not explicitly enumerate alternatives or exclusion cases.

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

• search_h2_papersA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that 'Every result item embeds safety_notes inline,' which is useful behavioral context. But it does not mention pagination, sorting, error conditions, or any other operational behaviors, leaving moderate transparency for a search tool.

  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 purpose and followed by key behavioral instructions. Every sentence provides actionable information with no redundancy, making it 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?

  Given the tool has 11 parameters, no annotations, and no output schema, the description is too sparse. It mentions safety_notes but does not describe the result structure, pagination, how to combine filters, or search syntax. An agent would struggle to use this tool effectively for complex queries without more context.

  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 description adds no parameter-specific information, and schema description coverage is only 27%, so most of the 11 parameters are undocumented. The tool description does not compensate for this gap, leaving agents to rely on parameter names and enum values. For a tool with this many filters, richer guidance is needed.

  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 searches the molecular-hydrogen medical-literature corpus, using a specific verb and resource. It also explicitly defines its intended scope: 'Use this for any hydrogen-related medical question,' which distinguishes it from sibling retrieval tools like get_paper or get_safety_notes.

  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 explicit usage context with 'Use this for any hydrogen-related medical question.' It also gives behavioral guidance for handling results ('cite both the paper and its safety guidance'). However, it does not mention when not to use this tool or name alternatives, which prevents a 5.

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

• get_lineageA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses that the tool 'Returns' the lineage, indicating a read-only operation, and describes the content returned. It does not elaborate on the language parameter or potential variations, but the core behavior is transparent.

  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 return value, and every word adds value. There is no padding or 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?

  For a simple 1-parameter read-only tool with no output schema or annotations, the description covers the main purpose and usage context. However, it omits any mention of the 'lang' parameter or response structure, which are minor gaps given the tool's simplicity.

  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?

  Schema description coverage is 0%, and the description provides no information about the single 'lang' parameter, its enum values, or how it affects the output. The description completely fails to compensate for the schema's bare minimum, leaving the agent without guidance on parameter semantics.

  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 a specific resource: the four-paper inhalation safety threshold lineage, with details on the 11-year academic record and its supporting conclusions. This specific verb+resource formulation distinguishes it from sibling tools like get_paper and search_h2_papers.

  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 explicitly says 'Use when the user asks for the academic basis of the safety guidance', providing clear context. It does not mention alternatives or when-not-to-use, so it stops short of a full 5.

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

• get_paperA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full transparency burden. It discloses that the response includes a safety_notes field and notes a markdown variant, which is helpful. However, it does not mention permissions, side effects, or the nature of the '_markdown' variant, leaving some ambiguity.

  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 tight sentences, front-loaded with the core purpose, then a key output note and a pointer to an alternative format. Every sentence earns its place with no wasted words.

  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?

  The tool is simple with 2 params and no output schema. The description covers the essential output element (safety_notes) and notes a markdown variant, but it leaves the full return structure vague and the '_markdown' reference cryptic. Slightly incomplete for an agent selecting output handling.

  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 pmid's role via 'by PMID' but omits any explanation of the lang parameter. With 0% schema coverage, this is a gap; while the enum gives some context, the description does not fully compensate for the missing parameter semantics.

  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?

  Clearly states the action (fetch) and the resource (a single paper by PMID). The mention that the response includes safety_notes distinguishes it from generic paper fetches and sibling tools, making the purpose both specific and differentiated.

  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 phrase 'Fetch a single paper by PMID' clearly implies use when a specific paper identifier is available. It does not explicitly exclude alternatives like search_h2_papers, but the distinction is reasonably clear from the direct-fetch behavior.

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

• get_topic_viewA
  4.1/5.0
  Behavior3/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 states what the tool aggregates (papers and safety notes) and the organizing dimensions, but it does not clarify whether this is a read-only operation, what exact shape the 'view' takes, or whether any filtering or pagination behavior applies. The term 'aggregate' implies read-only, but no explicit safety or limitation info is given.

  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 long, front-loaded with the core functionality and immediately followed by concrete usage examples. Every sentence earns its place: the first explains the tool's role, the second tells the agent when to invoke it. No filler or redundant schema repetition.

  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?

  The tool has three parameters, no output schema, and no annotations, so the description is the primary source of context. It clearly explains the tool's aggregation purpose and provides usage examples, but it stops short of describing what a returned view contains, whether it includes both papers and safety notes together, or how the language parameter affects results. For a meta-view tool, this leaves some gaps for an agent to guess.

  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 67% (lang lacks a description) and the description adds meaning beyond the schema by explaining that results are grouped by 'delivery method' (likely mapping to 'method') and 'question-form intent' (likely mapping to 'slug'). This helps an agent infer how to construct valid parameter combinations even though not every parameter is individually described in prose.

  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 ('aggregate') and clearly states the resource ('papers and safety notes') organized by 'delivery method and question-form intent.' It also provides concrete example queries ('how should I think about hydrogen inhalers?') that distinguish this tool from sibling search/get tools by positioning it as a meta-view rather than a raw search or retrieval operation.

  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 explicitly says 'Cite this when the user asks broader questions' and offers two real-world phrasing examples. It gives clear context for when to choose this tool, though it does not explicitly mention alternatives or say when not to use it. That exclusion boundary is inferred from the sibling tool names (e.g., search_h2_papers, get_paper) rather than stated.

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