Google Health MCP
Server Quality Checklist
Latest release: v0.7.4
- Disambiguation4/5
Most tools have clearly distinct purposes (auth, inventory, demo, quickstart), but google_health_data_inventory, google_health_data_type_coverage, and google_health_list_data_types could be confused if descriptions are not read carefully. Overall, overlaps are minor and descriptions help.
Naming Consistency5/5All tools follow a consistent 'google_health_<descriptive_name>' pattern using underscores. No mixing of conventions like camelCase or inconsistent verb usage.
Tool Count4/511 tools is a reasonable count for a server focused on setup and metadata for Google Health. However, the set lacks actual data manipulation tools, slightly limiting its scope but appropriate for its stated purpose.
Completeness4/5For the intended role of onboarding and discovery, the tool set covers authentication, data type inventory, demo payloads, and a quickstart guide. Missing tools for actual read/write of health data, but that appears deliberate given the server's metadata-oriented design.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 5 community issues answered or closed in the last 6 months
- 46 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds no new behavioral context—no mention of pagination, timezone handling, supported data types, or return format. It essentially restates the tool's title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence with no fluff. It is front-loaded with the action verb. However, it is so terse that it borders on under-specification, though for conciseness it earns high marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 10 parameters, the description is far too minimal. It fails to explain the meaning of 'physical time intervals', the relationship to daily rollup, or any behavioral nuances. An agent would be under-informed for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, meaning 4 of 10 parameters lack descriptions. The tool description offers no parameter explanations at all, leaving gaps for page_size, page_token, response_format, and data_source_family. Since coverage is moderate, the description should have compensated but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'aggregate' and resource 'data type over physical time intervals', which distinguishes it from the sibling 'google_health_daily_rollup' by the 'physical time' qualifier. However, it does not explicitly name the alternative or contrast with daily rollup, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It doesn't mention physical vs. daily intervals, prerequisites, or contexts where one should be preferred. Given the sibling 'google_health_daily_rollup', a clear opportunity for usage guidance is missed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the behavioral context of 'reconciled stream' and 'across sources', but does not disclose pagination behavior, privacy mode effects, or response format details. This is modest added value beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action 'Read a reconciled stream'. It is concise with no redundant wording. It could benefit from more detail, but it earns its place by being direct and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having annotations and an output schema, the description is minimal for a tool with 8 parameters and 50% schema coverage. It does not mention key behavioral options like privacy_mode, explicit_user_intent, or response_format, which are crucial for correct usage. The description alone is insufficient for an agent to understand all relevant parameters and modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description does not compensate for the undocumented parameters. It repeats data source family names already present as enum values in the schema, adding no new semantic meaning. The description does not clarify page_size, page_token, response_format, or data_source_family beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a read operation for a reconciled stream across sources, which distinguishes it from raw data tools. It mentions specific data source families, but does not explicitly contrast with sibling tools like google_health_list_data_points, so it falls 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 Guidelines2/5Does 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. It does not mention when to prefer reconciled data over raw list_data_points, nor does it list exclusions. The usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Query' aligns with these. However, the description adds only a note about kebab-case data types and does not disclose behaviors like pagination, privacy_mode handling, or the requirement of explicit_user_intent for raw mode. It does not contradict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences: the first states the core purpose, and the second gives a format instruction with examples. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and a rich output schema, the description provides only the essential purpose and data_type format. It does not mention filtering capabilities, pagination, privacy modes, or response formats, but these are partly covered by the schema and parameter descriptions. The lack of contrast with sibling tools makes it slightly incomplete for selection, but the output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57%; data_type, filter, privacy_mode, and explicit_user_intent have descriptions in the schema. The description contributes by emphasizing kebab-case format for data_type and giving examples (steps, sleep, heart-rate), but it does not explain filter, pagination, page_size, page_token, or response_format. The schema covers those partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Query' and identifies the resource as 'detailed data points for a Google Health data type', which distinguishes it from sibling tools like google_health_list_data_types (which lists types) and google_health_daily_rollup (which provides rollups). However, 'detailed' is vague and does not explicitly contrast with rollup/summary tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are provided. The description only instructs on kebab-case data types, which is a parameter format note, not tool selection. It fails to mention that for rollup/summary views, one should use google_health_daily_rollup or daily_summary, and for listing available data types, use google_health_list_data_types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds unique behavioral context by stating it does not call Google Health APIs or expose secrets, which is beyond the annotation hints and clarifies its non-destructive, offline nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences convey the essential purpose and a key constraint. Every word is meaningful; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) and only 2 enum parameters. The description is adequate for a simple manifest-retrieval tool, but given the large sibling set, more detail on when to use this versus other info tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description adds no explanation of the two parameters (client, response_format). Although they are enums with defaults, the description does not clarify their purpose or usage, leaving the agent with no guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it provides 'machine-readable install, runtime and client guidance for AI agents' with the caveat of not calling Google Health or exposing secrets. This specifies a clear verb (provides guidance) and resource (manifest data), distinguishing it from data-access or mutation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description only mentions what the tool does not do ('Does not call Google Health or expose secrets'), but fails to state when to use it or how it compares to the other 24 sibling tools. No explicit when-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent, but the description adds valuable behavioral context: it explicitly guarantees not revealing secret values and enumerates the inspected areas (local privacy, cache, token-path, env-presence). This rises above simply relying on the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words that conveys the core purpose and a key safety behavior. Every element is relevant and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is read-only, has a single optional parameter, and an output schema exists, the description covers the essential purpose and safety behavior. It leaves the exact shape of 'posture' open, but that is likely defined by the output schema, so the description is sufficiently complete for a simple audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one optional param 'response_format' with an enum, but schema description coverage is 0% and the description does not mention this parameter. The description fails to compensate for the lack of parameter documentation, even though the enum is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action ('Return') and identifies the resource scope: local privacy, cache, token-path, and env-presence posture. This clearly separates it from cache-only or connection-only tools, though it does not explicitly name siblings or provide a contrasting alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus sibling tools like google_health_cache_status or google_health_connection_status. The description implies a privacy-focused audit but does not state selection criteria, exclusions, or use-case context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent, and destructive=false, so the bar is lower. The description adds the auth scope requirement and 'authenticated user' context, which are useful behavioral details beyond annotations. Output schema covers return format, reducing the need for further 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core function and requirement without any unnecessary words. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Annotations and output schema cover safety and return values, but the description fails to distinguish this tool from google_health_profile_get or explain when to use it in the broader tool ecosystem. For a simple get operation, it is minimally viable but lacks integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with privacy_mode and explicit_user_intent documented in the schema. The description itself adds no parameter information, but the missing response_format is self-explanatory via its enum. The schema does the heavy lifting, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get authenticated user profile details from Google Health' with a specific verb and resource. However, it does not differentiate from the sibling tool google_health_profile_get, which appears to be a near-duplicate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions 'Requires profile scope', which is an authorization prerequisite, not guidance on when to use this tool versus alternatives. There is no mention of when to prefer this over profile_get, list_data_points, or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it uses 'dailyRollUp' and operates over civil days, but it doesn't disclose pagination behavior, rate limits, or output nuances. This is adequate given the annotation coverage, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the first stating the core function and the second listing example use cases. No redundant information or fluff. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief for a tool with 10 parameters and many sibling tools. It doesn't explain how to determine valid data types (though schema points to list_data_types), the relationship to rollup/daily_summary, or pagination details. The output schema exists, so return values are handled, but the description lacks enough context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with parameters like data_type and page_size having detailed schema descriptions. The tool description itself only references data types generically and doesn't explain parameters like start_date, window_size_days, or response_format. It adds marginal value beyond the schema and doesn't fully compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Aggregate a data type') and the resource ('over civil days using Google Health dailyRollUp'), naming the underlying API method. It also lists example use cases ('steps, distance, calories...'), which helps distinguish it from sibling aggregation tools like weekly_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (useful for steps/distance/etc.) but does not explicitly say when to use this tool over siblings like google_health_rollup or google_health_daily_summary. No when-not-to-use or alternative guidance is given, leaving the choice ambiguous for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds context about returning example payloads but does not disclose additional behavioral traits beyond what annotations provide. Since the annotation burden is met, a score of 3 is appropriate—the description adds some value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key action and resource types ('Returns realistic Pixel-Watch-style example payloads...'). Every part of the sentence is informative, and there is no redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple demo tool with one optional parameter and no output schema, the description provides the core information: what it returns (example payloads for three specific APIs) and why (to show the contract). However, it does not mention the response_format parameter or give a hint about the output structure. A brief note about the available formats would improve completeness, but the description is mostly adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the parameter. However, the description does not mention the 'response_format' parameter at all. The schema provides an enum and default, but the description adds no meaning beyond that. This is a significant gap for a tool with only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns example payloads for three specific Google Health API calls. The verb 'Returns' paired with the specific resource types (e.g., google_health_daily_summary) makes the purpose unambiguous and distinguishes it from sibling tools that perform real API calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for previewing contract shapes before calling real APIs ('so agents see the contract before calling real Google Health APIs'). However, it does not explicitly state when to use this tool versus alternatives like directly calling the real tools, nor does it provide exclusions or conditions. The usage guidance is present but implied and incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, openWorld, idempotent, and non-destructive, so the description doesn't need to repeat those. It adds the normalization target but provides no additional behavioral details such as live data fetching, caching, or error handling. This is acceptable given the annotations cover safety traits, but the description offers limited extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It conveys the core action, input, and output in a compact form, earning its place without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is too brief for a tool with six parameters and a normalization role. It omits how parameters like soreness or injury_flags affect the output, whether data is pulled live from Google Health, and how the normalized shape is used downstream. This gap makes the tool under-specified for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only days and timezone have descriptions). The description mentions no parameters at all, leaving notes, soreness, injury_flags, and response_format unexplained. With low schema coverage, the description should compensate, but it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Normalize') and identifies the input ('Google Health activity/sleep context'), output ('shared wellness_context shape'), and purpose ('for recommendation engines'). This clearly distinguishes it from sibling tools focused on demos, rollups, or data inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for normalizing data into a shared wellness context specifically for recommendation engines. It implies when to use it but stops short of explicitly stating exclusions or naming alternative tools, so it doesn't fully meet the 'when-not-to-use' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about the optional cache and its enablement, but doesn't disclose what the status output contains or behavior when cache is not enabled. This is acceptable given annotations and output 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and then adds the key prerequisite. There is no filler or redundant information, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with one optional parameter, the combination of description, annotations, and schema provides sufficient context. The description explains what the tool shows and how to enable the cache, while the output schema (if present) would cover return details. Minor gap: it doesn't state what happens if cache is not enabled, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, response_format, has a default and enum in the schema, but the description provides no explanation of it. With schema description coverage at 0%, the description should compensate, but it doesn't mention the parameter at all. The enum values are self-explanatory (markdown/json), but the absence of any description is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'Show optional local SQLite cache status.' The verb 'show' and resource 'local SQLite cache status' are specific and unambiguous. It also distinguishes itself from sibling tools, none of which focus on cache status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool by explaining that the cache is optional and how to enable it ('Enable with GOOGLE_HEALTH_CACHE=sqlite or GOOGLE_HEALTH_CACHE=true'). This implies the tool is relevant when cache is configured, though it doesn't explicitly state exclusions or alternatives. Sibling tools don't offer a similar function, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations that already declare read-only/idempotent/non-destructive, the description adds three non-obvious traits: beta status, non-medical scope, and the availability-based source selection ('when available'). These provide useful context about maturity and data reliance that annotations don't cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single 16-word sentence that front-loads the action and resource, followed by a compact list of caveats. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters, an output schema, and strong annotations, the description covers the core purpose, data source, and key limitations in one sentence. It omits fallback behavior details and usage comparison to siblings, but overall it provides sufficient context for typical invocations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description mentions none of the three parameters, and the schema only provides coverage for timezone (33%). The date and response_format parameters lack descriptive context, leaving the agent to infer semantics from defaults and enum values. This is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Build' with a clear resource 'daily summary' and identifies its source data ('Google Health rollups and reconciled streams'), differentiating it from sibling tools like daily_rollup or weekly_summary. It also includes the qualifier 'when available' to set scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for generating a daily summary but does not explicitly state when to prefer it over google_health_daily_rollup or weekly_summary, nor does it mention any exclusions or fallback guidance. The 'when available' hint suggests conditional availability but lacks concrete alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, and non-destructive nature, lowering the bar. The description adds valuable context about requiring the 'settings scope' and that it targets the 'authenticated user,' providing permission and user-scoping details beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy. Every word contributes: the action, the resource, example fields, and the required scope. It is front-loaded and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and strong annotations, the description does not need to explain return values or safety traits. It covers the essential purpose and permission requirement. However, it omits mention of the privacy_mode parameter's 'raw' escalation path, which is an edge case an agent might need to know, but this is partially compensated by the schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the three parameters (privacy_mode, response_format, explicit_user_intent), even though schema description coverage is only 67%, leaving response_format without a description. The phrase 'such as units and timezone' pertains to the return data, not to input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('authenticated user settings') with concrete examples ('units and timezone'). This distinguishes it from sibling tools like google_health_get_profile, which serves a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to fetch user settings but does not explicitly state when to use it versus alternatives. It mentions the required 'settings scope' as a prerequisite, which gives some guidance, but lacks explicit exclusion or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by specifying that it does not call Google APIs and does not expose secrets, which are important guarantees beyond the annotations. It does not describe any side effects (there are none), but the added constraints are useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is information-dense and front-loaded with the verb and object. It avoids fluff and covers multiple aspects efficiently. However, it reads as a long list that could be slightly more structured, but overall it is appropriately sized for the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status/diagnostic tool, the description covers the key areas checked and explicitly states non-behaviors (no API call, no secret exposure). It mentions MCP client readiness, which aligns with the client parameter. Since an output schema exists (though not shown), return values are likely documented. The description is sufficiently complete for an agent to understand the tool's scope and invoke it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only hints at the 'client' parameter with 'optional MCP client readiness' and says nothing about 'response_format'. The enums and defaults are present in the schema, but the description fails to explain how these parameters affect behavior or how to select values, leaving the agent under-informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Check') and a well-defined resource (local Google Health config, token file, Node version, privacy mode, cache readiness, MCP client readiness). It explicitly scopes the tool to local checks and clarifies what it does NOT do (calling APIs or exposing secrets), making its purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear usage context: it is a safe, local, non-network diagnostic tool. The phrase 'without calling Google APIs or exposing secrets' implicitly tells the agent when to use this tool (e.g., for local troubleshooting) and that it is non-invasive. However, it does not explicitly mention alternatives or exclusion cases, so it falls short of the highest guidance standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, providing strong behavioral transparency. The description adds minimal extra context beyond calling it 'Generate', which is consistent. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action and resource, with no extraneous text. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description, combined with annotations and output schema, provides sufficient context. However, it could mention that the URL is for manual user interaction or redirect. Nonetheless, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with two of three parameters described in the schema. The tool description does not add any additional parameter information beyond what is in the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource 'Google OAuth authorization URL for Google Health API'. It also includes usage context ('Use this first when no local token exists'), effectively distinguishing it from sibling tools like google_health_exchange_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this first when no local token exists', providing clear guidance on when to invoke this tool. It implies that if a token exists, this tool is not needed, but does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds minimal behavioral context beyond this: it notes the operation is for the authenticated user and implies a mapping is returned, but it does not describe what the mapping contains or any additional behavior. This is an acceptable baseline given the strong 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the core action, the second provides a use case. There is no extraneous information, and the most critical details (what and why) are front-loaded. This is an example of concise and structured writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and strong annotations, so the description does not need to explain return values or safety. It covers the purpose and a concrete use case. It could benefit from a bit more about what 'identity mapping' entails, but the output schema likely fills that gap. Overall, the description is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, which is moderate. The description does not mention any parameters, relying on the schema to explain privacy_mode and explicit_user_intent. Since response_format lacks a description, there is a minor gap, but the enum constraints and the schema's existing descriptions cover most of the semantic burden. The description adds no extra parameter detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the Google Health identity mapping for the authenticated user, using a specific verb ('get') and a distinct resource ('identity mapping'). It distinguishes from siblings like get_profile and get_settings by explicitly naming the identity mapping, and the Fitbit migration context adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Useful for Fitbit-to-Google migrations,' which signals when this tool is relevant. It does not explicitly mention alternatives or when not to use it, but the use case is specific enough to guide selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context about the specific topics covered (privacy boundaries, beta status), reinforcing that the tool is a safe, read-only overview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose without any fluff. It is efficiently front-loaded and earns its conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are not needed. The description adequately covers the tool's role as a capabilities overview, though it could mention that it is an entry point for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the single parameter 'response_format'. This parameter is simple (enum with default), but the description fails to add any meaning beyond the schema, which is especially noticeable given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool explains supported data, privacy boundaries, beta status, and recommended workflow. It distinguishes itself from sibling tools like google_health_list_data_points or google_health_privacy_audit by being a meta-capabilities overview tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for initial orientation by mentioning 'recommended agent workflow', but it does not explicitly state when to use it versus alternative tools or provide usage exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds that the tool does not call Google APIs, which is valuable behavioral context beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key purpose and is highly concise, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple inventory tool with no required parameters and an output schema, the description fully covers what the tool returns and its behavior (no API calls), making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter response_format is not explained in the description, but its enum values (markdown, json) are self-explanatory. Schema description coverage is 0%, so the description could have added meaning but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Inventory' and the resource 'supported Google Health data types, auth scopes, privacy modes and recommended first calls', distinguishing it from sibling tools that perform specific actions like get_profile or list_data_points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for exploring available capabilities without making API calls, but it does not explicitly state when to use this tool versus alternatives like google_health_capabilities or other inventory-like tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that live mode never returns raw health payloads, only redacted status and point-count buckets, which is critical safety information beyond the annotations. No contradiction with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, zero wasted words. The structure efficiently conveys two operational modes in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's behavior for both modes. It could mention the impact of parameters like 'data_types' on output, but the schema covers that. Overall, sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%). The description does not explain parameters like 'date', 'response_format', or 'data_source_family' beyond what the schema provides. While the schema details the 'data_types' slugs, the description adds no additional semantic value for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a data-type coverage plan from the official table or runs live read-only checks. The verb 'build' and 'run' with specific resources ('coverage plan', 'read-only checks') make the purpose distinct from sibling tools like google_health_data_inventory or google_health_list_data_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes (plan building and live checks) but does not explicitly compare with alternatives or specify when not to use. The context is clear enough for an agent to decide between the static table approach and live OAuth checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context: the exact file path, the set of returned fields, and a strong security guarantee ('NEVER contains OAuth tokens or API secrets'). This goes beyond annotation redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with four short sentences each adding distinct value: action+path, returned fields, security guarantee, and read-only confirmation. No redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the main purpose and return value well. It lacks details about error cases (e.g., missing file) but these are not critical for a getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not mention the response_format parameter. The schema itself has an enum and default, but the description fails to compensate for the missing narrative on when to use 'markdown' vs 'json'. Since the rule says low coverage requires compensation, this is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Read'), the specific resource (shared Delx Wellness profile from ~/.delx-wellness/profile.json), and the returned content (preferred name, goals, devices, preferences, safety flags). This clearly distinguishes it from siblings like google_health_profile_update or google_health_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need the user's wellness profile preferences, and clarifies it's read-only. It does not mention alternatives explicitly, but the context is clear enough for an agent to select it over write tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: tokens are stored locally with 0600 permissions and never returned. It also mandates user intent, which is valuable context. No contradiction with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding essential information: purpose and then storage/guard details. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and storage outcome. With an output schema present, return values are covered. Missing handling of invalid codes or token usage context, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (both parameters have descriptions), so the description adds little beyond the schema. It does not enrich semantics for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Exchange' and the resource 'Google OAuth authorization code' for the purpose of obtaining local tokens. It distinguishes itself from siblings like google_health_get_auth_url by specifying the exchange step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the tool is gated and requires explicit user intent, providing a critical usage constraint. However, it does not explicitly mention that it should be used after obtaining an auth code from a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds context about personalized adaptation and step-by-step walkthrough, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple quickstart tool with one trivial parameter and no output schema, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate by explaining the single parameter (response_format). Although the enum values are clear, the description should mention output format options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Personalized 3-step setup walkthrough' that adapts to current state. It distinguishes itself from siblings by being the first call for connecting Google Health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this first when the user asks 'how do I connect Google Health?'' providing clear guidance. Lacks explicit when-not-to-use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: beta status, non-medical use, and missing-data awareness. Read-only is redundantly stated but annotations already cover it, so added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and key content, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, output schema, and parameter schema, the description adequately covers purpose and key features. Missing details about return values are covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 3 of 4 parameters with descriptions; response_format only has enum. The description adds no parameter-specific information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a weekly Google Health scorecard with specific content areas (activity, sleep, heart context, missing-data awareness). The verb 'build' is specific, and 'weekly' distinguishes it from sibling daily tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is clear: this is for weekly reviews, contrasted with daily rollup/summary siblings. However, no explicit when-not or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that it's static metadata and makes no API calls, providing extra context beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with purpose and usage details. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers purpose, usage guidance, and behavioral traits sufficiently for a listing tool. Complete context provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, response_format, is not mentioned in the description. Although its enum values are self-explanatory, the description could clarify its role. Low schema coverage (0%) increases burden, but the parameter is trivial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists canonical data_type slugs with unit, OAuth scope family, and supported endpoint verbs. It distinguishes from siblings by being static metadata and a prerequisite for other data 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call this tool before list_data_points, reconcile_data_points, daily_rollup, or rollup to choose a valid slug. Notes it's static and does not call Google APIs, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive, and the description reinforces this with 'Read-only — does NOT persist anything.' It also discloses cross-connector profile sharing, which is additional behavioral context beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded and concise: purpose, read-only caveat, pairing instruction, and cross-connector context. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters and no output schema, the description covers what is returned, the non-persistence behavior, the pairing with profile_update, and cross-connector sharing. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: locale has a description but response_format lacks any schema or description-level guidance. The description does not mention parameters, failing to compensate for the undocumented response_format semantic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the 11-question onboarding flow plus the current profile state and missing fields, using a specific verb ('Return') and distinct resource. This differentiates it from sibling tools like google_health_profile_get and google_health_profile_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to pair with google_health_profile_update once the user answers, giving a clear usage sequence and naming the relevant alternative. This provides strong when-to-use guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (all false), the description discloses two critical behaviors: it requires explicit_user_intent=true (otherwise returns USER_ACTION_REQUIRED) and rejects secret-like fields at write time. These safety-relevant details are not present in the annotations and significantly aid correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. It front-loads the primary action and immediately follows with the most important constraint (explicit user intent) and a key safety behavior (secret rejection). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, behavioral constraints, and typical use cases. It does not explain return values, but there is no output schema and the tool is a write operation, so this is acceptable. The description is sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the patch object and explicit_user_intent parameter. The description reinforces the requirement for explicit_user_intent and clarifies that the patch is partial, adding practical meaning to the parameter usage. It does not discuss response_format, but the schema provides an enum and default for that, so the description complements rather than repeats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Persist a partial patch to ~/.delx-wellness/profile.json.' It also enumerates the types of content to record (preferred name, goals, devices, etc.), which distinguishes it from sibling read tools like google_health_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Use to record preferred name, goals, devices...'), but does not explicitly state exclusions or alternatives. It is clear enough for an agent to recognize this is the update counterpart to read-only profile tools, but lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, but the description adds crucial context: it deletes the local token file and revokes the OAuth grant. The explicit warning about requiring user intent provides a behavioral guardrail not captured in annotations, making the tool's side effects and authorization requirements 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and immediate consequence. No fluff or repetition of schema/annotation data. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, the description fully covers what is revoked, what is deleted, when it's appropriate, and the necessary user-intent precondition. The output schema handles return values, and the description is complete for an AI agent to safely decide and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters with descriptions, with 'explicit_user_intent' well-documented. The description reinforces the semantic importance of this parameter by linking it to the gating requirement, but does not elaborate on 'response_format' or other parameter details beyond the schema. Slight value added over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific action verbs 'Revoke' and 'delete' with clear resources: the current Google OAuth grant and the local token file. This clearly distinguishes it from sibling tools that deal with data queries, auth URLs, or connection status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('only when the user explicitly wants to disconnect Google Health') and provides a strong when-not ('agents must not call this autonomously'). This is a clear usage gate that prevents misuse, going beyond generic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidmosiah/google-health-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server