Server Quality Checklist

Tool Scores

• health_dailyA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true. The description adds meaningful behavioral context beyond that by explaining that days use civil-day rollups and align to the local calendar rather than UTC, and that the date range is inclusive. This helps the agent understand timezone behavior without contradicting the annotations.

  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 with no filler. The core purpose is front-loaded, and the second sentence adds a distinct behavioral detail. Every sentence earns its place.

  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 is adequate for a read-only aggregate query, and an output schema exists so return value details are not required. However, given the many sibling tools and the undocumented data_type parameter, a slightly richer description would be needed for fully confident tool selection and invocation.

  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 the description must carry the parameter semantics. It explains start and end as a YYYY-MM-DD inclusive range, which is useful, but it leaves data_type entirely undocumented and gives no examples or valid values. This is only partial compensation for the schema gap.

  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 tool as producing a daily aggregate for one data type over a date range. It is specific about the resource and scope, though it does not explicitly differentiate itself from siblings like health_daily_brief or health_trend.

  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 the tool: when a daily aggregate for a single data type over a date range is needed. However, it provides no explicit guidance about when not to use it or which sibling tool would be a better alternative.

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

• health_profileA
  3.5/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true and openWorldHint=true, so the description carries a lower burden. It adds context by specifying the scope of the returned data (profile, unit/timezone settings, paired devices with sync state), which is useful behavioral information. However, it does not mention whether the data reflects the current user, whether units/timezone are editable or just reported, or any additional detail about the sync-state semantics beyond the label.

  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 sentence of eleven words conveys the tool's full scope with zero filler. The key components are listed in a natural order: profile, then settings, then devices. There is no redundancy or repetition of the tool name or title.

  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 parameterless, read-only tool with an output schema and openWorldHint, the description is adequately complete. It tells the agent exactly what area of functionality this tool covers and the presence of an output schema lets the agent inspect the return shape. The description could be improved by explicitly saying 'current user' or noting that this is the baseline profile view distinct from health data summaries, but nothing critical is missing for safe invocability.

  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 no properties, so there are zero parameters to document. Per the baseline rule for 0-param tools, the description need not compensate for any schema gaps. The description appropriately matches the empty schema and adds no unnecessary parameter detail.

  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 names a specific resource (Google Health profile) and enumerates its content: unit/timezone settings and paired devices with sync state. This distinguishes it from sibling tools like health_daily, health_trend, and health_readiness, which focus on data and analytics rather than profile configuration. The only gap is the lack of an explicit action verb like 'get' or 'retrieve', but the resource is so specific that intent is clear.

  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 given for when to use this tool versus alternatives. It does not state e.g. 'use this to check the current user's profile settings' or 'for daily metrics use health_daily instead'. Given eight sibling tools covering related health data, the absence of any routing or exclusion guidance is a significant gap.

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

• health_anomaliesA
  4/5.0
  Behavior4/5

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

  Annotations only declare readOnlyHint=true and openWorldHint=true, so the description carries the behavioral disclosure burden. It reveals that the tool computes a trailing baseline, uses standard deviations as the anomaly criterion, and surfaces only noteworthy days. This adds substantive context beyond the annotations, though it does not address edge cases like insufficient data or empty anomaly sets.

  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 that front-load the purpose and immediately give the anomaly-detection algorithm, followed by a concise value statement. There is no redundant material; every clause 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?

  With an output schema present and annotations covering read-only safety, the description covers the core algorithm and output behavior. It doesn't mention what happens with insufficient data or how many results are returned, but those details are likely captured in the output schema, so the description is adequate for such a focused analytic tool.

  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?

  With 0% schema description coverage, the description must compensate, and it does explain `threshold` as the number of standard deviations from baseline. However, `days` is only indirectly referenced as 'recent days,' so the agent must infer that the `days` parameter controls the scan window; no ranges, units, or further semantics are given. Defaults are present in the schema, so that part doesn't need to be repeated.

  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 opens with a specific verb and resource: 'Scan recent days for metrics that moved more than `threshold` standard deviations from your own trailing baseline.' It defines the detection criterion precisely, distinguishing it from generic trend or daily-data siblings. The final sentence 'Surfaces the handful of days worth talking about instead of a wall of numbers' clearly differentiates it from raw list/trend tools by emphasizing anomaly summarization.

  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 a use case—finding notable anomalies rather than viewing a full dataset—via 'instead of a wall of numbers,' but it never explicitly names sibling tools or states when to choose this over health_trend, health_daily, etc. There is no direct when-to-use/when-not-to-use guidance or exclusion criteria, leaving the routing decision to the agent's inference.

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

• health_daily_briefA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the tool returns a baseline comparison and defaults to today. This is genuine added context rather than a repeat of annotations.

  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 with zero filler. The core capability is front-loaded, the baseline-comparison behavior is stated compactly, and the usage guidance follows naturally. 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 single-parameter read-only tool with an output schema, the description covers the main behavioral details: what data is returned, how it is compared, the default date, and when to use it. It omits the exact date string format, but the output schema and type annotation make the tool safely callable. Complete enough for its 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?

  Schema coverage is 0%, so the description carries the burden of explaining the single 'date' parameter. It does add value by stating 'Defaults to today' and implying the parameter selects the day, but it does not specify the accepted date format. This is partial compensation, not full coverage, so a 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 opens with 'One-call snapshot of a single day' and enumerates the specific metrics included (sleep, resting HR, HRV, etc.), making the resource and action unambiguous. It also adds the distinguishing trait 'each compared against your own trailing baseline'. However, it does not explicitly differentiate itself from the sibling health_daily, so it falls just short of a 5.

  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 clear usage context: 'This is the right first call for "how am I doing today"' and 'Defaults to today'. This tells the agent when to prefer this tool, but it does not name alternatives or state when not to use it, so it lacks the explicit when/when-not structure of a 5.

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

• health_readinessA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, and the description's 'Informational only' reinforces that. It adds meaningful behavior beyond the annotations by disclosing that confidence and missing_inputs are returned, that reasoning is shown, and that the result is not a medical assessment.

  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 tightly written and front-loaded with the core purpose, followed by what is returned and the key safety caveat. Every sentence adds useful information with no repetition or filler.

  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 and read-only annotations, the description covers the main inputs, outputs, and important limitations such as the non-medical disclaimer. It is complete enough for an agent to invoke correctly, though explicit date formatting and sibling-tool routing would make it fully 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?

  The schema has one optional date parameter with zero description coverage. The description adds that this is a per-day calculation, giving the date parameter meaning, but it does not specify the expected date format or behavior when the date is omitted. It is minimally adequate for a single optional parameter.

  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 names the exact outcome, a per-day recovery readiness call combining HRV, resting HR, breathing rate, SpO2, and sleep debt into a train/hold/rest recommendation. This clearly distinguishes it from broader sibling tools like health_daily or health_trend by focusing on readiness scoring.

  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 use for a specific day's readiness and explicitly notes it is informational only and not a medical assessment. However, it does not mention when to prefer this tool over siblings such as health_daily or health_trend, leaving selection partly to inference.

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

• health_trendA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare the operation read-only, and the description adds what the agent can expect: weekly means, direction, and first-to-most-recent change. It goes beyond the schema by framing output semantics and by implying aggregation over multiple weeks, though it does not address edge cases like insufficient week history.

  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 with no filler; the definition is front-loaded and the usage guidance is immediately actionable. Every clause earns its place.

  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 is sufficient for a simple read-only trend tool with an output schema, but it leans on the agent to infer parameter semantics from titles and context. Without schema descriptions or enums, the missing data_type guidance prevents the description from being fully self-contained.

  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 description coverage is 0%, so the description must compensate. It explains that the tool tracks 'one metric' (data_type) and implies weeks via 'week-over-week' and 'first week to most recent', but it never defines valid data_type values or precisely how the weeks parameter changes the calculation. Partial compensation, but a real gap remains.

  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 states a specific analytical purpose: computing a week-over-week trend for one metric, including weekly means, direction, and change from first to most recent week. This clearly distinguishes it from the daily, readiness, and anomaly siblings by focusing on trend over time rather than a single snapshot.

  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 second sentence gives an explicit use case: answer 'is my sleep actually getting worse' rather than reacting to a single bad night. It provides clear contextual guidance but does not name sibling alternatives or state when to prefer a different tool for non-trend questions.

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

• health_pointsA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, and the description reinforces this with 'Read raw data points.' It adds valuable behavioral context beyond annotations: the cross-source reconcile behavior, deduplication, and the high-volume warning that motivates pagination awareness.

  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 compact and front-loaded with the core action, then layered with the reconcile detail and the low-level guidance. Every sentence earns its place, though the three-paragraph split could be tightened without losing value.

  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 complexity of low-level raw data retrieval, the description covers the most critical behavioral aspects: inclusivity of dates, reconcile semantics, and scale warning. It leaves data_type vocabulary to sibling tools like health_data_types, which is reasonable, and an output schema exists to describe returns.

  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 description coverage is 0%, so the description must carry the parameter meaning. It does explain reconcile=True and the date format (YYYY-MM-DD, inclusive), but it does not explain data_type values, page_size behavior, or how paging works. The partial coverage makes it adequate but not complete.

  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-resource pair — 'Read raw data points' — and explicitly frames itself as 'the low-level escape hatch' versus daily-aggregated tools. This clearly separates it from siblings like health_daily and health_daily_brief.

  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?

  It tells the agent exactly when to prefer alternatives: 'For daily questions prefer health_daily or health_daily_brief' and warns that a single day of heart-rate can be 1440 points. It also explains when reconcile=True is appropriate ('almost always what you want'), leaving little to inference.

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

• health_auth_statusA
  4.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the error-recovery context but does not disclose other behavioral details such as cache behavior or credential refresh semantics. It is consistent with annotations and provides some useful context, earning a baseline 3.

  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, no filler. The primary purpose is stated first, followed immediately by the key usage directive. Every word earns its place.

  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?

  For a zero-parameter, read-only status check with an output schema present, the description fully equips an agent: it knows what the tool does and exactly when to call it. No additional context is needed.

  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 coverage is vacuously 100%. The description adds no parameter-level meaning, which is fine because there are none to document; per the baseline for 0 parameters, this scores a 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?

  Description states a specific verb ('Check'), resource ('server holds valid Google Health credentials'), and outcome. It clearly distinguishes this tool from the health_data_types, health_profile, and other data-retrieval siblings by focusing on authentication state rather than health data.

  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 says 'Call this first if any other tool returns a not_authorized error.' This provides a concrete trigger condition and sequencing directive, leaving no ambiguity about when to invoke this tool instead of its siblings.

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

• health_data_typesA
  4.5/5.0
  Behavior4/5

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

  Annotations already establish readOnlyHint=true, and the description consistently describes a read-only listing operation. It adds useful behavioral context beyond the annotation by stating that every readable type is returned and that Fitbit Air-produced types are flagged, which shapes expectations without contradicting the structured metadata.

  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 filler. Every phrase adds value: the action, the scope, and the Fitbit Air classification flag.

  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?

  For a zero-parameter, read-only catalog tool with an output schema present, the description is sufficient. An agent knows exactly why to call it and what result to expect, and no invocation-time details are missing.

  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 effectively complete, so there is no parameter burden for the description to carry. Per the baseline for zero-parameter tools, a 4 is appropriate; there is nothing meaningful left undocumented.

  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 ('List') with a clear resource ('every readable data type') and adds a distinguishing qualifier about Fitbit Air production flags. This makes it easy to tell apart from sibling health-data tools even without inspecting their schemas.

  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 clearly implies use when an inventory of available data types is needed, and the openWorldHint annotation supports exploration. It does not explicitly name alternatives or exclusion conditions, but the sibling tools are clearly data-value tools rather than catalogs, so the intended context is unambiguous.

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