Server Quality Checklist

Tool Scores

• search_groupsA
  3.6/5.0
  Behavior4/5

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

  Given no annotations, the description must carry full burden. It discloses that results are relevance-ranked by the LOINC Search API (same as loinc.org/search UI), that rows are compact for triage, that output is a TOON table capped to a character budget, and that pagination uses 'offset'. This is substantial behavioral context, though it could mention sorting behavior or what facets are for.

  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 fairly concise and front-loaded with purpose. It wastes no words and is structured logically: definition, usage, behavior, pagination. A slight improvement could be combining the rank and page sentences, but overall effective.

  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?

  While the description covers purpose and broad behavior, it lacks explanations for most parameters (6 total, 0% schema coverage, no parameter descriptions in description). There is no output schema, so return format is only vaguely described as 'TOON table capped to character budget'. For a tool with this complexity, the description leaves significant gaps.

  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 schema has 6 parameters with 0% description coverage. The description does not explain any parameter beyond implicit mention of 'query' and 'offset' for pagination. 'rows', 'language', 'sortorder', and 'include_facets' are not explained at all, leaving the agent to guess their semantics from titles 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 clearly states the tool searches LOINC groups, defines what they are (curated collections of related terms), and contrasts with searching individual terms. The verb 'search' plus resource 'groups' is specific, and the examples ('all glucose measurements') make it concrete.

  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 you want a pre-grouped set of related LOINCs rather than individual terms.' It also provides guidance on reformulating queries if top hits miss, avoiding deep-paging, and suggests calling get_loinc for full records. While it doesn't explicitly state when not to use, the guidance is clear and actionable.

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

• search_partsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, description carries full burden. Mentions results are relevance-ranked, rows are compact for triage, output is a TOON table capped to character budget, and to page with offset when truncated. Does not mention auth or rate limits, but reasonable for a read operation.

  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?

  Description is two sentences, front-loaded with purpose. Efficiently communicates key behavioral points and usage guidance. Could be slightly more concise, but 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?

  No output schema, so description should explain return format. Mentions TOON table capped to character budget but not fields. Does not cover error conditions or language/sortorder/facets. For 6-param tool with no output schema, some gaps remain.

  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 explain parameters. It explains query, rows, offset (via pagination mention), but fails to describe language, sortorder, and include_facets. Lacks clarity on these three parameters, which could confuse usage.

  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 searches LOINC parts and defines them as LP-coded building blocks. It distinguishes from sibling tool get_loinc by noting it returns compact results for triage and to drill into full record with get_loinc. The verb 'search' and resource 'LOINC parts' are specific.

  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 to use: 'when you need the canonical part behind a concept, or to explore the axis vocabulary.' Provides guidance on result ranking, suggests reformulating query rather than deep-paging if top hits miss, and recommends calling get_loinc for full details. Differentiates from siblings.

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

• search_answerlistsA
  4.2/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Discloses relevance ranking (same as loinc.org/search UI), truncation behavior with character budget, and recommendation to call get_loinc for full records. Lacks explicit read-only statement but appropriate 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.

  Conciseness4/5

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

  Single coherent paragraph, front-loaded with purpose. Sentences are efficient, but could benefit from minor restructuring to separate behavior from parameter guidance.

  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?

  Covers key aspects: what is searched, ranking, truncation, pagination, and linkage to get_loinc. Missing parameter descriptions but otherwise complete for a search tool with no output schema.

  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 coverage is 0%, but description only explains `offset` in context of pagination. Other parameters (rows, query, language, sortorder, include_facets) are not described, leaving the agent without guidance on their meaning or valid values.

  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?

  Explicitly states 'Search LOINC answer lists' with examples (e.g., smoking-status choices). Distinguishes from siblings by stating 'Use when you need the allowed answers for a term rather than the term itself.'

  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 clear when-to-use vs alternatives, advises reformulating query instead of deep-paging when top hits miss, and explains pagination with `offset` for truncated results.

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

• search_loincsA
  4.3/5.0
  Behavior4/5

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

  Discloses relevance ranking, compact rows for triage, character-budget capped output, and pagination with offset. No annotations provided, so description carries full burden. Could mention read-only nature but otherwise 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?

  Efficiently written with front-loaded purpose, then usage tips, ranking behavior, and pagination. No superfluous sentences.

  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?

  Provides good context for using the tool, including output format (TOON table) and when to use sibling tool. However, missing parameter descriptions and output schema details, leaving some gaps.

  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?

  Parameter schema coverage is 0%, but description only explains query and offset implicitly. Missing explanations for rows, language, sortorder, and include_facets, which are crucial for proper usage.

  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 this tool searches LOINC terms, listing specific examples like lab tests, vital signs, and measurements. It distinguishes from siblings by mentioning get_loinc for drill-down and other search tools.

  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?

  Explicit guidance on when to use this tool (for any LOINC search by name or number), and when to reformulate queries instead of deep-paging. Also instructs to use get_loinc for full record details.

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

• get_loincA
  4.7/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses that null/empty fields are dropped, lists the types of fields returned, and specifies what content is not included (part hierarchy, language variants). Lacks only explicit mention of authorization or rate limits, but these are less critical for a read-only detail lookup.

  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 with no redundancy. The main action is front-loaded, and every sentence provides essential information: what it does, workflow context, and caveats about missing data.

  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 only one parameter, no output schema, and no enums, the description fully covers the needed context: what the tool returns, what it does not, and the workflow in relation to sibling tools.

  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 description compensates by explaining the single parameter 'code' as an exact code like '783-1', clarifying the input format beyond the schema's plain string type.

  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 verb 'Drill into' and the resource 'one LOINC term by its exact code', distinguishing it from sibling search tools by explicitly positioning it as tier-2 of the search→detail 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?

  Explicitly tells when to use the tool: after triaging with search_loincs, then get the code. It also describes what is not in this record and to follow the Link for additional content, guiding the agent on limitations and next steps.

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