Google Health MCP
Server Quality Checklist
Latest release: v0.7.7
- Disambiguation2/5
Multiple tools overlap in purpose: connection_status, privacy_audit, and cache_status all touch local config/cache/token readiness; data_inventory, list_data_types, data_type_coverage, and capabilities all describe supported data types/scopes. The get_profile vs profile_get pair is especially easy to confuse because one is a Google Health profile and the other is a local Delx wellness profile.
Naming Consistency3/5All tools share the google_health_ prefix and use snake_case, but beyond that the pattern is mixed: verb-first names (get_profile, list_data_points, revoke_access) coexist with noun-first names (profile_get, profile_update) and pure noun names (capabilities, quickstart, data_inventory). This is readable but not a consistent verb_noun convention.
Tool Count2/5At 26 tools, the server crosses the threshold where the set becomes heavy. Many tools are narrow status/help/metadata endpoints (cache_status, privacy_audit, capabilities, agent_manifest, quickstart, demo) that could reasonably be consolidated into fewer, broader tools without losing capability.
Completeness4/5The tool surface covers the main lifecycle for this domain: OAuth setup, identity/profile/settings reads, data type discovery, data point listing, reconciliation, rollups, summaries, local profile persistence, and access revocation. Minor gaps exist (e.g., no explicit token-refresh tool, no update for Google Health settings), but they are unlikely to block the core read-only Google Health workflow.
Average 3.8/5 across 26 of 26 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 5 community issues answered or closed in the last 6 months
- 45 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 readOnly, openWorld, idempotent, and non-destructive behavior, so the safety profile is covered. However, the description adds no behavioral context such as pagination behavior, privacy mode effects, or output format defaults, beyond what the schema already states.
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 with no filler. The primary action is front-loaded, and the kebab-case instruction is relevant and immediately actionable.
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?
This tool has seven parameters, a privacy-mode escalation requirement, and pagination support. The description only addresses the data_type parameter format and does not help the agent understand pagination, response format selection, or raw privacy mode semantics, making it incomplete for a tool of this 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?
The schema already documents data_type, privacy_mode, and explicit_user_intent, and the description only repeats kebab-case guidance with examples already present in the schema enum. Parameters like page_size, page_token, and response_format have no description coverage, and the description does not compensate for that gap.
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 specific action ('Query detailed data points') and a specific resource ('Google Health data type'). It does not explicitly compare with sibling tools, but 'detailed data points' distinguishes it from rollup-style 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?
The description gives format guidance for data_type but no explicit guidance on when to use this tool versus siblings like google_health_daily_rollup, google_health_rollup, or google_health_list_data_types. There is no mention of alternatives or exclusions, so the agent must infer usage from the tool name.
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?
The annotations already establish that this is read-only, idempotent, and non-destructive, so the description does not need to cover side effects. It adds the basic aggregation-over-physical-time behavior, which is useful context, but it leaves out pagination, privacy-mode behavior, and windowing semantics that would help the agent understand the call's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence with the core verb front-loaded, which is easy to scan. 'using Google Health rollUp' is slightly redundant given the tool name, but there is no fluff or unnecessary elaboration.
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?
This is a 10-parameter aggregation tool with a rich output schema and many siblings, but the description gives no operational context about privacy_mode=raw, data_source_family, pagination, or how it differs from google_health_daily_rollup. The output schema reduces the need to document return values, but the surrounding behavior is still underdescribed.
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?
With 10 parameters and only 60% schema description coverage, the description should compensate for undocumented parameters such as page_size, page_token, response_format, and data_source_family. The description only vaguely implies data_type and time-interval concepts, adding little meaning beyond what the input schema already documents.
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 action ('Aggregate') and resource ('a data type over physical time intervals'), which gives the agent a clear sense of what the tool does. The phrase 'physical time intervals' helps distinguish it from daily-rollup siblings, though it does not name an alternative explicitly. It is not a tautology: it adds the concept of aggregation over physical time beyond the title.
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?
There is no guidance on when to use this tool versus google_health_daily_rollup, google_health_list_data_points, or the summary tools. The description implies a use case but gives no exclusions, prerequisites, or alternative routing, leaving the agent to infer when this is the right choice.
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, openWorldHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a small behavioral detail that aggregation happens over 'civil days' using Google Health dailyRollUp, but it does not describe pagination behavior, date-range semantics, or privacy/redaction behavior beyond what the schema exposes.
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 that front-loads the core purpose and then gives concrete use-case examples. No words are wasted, and it is appropriately sized for the level of detail it intends to convey.
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?
For a tool with 10 parameters, output schema, and a large sibling family, one sentence is insufficient. The description omits how start_date/end_date relate to civil-day windows, the role of window_size_days and page_size, the privacy_mode/raw behavior, and when to choose this over google_health_rollup or google_health_daily_summary. Although annotations and schema carry some of the burden, the overall context for correct invocation is incomplete.
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 only 50%, with start_date, page_token, window_size_days, data_source_family, and explicit_user_intent lacking descriptions. The tool description does not compensate for these gaps: it only lists example data types, which are already enumerated in the data_type schema. An agent would not learn the meaning of window_size_days, page_token, or the date semantics from either the description or those parameter schemas.
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 operation ('Aggregate a data type over civil days') and identifies the resource and use cases ('steps, distance, calories, active minutes, weight and heart summaries'). It does not explicitly differentiate from close siblings like google_health_rollup or google_health_daily_summary, but the dailyRollUp reference makes the intent reasonably distinct.
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 phrase 'Useful for steps, distance, calories, active minutes, weight and heart summaries' implies common use cases but provides no explicit guidance on when to prefer this tool over google_health_rollup, google_health_daily_summary, or google_health_list_data_points. There are no exclusion criteria or alternative tool mentions, so usage guidance remains inferred rather than 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 'Explain' wording is consistent with those. The description adds context about privacy boundaries and beta status, but these are subject-matter details rather than additional behavioral disclosures like auth requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the core action and then enumerating the specific facets covered. Every word earns its place.
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 adequately summarizes the tool's content areas and the annotations cover its safety profile, while an output schema exists for return values. However, it lacks guidance for distinguishing this overview tool from closely related siblings and does not mention the response_format parameter, leaving some selection ambiguity.
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 only parameter, response_format, is self-documenting through its enum ('markdown'/'json') and default value, so the schema carries the essential meaning even though prose descriptions are absent. The description does not mention the parameter, but for this trivial optional parameter the omission is acceptable.
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 a specific verb, 'Explain,' and names the resource: supported Google Health data, privacy boundaries, beta status, and recommended agent workflow. This clearly states the tool's scope and differentiates it from more specific sibling tools like data_inventory, privacy_audit, and quickstart.
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 does not explicitly say when to use this tool versus alternatives such as google_health_data_inventory, google_health_privacy_audit, or google_health_quickstart. The phrase 'recommended agent workflow' only implies an orientation use case, but there is no direct when-to-use or when-not-to-use guidance.
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 mark this as read-only, open-world, idempotent, and non-destructive; the description's 'Read' is consistent with those attributes. It adds the notion of a reconciled stream across sources, but does not disclose behavior like pagination, privacy-mode effects, or how reconciliation differs from raw listing. With annotations covering the safety profile, this is acceptable 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?
The description is exceptionally concise: two sentences, front-loaded with the core verb and object, followed by the supported source families. There is no filler or repetition.
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 core purpose is clear, and the presence of an output schema reduces the need to explain return values. However, for a tool with 8 parameters, the description does not clarify selection versus list_data_points/rollup, and several parameters remain semantically under-specified. It is adequate but not fully complete for an agent encountering this tool in a large sibling set.
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 exactly 50%, so the description is expected to compensate for undocumented parameters. It partially does by listing the three data source family values in prose, but it adds nothing about page_size, page_token, response_format, or default privacy behavior. The description provides marginal value over the schema but does not fill the coverage gap completely.
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 a specific action ('Read') and a specific resource ('a reconciled stream for one data type across sources'), which is not a tautology of the title. It also lists the supported data source families, adding concrete scope. However, it does not explicitly differentiate itself from siblings like google_health_list_data_points or google_health_rollup.
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 google_health_list_data_points, google_health_rollup, or any exclusion criteria, leaving the agent to infer selection without support.
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 cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), lowering the burden on the description. The description adds that output is normalized into a shared shape, but does not disclose how missing data is handled, whether Google Health authentication is involved, or what happens for empty inputs. There is no annotation 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?
The description is a single focused sentence with no filler. It front-loads the action, the source data, and the normalization target, making it easy to scan and understand.
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 presence of an output schema and strong annotations covers return-shape and safety details that the description would otherwise need to state. However, the one-line description leaves ambiguity about how the normalization works, what inputs are meaningful, and how this tool relates to the many sibling Google Health tools. It is minimally adequate but not fully self-sufficient.
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?
Only 33% of parameters (days and timezone) have schema descriptions, and the tool description does not mention any of the six parameters. It fails to compensate for undocumented parameters like notes, soreness, injury_flags, and response_format, leaving their intended semantics largely to inference from names and default values.
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 a specific verb ('Normalize') and names both the input resource ('Google Health activity/sleep context') and the output target ('shared wellness_context shape'). It is distinct from sibling retrieval/summary tools because it describes a transformation, though it does not explicitly name or differentiate itself from alternatives.
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 phrase 'for recommendation engines' gives an implied use context, but the description does not explain when to choose this tool over related siblings like google_health_rollup, google_health_daily_summary, or google_health_data_inventory. No exclusions, prerequisites, or alternative routing guidance is provided.
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 annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond the annotations: the tool is beta, non-medical, and dependent on reconciled streams being available. This is meaningful but does not cover failure modes or pagination behavior.
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 exceptionally concise: the first sentence front-loads the purpose and data sources, and the second packs the read-only, beta, and non-medical caveats into a short fragment. No words are wasted.
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 that an output schema exists, the parameter schema covers the optional arguments reasonably well, and annotations communicate safety, the description provides sufficient invocation context. It could be more complete by naming when to prefer this over sibling summary/rollup tools, but that gap is mostly a usage-guidance issue.
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 only 33%, and the description does not explain `date`, `timezone`, or `response_format` at all; it fails to compensate for the low schema coverage. The schema itself provides some constraints and defaults, but the description adds no parameter-level meaning.
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 clear verb-resource pair—'Build a practical daily summary'—and identifies the data sources ('Google Health rollups and reconciled streams'). This distinguishes it somewhat from raw rollup tools, though it does not explicitly contrast it with google_health_daily_rollup or google_health_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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings such as google_health_daily_rollup or google_health_weekly_summary. The phrase 'when available' refers to data availability, not tool-selection context, so an agent gets no routing help.
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 the tool is read-only, idempotent, and non-destructive. The description adds meaningful safety-relevant behavior beyond annotations: it does not call Google Health and does not expose secrets. This is useful context for an agent deciding whether invoking the tool is safe.
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 with no filler. Both clauses earn their place: one defines the resource, the other clarifies important boundaries regarding external calls and secrets.
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?
This is a low-complexity tool with two optional enum parameters, an existing output schema, and strong safety annotations. The description adequately conveys the tool's purpose and its non-action boundaries. It does not detail output structure, but that is covered by the output schema.
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 explain either parameter. The client and response_format enums are fairly self-explanatory from their names and allowed values, but the description fails to compensate for the complete lack of schema-level descriptions.
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 the tool provides 'machine-readable install, runtime and client guidance for AI agents,' identifying a clear resource and purpose. It also distinguishes itself by explicitly noting it does not call Google Health or expose secrets, though it does not name specific 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'install, runtime and client guidance' implies the tool is meant for agent setup and configuration, but there is no explicit when-to-use guidance or comparison to alternatives like google_health_quickstart or google_health_onboarding. The intended usage must be inferred rather than stated.
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond that: live mode returns only redacted status and point-count buckets, and never raw health payloads. This is valuable privacy-relevant disclosure that an agent would not otherwise know.
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 sentences with no wasted words. The primary action is front-loaded, the live mode is introduced as an explicit alternative, and the redaction guarantee earns its place as crucial behavioral context. Every sentence adds distinct value.
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 5 optional parameters and an output schema, the description covers the core purpose, the two execution modes, and the privacy behavior of live mode. It notes the OAuth prerequisite, and the output schema can handle return-value details. It does not define what a 'coverage plan' contains or how data_source_family affects it, but those gaps are partially covered by schema enums and defaults.
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 only 40%, so the description needs to compensate for undocumented parameters like date, response_format, and data_source_family. The description does not explain any of these; it only alludes to live mode, which the schema's live parameter description already covers more fully. The rich data_types slug list lives in the schema, not the description, so the description adds little parameter-level meaning.
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 action: building a data-type coverage plan from the official Google Health API table or running live read-only checks. It distinguishes itself from sibling tools like google_health_list_data_types and google_health_data_inventory by focusing on 'coverage plan' rather than listing or inventorying data. It does not explicitly name a sibling alternative, so it stops 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use context: build a plan from the official table, or run explicit live checks against a real OAuth account. However, it does not explicitly say when to prefer this tool over related siblings such as google_health_data_inventory or google_health_rollup, nor does it state exclusions. The mode guidance is useful but the comparison to alternatives is missing.
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=false, so the safety profile is well covered. The description adds the identity-mapping scope and migration context, but no further behavioral details such as output shape or privacy-mode effects beyond what the schema provides.
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 tight sentences with no filler. The primary action is front-loaded, and the migration-use context is stated efficiently.
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 strong annotations, an output schema, and zero required parameters, the description is largely sufficient. It could be slightly more complete by mentioning the optional parameters or clarifying the distinction from profile-related tools, but nothing essential is missing for basic 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?
The tool description provides no parameter-level meaning. Schema coverage is only 67%, leaving response_format undocumented in the schema, and the description does not fill that gap or clarify how privacy_mode or explicit_user_intent affect the call.
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 verb 'Get' and the specific resource 'Google Health identity mapping for the authenticated user.' This distinguishes it from profile/settings tools, though it does not explicitly name a sibling or contrast itself with a close alternative.
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?
It provides a concrete use context: 'Useful for Fitbit-to-Google migrations.' However, it does not state when not to use this tool, nor does it name alternative sibling tools that might be more appropriate.
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 establish read-only, idempotent, and non-destructive behavior. The description adds the auth scope requirement, which is genuinely useful beyond annotations. It does not disclose other behavioral details such as redaction or privacy-mode effects, but the output schema and parameter descriptions partially cover those, so the added value lands at an adequate, not exceptional, level.
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 with no redundancy. The core purpose is front-loaded and the scope prerequisite is told in one additional sentence. 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?
Given the low complexity (zero required parameters, no nested objects), rich annotations, and presence of an output schema, the description is mostly sufficient. The main gap is the lack of sibling differentiation, especially against google_health_profile_get, but nothing critical about invoking the tool is missing.
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 description adds no parameter-level detail; the schema provides descriptions for privacy_mode and explicit_user_intent, and response_format has a default and enum. With schema coverage around 67%, the description does not compensate for the half-documented response_format parameter, but the enum values are largely self-explanatory, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('authenticated user profile details'), and the source ('Google Health'), so an agent can infer the tool's basic purpose. However, it does not distinguish this from the nearly identically named sibling 'google_health_profile_get', so it stops short of full sibling differentiation.
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 'Requires profile scope' note provides a useful prerequisite and implies this is the tool for retrieving the authenticated user's profile. There is no explicit guidance about when to prefer this over alternatives such as google_health_profile_get, google_health_get_identity, or google_health_get_settings, leaving selection among siblings to inference.
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 mark it read-only, idempotent, and non-destructive. The description adds useful behavioral context: the local file path, the exact content categories returned, and a strong guarantee that it NEVER contains OAuth tokens or API secrets. 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?
Three short sentences, with the action and path front-loaded, the return contents summarized in one list, and a decisive safety warning. Every sentence carries useful information; no filler.
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 one-optional-parameter read tool with no output schema, the description covers what is read, where it lives, what it returns, and what it never contains. It does not address missing-file behavior or explain how response_format changes output, but the schema covers the parameter and these are minor gaps.
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 only parameter, response_format, is optional and fully constrained by its enum and default in the schema, so the agent can interpret it without help. However, description-level schema coverage is 0% and the description itself says nothing about response_format, so no additional parameter meaning is contributed.
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 clear verb and resource ('Read the shared Delx Wellness profile from ~/.delx-wellness/profile.json') and lists the returned fields. It does not explicitly distinguish itself from the similarly named sibling google_health_get_profile, so it misses the strict sibling-differentiation bar for 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call it when you need the Delx profile contents, and the warning that it never contains OAuth tokens suggests when not to use it for secrets. However, it provides no explicit when-to-use/when-not-to-use guidance and does not mention alternatives like google_health_get_profile or google_health_profile_update.
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 signal readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond those: the cache is optional and local SQLite, and it names the environment variables that turn it on. It does not detail the exact status fields, but the output schema exists and the read-only safety profile is well covered by 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 short sentences contain all the core information: what the tool shows and how the optional cache is enabled. There is no fluff, and the primary function is front-loaded. 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?
For a simple read-only status tool, the description plus rich annotations and an output schema is largely sufficient. The main missing piece is explicit routing among the many sibling health-status tools, but that gap is mostly captured under usage guidelines rather than contextual completeness.
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 description does not mention response_format, and schema description coverage is 0%. However, the input schema fully documents the only parameter through its enum (markdown/json) and default value (markdown), making the parameter's meaning self-sufficient. The description misses a chance to compensate for the lack of schema descriptions, but the agent will not be confused about how to invoke the tool.
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 opens with a specific verb and resource: 'Show optional local SQLite cache status.' The term 'cache status' clearly distinguishes it from siblings like google_health_connection_status, google_health_data_inventory, and google_health_capabilities. An agent can tell exactly what this tool does without guessing.
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 useful enablement context: 'Enable with GOOGLE_HEALTH_CACHE=sqlite or GOOGLE_HEALTH_CACHE=true.' However, it never explicitly states when to use this tool versus alternatives, nor does it name any sibling as a better choice for other kinds of status checks. Usage is implied but not explicit.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully cover the safety profile. The description adds no additional behavioral detail, but it also does not contradict the annotations, so a baseline score is appropriate.
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 no wasted words. The core purpose is front-loaded, and the usage condition is stated immediately after, making the description easy to parse and act on.
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 zero-required-parameter tool with an output schema and safety annotations, the description is nearly complete: it states what the tool does and when to call it. It could optionally mention the next step of exchanging the code, but that is inferable from the sibling tool list.
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 state and scopes already documented in the schema and response_format having an enum and default. The description does not add parameter-level meaning, but the schema carries most of the semantic weight. This is adequate but not enhanced.
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 specific resource: a Google OAuth authorization URL for the Google Health API. This distinguishes it from sibling tools like google_health_exchange_code or google_health_connection_status, which handle different steps.
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 to use this tool first when no local token exists, providing a clear condition and ordering. It does not explicitly name alternatives or when-not-to-use scenarios, but the condition is specific enough for an agent to route correctly.
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, idempotentHint, and non-destructive behavior. The description adds meaningful context by requiring a specific settings scope and specifying that these are settings for the authenticated user, which goes beyond what annotations alone communicate.
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 short sentences deliver the core purpose and the key prerequisite with no filler. The most important information is front-loaded and 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?
For a simple read-only settings getter with an output schema and safety annotations, the description is nearly complete: it names the resource, gives examples, and states the required scope. It does not discuss the optional privacy/format parameters, but the input schema documents those adequately.
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%, and the description adds little parameter-specific meaning: it never mentions privacy_mode, response_format, or explicit_user_intent. However, the schema itself documents two parameters well and the third is self-explanatory from its enum and default, so the description does not need to compensate heavily.
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 states a specific verb and resource: 'Get authenticated user settings' and gives concrete examples ('units and timezone'). This clearly differentiates it from sibling tools like identity/profile/status tools, even without naming them.
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 gives useful context ('authenticated user settings') and a prerequisite ('Requires settings scope'), but does not explicitly state when to use this tool versus any alternative. Usage guidance is implied rather than explicit.
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 read-only, idempotent, and non-destructive behavior. The description adds a meaningful behavioral guarantee: it returns posture without revealing secret values, and it enumerates the inspected scopes (privacy, cache, token-path, env-presence), which goes 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?
The description is a single sentence with no filler. It front-loads the primary action and result, then adds the critical safety qualifier, making it both concise and well-structured.
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?
With an output schema present, read-only/idempotent annotations, and only one optional self-documenting parameter, the description provides enough for an agent to invoke the tool correctly. The main missing piece, explicit sibling differentiation, is a usage-guideline concern rather than a completeness gap for calling the 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?
Schema description coverage is 0%, and the description does not mention the response_format parameter at all. The parameter is optional and well-constrained by the enum and default (markdown/json), so the omission is not severe, but the description still adds no semantic value for the 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 names a specific verb ('Return'), resource ('local privacy, cache, token-path and env-presence posture'), and an explicit constraint ('without revealing secret values'). This makes its purpose immediately clear and distinguishes it from sibling health/status tools as a privacy audit rather than a connectivity or rollup tool.
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 clearly implies use when a local privacy/cache/token-path audit is needed, but it does not explicitly state when to prefer this tool over the many sibling google_health tools. No exclusions, prerequisites, or alternative tool names are mentioned, so selection guidance is left to inference.
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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds valuable context beyond those: beta status, non-medical scope, and missing-data awareness. These disclose important behavioral traits 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that starts with the primary action and resource, then adds content scope and caveats. Every clause earns its place, with no repetition of schema details or padding.
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 moderately simple, has an output schema, and its annotations already cover the safety profile. The description supplies scope, content, and important caveats. The main gap is the lack of explicit sibling routing, but that is more of a usage-guideline shortcoming than a completeness failure.
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 description does not discuss parameters, but the schema provides descriptions for days, timezone, and compare_days. The only undocumented parameter, response_format, is self-explanatory through its enum values and default. With 75% schema coverage, the description is not required to compensate heavily.
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?
States a specific action and resource: 'Build a weekly Google Health scorecard' with explicit content areas (activity, sleep, heart context, missing-data awareness). The word 'weekly' plus 'scorecard' clearly differentiates it from sibling tools like google_health_daily_summary and google_health_rollup.
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?
Provides useful usage context such as 'Read-only, beta, non-medical', but does not explicitly name alternatives or conditions like 'use daily_summary for day-level details'. The intended usage is implied rather than stated, so an agent must infer when this tool is preferable to its many 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 readOnly, idempotent, and non-destructive hints. The description adds meaningful behavioral context beyond those annotations by promising no Google API calls and no secret exposure, and by listing exactly what is inspected, which is valuable for an agent deciding whether invocation is safe.
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 one dense, well-structured sentence with the action verb, targets, and constraints. It front-loads the purpose and includes all essential scope information without any filler or repetition.
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 status tool with an output schema and rich annotations, the description covers purpose, offline behavior, and privacy constraints effectively. The main gap is that parameter semantics are left to inference, but the tool remains callable and understandable for an 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 explicitly explain either parameter. 'Optional MCP client readiness' only indirectly hints at the client parameter, and response_format is not mentioned at all. The parameter names and enums provide some self-evident meaning, but the description fails to add semantic value 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?
Description opens with the imperative 'Check' and names precise local resources: Google Health config, token file, Node version, privacy mode, cache readiness, and optional MCP client readiness. It also clearly scopes the tool as local-only by stating it does not call Google APIs or expose secrets, distinguishing it from API-facing siblings.
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 use case: local, offline diagnostics of connection state. The explicit 'without calling Google APIs' gives an agent a strong signal to prefer this tool for local checks rather than remote data-access tools, though it does not explicitly name alternatives or when-not-to-use conditions.
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 the important behavioral detail that it works 'without calling Google APIs', meaning it has no external side effects and is purely informational. This goes beyond the annotations and helps an agent understand the tool's operational profile.
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, tight sentence that front-loads the primary purpose ('Inventory supported Google Health data types') and then appends the additional included categories and the no-API-call qualifier. Every word earns its place; there is no filler or 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?
The tool has zero required parameters, an output schema, and annotations covering its read-only/idempotent behavior. The description adds the crucial offline nature and enumerates the inventory categories. Nothing essential is missing for a tool of this simplicity.
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 only parameter, response_format, is clearly structured with an enum of 'markdown' and 'json' plus a default, so its meaning is essentially self-evident. However, the schema description coverage is 0% and the tool description does not mention this parameter at all. The description adds no semantic value beyond the schema, though the parameter is simple enough that this is a minor 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 uses a specific verb ('Inventory') and clearly names the resource scope: supported Google Health data types, auth scopes, privacy modes, and recommended first calls. It also distinguishes itself from live API calls by adding 'without calling Google APIs', which separates it from siblings like google_health_list_data_types that may make actual API requests.
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 when to use the tool—when you need an offline inventory of data types, scopes, privacy modes, and first calls—but it does not explicitly state when to choose this over alternatives or name sibling tools. There is no exclusion guidance (e.g., 'use list_data_types when you need only data types'), leaving the agent to infer the routing decision.
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, idempotent, and non-destructive behavior, so the description only needs to add context beyond that. It does so by clarifying that the tool returns synthetic 'example payloads' rather than real data, and it labels them as 'Pixel-Watch-style' to frame their realistic-but-demo 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?
The description is a single dense sentence that front-loads the operation, names the exact payload types, and gives the purpose with zero filler. Each clause adds necessary information, making it highly efficient.
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 provides a clear high-level picture of what the tool returns and why, which is especially valuable given there is no output schema. It doesn't enumerate the payload structures or mention response format details, but for a read-only demo tool with safety annotations, this level of completeness is 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%, and the description adds no guidance about the `response_format` parameter, even though it is the only parameter and controls markdown vs JSON output. The parameter is optional and self-explanatory, but the description still fails to compensate for the schema's lack of semantic detail.
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 states a specific verb ('Returns') and resource ('realistic Pixel-Watch-style example payloads') and names the three tools whose contracts it demonstrates. The stated purpose, 'so agents see the contract before calling real Google Health APIs', clearly differentiates this demo tool from the many API-calling siblings.
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 signals when to use it: before calling real Google Health APIs, framing it as a contract-preview/demo tool. It does not spell out exclusions or name alternatives directly, but the intended use is unambiguous given the sibling list and the phrase 'before calling real Google Health APIs'.
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 mark the tool readOnly, idempotent, and non-destructive; the description reinforces that with 'does NOT persist anything' and adds the cross-connector profile-sharing behavior. This extra state-model context helps the agent reason about data consistency, with no contradiction of 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?
Three sentences, front-loaded with the return value and zero filler. The connector list in the final sentence is long but earned, because it communicates a key cross-connector behavior.
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 zero-required-param read tool with no output schema, the description supplies the essential return content, non-persistence guarantee, and the follow-up update tool. It is complete enough to call, though a bit more detail on response_format behavior would round it out.
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 locale or response_format at all, and schema coverage is only 50% (response_format has no schema description). The enum values are self-explanatory, but the tool description adds no guidance about defaults or how these params shape the output, so it fails to compensate for the coverage 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 opens with a concrete verb ('Return') and a precise resource: 'the 11-question onboarding flow plus the current profile state and missing fields.' This clearly distinguishes it from read siblings like google_health_get_profile (which lacks the onboarding flow) and from the write sibling 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Pair with google_health_profile_update once the user answers' gives an explicit sequencing rule that routes the agent to the correct sibling after this call. It does not, however, spell out when to prefer this over profile_get/get_profile or state exclusions, so it stops short of full when/when-not coverage.
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 establish read-only, idempotent, non-destructive behavior. The description adds beyond that by revealing the tool is adaptive ('Adapts to current state') and that it is for the human user, not the agent. These are useful behavioral details not present in 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?
Three short sentences, each adding distinct value: what it is, how it adapts, and when to call it. The most actionable trigger is front-loaded at the end but clearly emphasized. There is 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 simple tool with one optional parameter and no output schema, the description covers the core purpose, adaptive behavior, and call trigger. The only notable gap is the absence of any guidance on the response_format parameter, though the schema's enum and default limit the ambiguity.
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 response_format at all. The schema provides an enum and default, so the parameter is somewhat self-explanatory, but the description adds no extra meaning and does not compensate for the lack of schema descriptions.
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 states a specific verb and resource: 'setup walkthrough for the human user' with a concrete structure ('3-step'). It also provides a trigger phrase, 'Call this first when the user asks 'how do I connect Google Health?'', which clearly differentiates this from sibling tools like get_auth_url 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit when-to-use condition ('Call this first when the user asks...'). However, it does not explicitly name alternatives or state when NOT to use this tool, so it falls just short of the top score.
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?
The description goes well beyond the annotations by disclosing that tokens are stored locally with 0600 permissions, are never returned, and that the operation is gated on explicit user intent. This is valuable behavioral context for a security-sensitive tool.
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 sentences with no filler. The primary purpose is front-loaded, followed by essential behavioral disclosure and a decisive usage constraint. Every sentence earns its place.
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 an OAuth token exchange tool, the description covers the necessary context: what the tool does, where tokens go, what permissions they get, that they are never returned, and that autonomous calls are forbidden. The output schema and parameter schema cover the remaining invocation details.
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 schema already documents the two required parameters, code and code_verifier, and the optional response_format has an enum plus default. The description adds no parameter-specific meaning, but the schema covers the important inputs adequately, so the agent can still invoke the tool correctly.
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-resource pair: 'Exchange a Google OAuth authorization code for local tokens.' This clearly differentiates it from sibling tools like google_health_get_auth_url and makes the tool's role in the OAuth flow unambiguous.
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 states a critical usage restriction: 'requires explicit user intent — agents must not call this autonomously.' It does not name alternative tools, but it gives a clear and strong condition for when the tool must not be used.
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 mark the tool destructive (destructiveHint: true) and non-read-only (readOnlyHint: false), and the description matches by disclosing exactly what is destroyed: the OAuth grant and the local token file. It adds the gating requirement that explicit user intent is necessary, making the irreversible consequences and autonomy restriction clear. 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?
Three short sentences, front-loaded with the action, then the user-intent condition and the autonomy prohibition. Every sentence earns its place; no filler or repetition of schema details.
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 simple two-parameter schema, rich annotations, and an output schema, the description covers what the tool does, what it deletes, and the strict invocation condition. It is complete enough for an agent to decide whether and how to call it, and no return-value documentation is needed.
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 schema covers explicit_user_intent well (must be true, prevents autonomous revocation), and the description echoes that guard, but the description adds no detail about response_format and does not clarify that explicit_user_intent should be treated as effectively mandatory despite the schema listing zero required parameters. At 50% schema coverage, the description only partially compensates, so this is adequate rather than strong.
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 opens with a specific verb ('Revoke'), names the exact resource ('current Google OAuth grant'), and adds the local side effect ('delete the local token file') that separates it from read-only/auth-flow siblings like google_health_get_auth_url or google_health_connection_status. The title reinforces 'Revoke Google Health OAuth Access', so an agent can confidently identify this as the disconnect 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 is explicit about the only allowed trigger: 'Use only when the user explicitly wants to disconnect Google Health.' It also states a hard prohibition: 'agents must not call this autonomously.' It does not name alternative tools for reconnecting or checking status, which prevents a full 5, but the when/when-not guidance is unambiguous.
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 indicate read-only, idempotent, and non-destructive behavior, but the description adds the crucial context that this is 'static metadata; does not call Google APIs.' This tells the agent there are no network side effects, auth requirements, or external state changes, which goes beyond what the annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tightly packed sentences with no filler: it states what the tool lists, when to call it, and the key behavioral caveat. The most important purpose information is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter tool with a simple output schema and detailed annotations, the description is complete. It covers the tool's purpose, its scope, the fields returned, the dependent tools it supports, and its non-network static behavior. There is no meaningful missing context an agent would need to call it correctly.
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 schema description coverage is 0%, so the description does not mention the single response_format parameter. However, the parameter is fully constrained by its enum of 'markdown' and 'json' with a default of 'markdown', making its semantics self-evident without additional description. The description omits it, but the schema itself is sufficient for the agent to invoke the tool correctly.
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 names the exact resource ('canonical kebab-case data_type slugs') and the specific details returned (unit, OAuth scope family, endpoint verb support), making the tool's purpose immediately clear. It also distinguishes itself from the sibling data-related tools by stating it lists accepted slugs rather than fetching data. The verb 'List' plus the precise resource leaves no ambiguity.
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?
The description explicitly instructs when to call this tool: 'before list_data_points, reconcile_data_points, daily_rollup or rollup.' It also explains the intended benefit, 'to choose a valid data_type instead of guessing a slug,' which gives the agent a clear decision rule for using it ahead of dependent tools.
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, the description discloses the write target, the explicit_user_intent gating with USER_ACTION_REQUIRED behavior, and write-time rejection of secret-like fields. This gives the agent the safety-relevant side effects it needs.
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 dense sentences, front-loaded with the core action and then behavioral constraints and use cases. Every sentence carries distinct information with no filler.
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 an open, nested patch tool with no output schema, the description plus schema covers what to write, where it is persisted, the mandatory intent flag, and the fields that are rejected. response_format is self-explanatory from its enum and default, so no further return-value detail is needed.
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?
Schema coverage is 67%, so the schema handles patch and explicit_user_intent. The description adds meaning by enumerating the intended top-level patch keys (profile, goals, devices, training, nutrition, preferences, safety, notes) and recordable domain content, though it does not detail response_format semantics.
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?
States a precise action ('Persist a partial patch') and a concrete resource ('~/.delx-wellness/profile.json'), with domain fields to write. The update action is clearly distinct from the many get/list/auth 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 phrase 'Use to record preferred name, goals, devices, training context...' gives clear when-to-use context. It does not explicitly name alternatives or exclusion conditions, though secrecy rejection and explicit-intent requirement delimit misuse.
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: