Server Quality Checklist

Tool Scores

• get_daily_health_pulseC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden. It only mentions 'deterministic', indicating consistent output, but lacks disclosure of side effects, authentication needs, or other behavioral traits.

  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 with no wasted words, but it is too brief to cover necessary details. It achieves conciseness at the cost of structure and completeness.

  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 one optional parameter and no annotations, the description leaves many unknowns. While an output schema exists, the description itself is insufficient for a complete understanding of the tool's behavior.

  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 explain the 'recovery_date' parameter's format, meaning, or default behavior. The parameter name is not self-explanatory without additional context.

  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 returns a daily health summary for one date, using a specific verb and resource. However, it does not explicitly distinguish from siblings like get_daily_health_facts, though the term 'pulse' implies a summary nature.

  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 instead of alternatives, or what conditions apply. The description provides no usage context or exclusions.

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

• get_health_historyB
  3.3/5.0
  Behavior3/5

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

  The description correctly states the tool is read-only and limits date range to 90 days, which are important behaviors. However, it does not disclose potential error cases, data origin, or what happens when the range exceeds 90 days. With no annotations provided, the description carries the burden and offers moderate transparency.

  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 sentences, each adding value. It front-loads the primary action and includes key constraints and options 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 description explains the date range limit and optional fields, but lacks prerequisites, error conditions, or format details for dates. Given the output schema likely covers return values, this is adequate but not comprehensive.

  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 0% with no parameter descriptions. The description adds meaning by specifying 'inclusive date range of up to 90 days' and listing example fields like sleep_minutes, steps. But it omits the date format (e.g., YYYY-MM-DD), so compensation is partial.

  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 returns normalized daily metrics for an inclusive date range, with optional field filtering. It also declares read-only. However, it does not explicitly differentiate this tool from siblings like get_daily_health_facts or get_daily_health_pulse, which have similar names.

  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, no prerequisites, and no exclusions. It only implies usage for retrieving historical metrics but lacks explicit context for selection.

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

• get_health_data_statusA
  3.5/5.0
  Behavior2/5

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

  With no annotations available, the description carries full responsibility for behavioral disclosure. It states the tool returns data 'without secrets' but does not indicate whether it is read-only, requires authentication, has rate limits, or what happens on error. The lack of side-effect or permission context limits transparency.

  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 sentence that efficiently conveys the tool's output and a key constraint (without secrets). Every word serves a purpose with no redundancy.

  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 description covers the basic return content but lacks detail on what each status field means and how this tool relates to siblings. With an output schema present, the description could be more self-contained. For a simple tool with no parameters, it is adequate but leaves room for ambiguity.

  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 has zero parameters, and schema description coverage is 100% (trivially). The description adds no parameter meaning, but none is needed. Baseline for zero-parameter tools is 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 returns three specific status components (authorization, last-sync, local data-coverage) and explicitly excludes secrets. It uses a specific verb 'Return' and distinguishes itself from sibling tools like get_daily_health_facts or get_health_records 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 Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus its siblings. There is no mention of prerequisites, typical usage scenarios, or exclusions. The agent must infer context from the tool name alone.

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

• get_daily_health_factsA
  3.6/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 a key non-obvious behavior: 'Activity values intentionally refer to the previous calendar day.' It also clarifies the scope (one recovery date) and the default (today). No mention of side effects, but as a read operation this is sufficient.

  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 concise, using two short paragraphs. The first sentence front-loads the purpose. The second paragraph adds necessary detail. No extraneous information, though the first sentence could be slightly tighter.

  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 read tool with an output schema, the description covers the essential context: purpose, parameter format, and a behavioral quirk (activity lag). It does not mention error handling or missing data, but overall it is complete enough for an agent to use 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?

  Schema coverage is 0% but there is only one parameter. The description adds significant meaning: date format (YYYY-MM-DD), optionality, and default behavior (today). This goes well beyond the raw schema which only provides type constraints.

  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 'Return calculated health facts and 7/28-day baselines for one recovery date' with a specific verb and resource. It also details the data elements (sleep, resting heart rate, HRV). However, it does not explicitly differentiate from sibling tools like get_daily_health_pulse, though the unique mention of baselines and activity lag provides some distinction.

  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 syntactic guidance on using the date parameter ('Use YYYY-MM-DD or omit the date for today'), but no guidance on when to use this tool versus sibling tools (e.g., get_daily_health_pulse, get_health_history). The agent receives no context on alternative selection.

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

• get_health_data_catalogA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must convey behavioral traits. It indicates a read-only listing operation, but does not disclose performance guarantees, result size, or whether the list is exhaustive. It is transparent about what it lists but lacks depth.

  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?

  One short sentence (11 words) that is front-loaded with the action 'List.' No wasted words, very efficient.

  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 the simplicity (no parameters, output schema present) and no sibling tool with similar scope, the description is mostly complete. However, 'local record coverage' could benefit from elaboration, but the output schema likely clarifies.

  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?

  There are 0 parameters, so the description carries the burden. It adds meaning by specifying what is listed ('supported detailed data type and its local record coverage'), which goes beyond the empty 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 clearly states it lists 'every supported detailed data type and its local record coverage,' which is a specific verb ('list') and resource. It distinguishes from siblings like get_health_history (which lists actual records) and get_daily_health_facts.

  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 directly state when to use this tool vs alternatives, but its purpose ('list all data types and coverage') implies it is for discovering available data types. No explicit exclusion or condition is mentioned.

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

• get_health_recordsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses encryption at rest, full-fidelity data, date inclusivity, pagination behavior, and specifics about sleep records and heart rate samples. This provides valuable behavioral context beyond the schema.

  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 with three sentences. The main purpose is front-loaded, and every sentence adds value without redundancy. No unnecessary words.

  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?

  With an output schema present, the description does not need to detail return values. It covers usage order (catalog first), data type selection, pagination, and special data fidelity aspects. Slightly more detail on data_types format would improve 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?

  Schema coverage is 0%, so the description must compensate. It adds semantics for dates ('inclusive YYYY-MM-DD values') and mentions pagination parameters. However, it does not explain the format or possible values for the 'data_types' parameter, leaving some ambiguity.

  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 ('Return') and the resource ('encrypted-at-rest, full-fidelity Google Health records'). It distinguishes from sibling tools like get_daily_health_facts by emphasizing 'full-fidelity' and mentioning specific data types like sleep and heart rate.

  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 guidance: 'Use the catalog first, request only the data types needed, and paginate with limit/offset.' It also notes inclusive date formats. However, it does not explicitly state when not to use this tool or name alternative tools for different purposes.

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

• get_health_windowA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description covers key behaviors: it returns records, uses ISO 8601 timestamps with local timezone handling for naive timestamps, and limits the window to seven days with bounded, pageable results. It does not explicitly state read-only status, but as a get operation, it is implied. The description sufficiently discloses potential pitfalls like timezone handling and pagination.

  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 five sentences, each adding essential information: core purpose, intended usage, timezone handling, window limit, and pagination. No extraneous words, well front-loaded, and 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?

  Given the presence of an output schema (so return values are covered), the description covers the main aspects: what the tool does, when to use it, timezone behavior, window constraints, and pagination. The only gap is the lack of explanation for the data_types parameter, which could affect agent decision-making. Overall, it is quite complete for a tool of moderate complexity.

  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 5 parameters with 0% description coverage. The description explains start_time and end_time as forming an ISO 8601 time window and mentions naive timestamp handling, which adds meaning. However, it does not describe data_types (nullable array of strings), limit, or offset, leaving their semantics entirely to schema defaults. This partial explanation results in a baseline score of 3 for low 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 clearly states 'Return detailed records overlapping an exact ISO 8601 time window', which specifies the verb and resource. The context for correlations with other timestamped tools further clarifies its purpose and distinguishes it from siblings like get_daily_health_facts which are for daily aggregates.

  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 use cases: 'correlations with calendar events, workouts, sleep periods, and other timestamped tools'. It also mentions constraints: maximum window of seven days and pagination. While it does not explicitly list when not to use or alternative tools, the context is strong enough for an AI 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.