Server Quality Checklist

Tool Scores

• get_patient_informationC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, and the description offers minimal behavioral context beyond the verb 'get'. It does not disclose whether the operation is read-only, what data sources are queried, or any side effects, leaving the agent with little understanding of the tool's behavior.

  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 a single, concise sentence with no extraneous words. However, it could include more useful information without becoming overly verbose, so it is slightly above average but not perfect.

  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 presence of five sibling tools and no output schema, the description is too minimal. It fails to specify what kind of patient information is retrieved (e.g., demographics, medical history), making it incomplete for an agent to use effectively.

  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 parameter description ('Patient identifier.') is clear. However, the tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

  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 states the tool retrieves patient information from rehabilitation data sources, but it is somewhat broad and does not distinguish from sibling tools that also involve patient data, like calculate_patient_risk_scores.

  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 versus alternatives. The description lacks any context about prerequisites, exclusions, or specific scenarios, providing no help for tool selection.

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

• identify_declining_rehabilitation_outcomesC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but does not disclose behavioral traits like how decline is determined, what measurements are used, or that lookback_days controls the time window. Lacks transparency.

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

  Conciseness3/5

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

  The description is a single sentence, concise but under-specified. It could be improved by adding key details about parameters 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?

  Given the lack of output schema and annotations, the description is incomplete. It does not explain the output format, the meaning of 'declining', or how the parameters affect results.

  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 50% (only patient_id has a description). The tool description adds no meaning for either parameter, failing to explain that lookback_days sets the time range or how patient_id filters.

  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 'Identify' and the resource 'patients whose rehabilitation outcomes are declining', which distinguishes it from sibling tools like calculate_patient_risk_scores or create_patient_alerts.

  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 versus alternatives. The description only states what it does, not when it should be chosen over similar tools.

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

• search_rehabilitation_researchC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully convey behavioral traits. It only states what the tool does, but lacks details on side effects, idempotency, or constraints like 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.

  Conciseness4/5

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

  The description is a single efficient sentence. It is front-loaded with the verb. Could be improved by brief parameter hints, but overall concise.

  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 search tool with two parameters and no output schema, the description is minimally adequate but lacks details about output format, what 'Firecrawl' is, or how to refine searches.

  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 adds no meaning for the parameters (query and limit). The schema provides defaults and constraints, but the description should explain how to formulate queries or how limit affects results.

  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 action (Search) and resource (Firecrawl for research papers and summaries). It is specific and distinct from sibling tools which focus on patient-specific operations.

  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 versus alternatives. Sibling tools are listed but no explicit when/when-not or selection criteria provided.

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

• create_patient_alertsB
  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 must carry full behavioral disclosure. It indicates a write operation ('create and persist') but does not mention side effects (e.g., whether it overwrites existing alerts), authorization needs, or error conditions. This is insufficient for a mutation 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?

  The description is a single, clear sentence that front-loads the purpose. It is concise with no superfluous information, though structured formatting (e.g., parameter list) could improve readability.

  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?

  The tool has three parameters with low schema coverage and no output schema or annotations. The description does not hint at the return value (e.g., created alert details) or error handling. Given its complexity as a creation tool, more context is needed for safe 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?

  Only one of three parameters (patient_id) has a schema description. The description adds context for risk_threshold and lookback_days by linking them to the threshold-crossing logic, but does not fully explain their meanings or valid values. It complements the schema modestly but leaves gaps.

  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 states the action (create and persist alerts) and the condition (patients whose rehabilitation risk or declines cross thresholds). It distinguishes from siblings like calculate_patient_risk_scores, but the term 'declines' is slightly ambiguous.

  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 when to use (when thresholds are crossed) but does not explicitly state when not to use or provide alternatives. It lacks guidance on prerequisites, such as requiring risk scores or decline identification first.

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

• calculate_patient_risk_scoresB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description should fully disclose behavioral traits. It mentions calculation and data sources but omits whether the tool is read-only or mutates any state, required permissions, side effects, or output format.

  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, no redundant information, and the action (calculate) and resources (risk scores) are front-loaded. Every word adds value.

  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?

  The tool has no output schema and moderate complexity (multiple data sources). The description fails to explain what the risk scores look like, how they are formatted, or any thresholds. It also does not mention that omitting patient_id covers all patients, though the schema does. Overall incomplete.

  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 input schema has two parameters with 50% description coverage (patient_id has a description, lookback_days does not). The tool description adds context on data sources but does not explain lookback_days or provide additional semantics beyond the schema for patient_id. Baseline 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 clearly states the tool calculates rehabilitation risk scores and lists specific data sources (patient records, therapy sessions, wearable measurements, medication adherence). It effectively distinguishes from siblings like 'identify_declining_rehabilitation_outcomes' which focuses on decline detection rather than scoring.

  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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, context, or conditions for invocation.

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

• generate_rehabilitation_reportsA
  3.5/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Mentions generating a report and optional Firecrawl research section, but does not clearly state whether it is read-only, any side effects, permissions, or rate limits. 'Generate' suggests non-destructive, but not explicit.

  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 front-loads key purpose. No wasted words, but could benefit from breaking out options (e.g., single patient vs cohort, optional research inclusion).

  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?

  With 3 parameters, no output schema, and no annotations, description fails to provide sufficient context. Missing behavioral traits, output format details, and how 'whole cohort' is specified. Leaves agent uncertain about usage boundaries.

  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 covers 67% of parameters (patient_id, include_research have descriptions; lookback_days missing). Description adds no extra meaning beyond schema. Does not explain lookback_days or parameter interactions.

  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 verb 'generate' and resource 'markdown rehabilitation report', and distinguishes between 'one patient or the whole cohort'. This differentiates it from sibling tools like calculate_patient_risk_scores or search_rehabilitation_research.

  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?

  Implies usage for generating reports, but no explicit guidance on when to use this versus siblings like identify_declining_rehabilitation_outcomes or search_rehabilitation_research. No when-not-to-use information.

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