Server Quality Checklist

Tool Scores

• book_appointmentB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, so the description's 'CONSEQUENTIAL WRITE' adds minimal new behavioral information. No additional side effects, authorization needs, or post-conditions are disclosed, so the description does not significantly extend beyond the structured annotations.

  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 very short (two sentences). The first sentence clearly states the purpose. The second sentence, while redundant with annotations, is not excessively long. No structural issues, but could be slightly more efficient by omitting the redundant note.

  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 three required parameters with no schema descriptions and an output schema (whose content is unknown), the description provides no parameter details or return value expectations. The agent lacks sufficient context to use the tool correctly without external knowledge.

  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%, meaning the input schema provides no parameter descriptions. The tool description fails to explain any of the three required parameters (patient_id, when, reason), leaving the agent without essential semantic context to pass correct 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?

  The description explicitly says 'Book a new appointment for a patient,' providing a specific verb (book) and resource (appointment). It clearly distinguishes from sibling tools like get_patient, list_appointments, and search_patients, which are read/query operations.

  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 does not provide explicit guidance on when to use this tool versus alternatives. It states the basic action but lacks context about prerequisites, availability constraints, or exclusion criteria. Usage is implied by the tool name and sibling contrast.

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

• get_patientA
  3.6/5.0
  Behavior3/5

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

  The description aligns with the readOnlyHint annotation, indicating a read operation. However, it adds no extra behavioral details (e.g., response format, performance constraints) beyond what annotations already convey.

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

  Conciseness5/5

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

  Single sentence, front-loaded with key action and resource, no extraneous words. Highly efficient.

  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?

  Output schema exists to define return values, and the description covers the basic purpose. However, missing usage guidelines and parameter details reduce completeness for a tool with 0% schema description coverage.

  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%, yet the description does not elaborate on the patient_id parameter beyond 'by id'. No format, source, or constraints are provided, leaving the agent with minimal guidance.

  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 patient demographics and conditions by ID, using a specific verb ('Return') and resource. It effectively distinguishes from sibling tools like book_appointment and search_patients.

  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?

  No explicit guidance on when to use this tool versus alternatives like search_patients. The context implies use when a patient ID is known, but no exclusions or conditions are stated.

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

• list_appointmentsA
  3.6/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, indicating non-destructive behavior. The description adds no additional behavioral traits beyond what annotations convey, such as pagination, ordering, or response 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 a single, front-loaded sentence with no wasted words. Every word adds value.

  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?

  While the description covers the core purpose, it lacks details on pagination, sorting, or result limits. Given the existence of an output schema (context signal) and the relatively low complexity (3 params, 1 required), the description is adequate but not fully 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?

  With 0% schema description coverage, the description adds minimal meaning: it mentions patient and optional date range but does not clarify the required patient_id, date formats, or default values beyond what the schema names imply.

  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 (list), resource (appointments), and scope (for a patient, optionally filtered by date range). It distinguishes itself from siblings such as book_appointment, get_patient, and search_patients.

  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 (list appointments with optional date filter) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it specify 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.

• search_patientsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description adds value by clarifying the output is 'lean summaries' and that patients are synthetic, which helps the agent understand result nature and data domain. However, it doesn't mention potential pagination or result 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?

  Two short sentences front-load the action and key information without any unnecessary words. Every sentence earns its place.

  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 single-parameter search tool, the description covers the main purpose and output nature. It doesn't discuss edge cases or response structure, but the presence of an output schema (not shown) might supplement this. Overall adequate.

  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 the 'query' parameter accepts names or conditions. This adds meaning beyond the raw schema, though it lacks details on format or examples.

  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 'Search', the resource 'synthetic patients', and the criteria 'by name or condition'. It distinguishes this tool from siblings like 'get_patient' (single patient) and 'list_appointments' (appointments) by its search nature and focus on patients.

  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 the tool is for searching patients by input terms but provides no explicit guidance on when to use it versus alternatives (e.g., 'get_patient' for exact ID lookup). It lacks exclusions or contextual cues for decision-making.

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