Provides read-only access to the Google Health API, enabling retrieval of health metrics such as sleep, heart rate, HRV, SpO₂, steps, and readiness with baselines and anomaly detection.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@google-health-mcp how did I sleep this week?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read-only MCP server for the Google Health API. Give any AI agent — Claude Code, Claude Desktop, Cursor — access to your own Fitbit, Pixel Watch and Health Connect data, and get advice grounded in your baselines instead of generic wellness copy.
Runs locally. Your data and tokens never leave your machine — the only network calls are to Google.
The legacy Fitbit Web API was turned down in September 2026. The Google Health API is its replacement, and this server targets that new API.
The obvious tool surface — get_steps(), get_sleep() — produces bad advice.
Hand an agent 1,440 raw heart-rate points and it says "try to sleep more."
So the composed tools here return your value, your baseline, the delta, and the z-score, plus an explicit confidence level and a list of any missing inputs:
// health_readiness("2026-03-14") — illustrative values
{
"score": 34,
"verdict": "rest",
"guidance": "Rest. Multiple recovery signals are off baseline together.",
"confidence": "medium",
"why": [
"HRV well below your baseline (z=-1.72)",
"resting HR +3.2 bpm over baseline",
"8.7h of sleep debt over the last week"
],
"missing_inputs": ["spo2"],
"signals": {
"hrv": { "value": 23.2, "baseline_mean": 30.73, "baseline_n": 9,
"delta": -7.53, "z_score": -1.72, "status": "well below baseline" }
}
}An agent that can see "HRV 23 ms against your 30-day baseline of 31, on 8.7 h of sleep debt" gives specific, checkable advice. One handed a bare score invents a rationale for it.
Related MCP server: WHOOP MCP
Google Health splits read and write into separate OAuth scopes. This server
requests only .readonly scopes, so the token it holds is incapable of
altering your health record. That is enforced by Google's token checks — not by a
flag in this code that a bug could flip.
Tool | What it gives you |
| Start here. One day — sleep, resting HR, HRV, SpO₂, breathing rate, skin temperature, steps, active zone minutes — each against your trailing baseline |
| Train / hold / rest, with the reasoning, a confidence level, and which inputs were missing |
| Week-over-week means and direction for one metric |
| Only the days where something moved >2 SD from your own norm |
| Daily series for any of the 40 data types |
| Raw / intraday escape hatch, cross-source reconciled |
| Profile, units, timezone, paired devices, battery, last sync |
| Every readable data type, with the wearable-backed ones flagged |
| Token health, and the exact command to fix it |
Then just ask: "how did I sleep this week?", "am I recovered?", "what's been off lately?"
Roughly 15 minutes, $0, and no security review.
Your tracker must be syncing into the Google account you are about to authorize. Open the Fitbit app and confirm it is signed in with that account — otherwise everything below will authorize cleanly and return an empty dataset.
Create or pick a project at console.cloud.google.com.
Enable the API — Google Health API → Enable.
Consent screen — Audience: User type External, publishing status Testing, and add your own Google account under Test users.
Scopes — Data Access → Add or remove scopes → search "Google Health API" → select these six:
.../auth/googlehealth.activity_and_fitness.readonly
.../auth/googlehealth.health_metrics_and_measurements.readonly
.../auth/googlehealth.sleep.readonly
.../auth/googlehealth.nutrition.readonly
.../auth/googlehealth.profile.readonly
.../auth/googlehealth.settings.readonlyCredentials — Credentials → Create credentials → OAuth client ID → type Web application → add this authorized redirect URI exactly:
http://localhost:8787/oauth/callbackCopy the client ID and secret.
Why Testing mode? Every Google Health scope is Restricted. Publishing an app that uses them requires an annual CASA security assessment — $500–$4,500 and 2–6 weeks. Testing mode skips all of it, supports up to 100 users, and costs nothing. The trade-off is that refresh tokens lapse periodically and you re-run one command.
git clone https://github.com/kirollosatef/google-health-mcp.git
cd google-health-mcp
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e .
cp .env.example .env # Windows: copy .env.example .envPut your client ID and secret in .env.
python scripts/authorize.py # or: google-health-authorizeA browser opens. Google will warn "Google hasn't verified this app" — expected in Testing mode, not an error. Choose Advanced → Go to (your app) and approve. The script captures the callback, stores an encrypted refresh token, and makes a live call to prove the chain works, printing your paired devices.
python scripts/mcp_config.py > .mcp.jsonThat writes a config with the paths on your machine already resolved. Claude Code
picks up .mcp.json when started from this directory; for Claude Desktop or
Cursor, merge the printed block into that app's MCP config.
python tests/test_smoke.py # 51 offline checks, no network or credentialssrc/google_health_mcp/
config.py settings, scopes, endpoints
auth.py OAuth flow, encrypted token store, auto-refresh
client.py REST client + polymorphic data-point parsing
datatypes.py 40 data types: filter fields, value paths, units
analytics.py baselines, z-scores, sleep debt, readiness (pure, no I/O)
server.py MCP tool surface
cli.py authorize / config entry pointsanalytics.py and the parsing in client.py are pure functions with no network
or auth dependency, so they lift unchanged into a Worker or Lambda if you later
want webhook subscriptions (projects.subscribers.subscriptions) or phone access.
Building this against the live API turned up five errors in Google's reference, each of which returns a 400 or silently produces wrong numbers. They are written up in docs/API-CORRECTIONS.md — worth reading before you write any Google Health code of your own:
range.start is a CivilDateTime, not a Date — the reference's own example is rejected.
Numeric fields arrive as JSON strings ("8432"), so naive parsers drop nearly every value.
Filter fields must be prefixed with the data type, with a different suffix per family. The full grammar exists only in the discovery document.
dailyRollUp does not support the daily data types (sleep, resting HR, HRV, SpO₂).
pageSize on rollups is a duration cap, not a row cap.
Plus units that are easy to get 1000× wrong: weight is in grams, distance in millimetres.
docs/discovery.json is the authoritative schema; refresh it with
python scripts/fetch_discovery.py.
Re-authorization. Refresh tokens lapse periodically in Testing mode. Tools
then return not_authorized with the fix; re-run scripts/authorize.py.
Baselines need history. Under 3 prior days yields no_baseline_yet. The
default window is 30 days, set by HEALTH_BASELINE_DAYS.
SpO₂ can be empty for a while after setup; it is reported under
missing_inputs rather than invented.
Polling, not webhooks. Subscriptions need a public HTTPS endpoint.
Data availability varies by device — a screenless tracker has no GPS, and some models have no ECG.
Tokens are encrypted at rest under your OS user directory, never in the repo. Health data is fetched on demand and never written to disk. See SECURITY.md.
This reads consumer wearable data with consumer-grade accuracy and applies simple statistics to it. Readiness scoring is a prompt for a conversation, not a clinical instrument, and every output carries a disclaimer. Persistent or severe changes are a reason to see a clinician, not to ask an agent.
Issues and PRs welcome — see CONTRIBUTING.md. Especially useful: data types this does not parse well yet, and devices whose payloads differ from what is assumed here.
MIT — see LICENSE.
Scan recent days for metrics that moved more than threshold standard
deviations from your own trailing baseline.
Surfaces the handful of days worth talking about instead of a wall of numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| threshold | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=true, so the description carries the behavioral disclosure burden. It reveals that the tool computes a trailing baseline, uses standard deviations as the anomaly criterion, and surfaces only noteworthy days. This adds substantive context beyond the annotations, though it does not address edge cases like insufficient data or empty anomaly sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that front-load the purpose and immediately give the anomaly-detection algorithm, followed by a concise value statement. There is no redundant material; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering read-only safety, the description covers the core algorithm and output behavior. It doesn't mention what happens with insufficient data or how many results are returned, but those details are likely captured in the output schema, so the description is adequate for such a focused analytic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does explain `threshold` as the number of standard deviations from baseline. However, `days` is only indirectly referenced as 'recent days,' so the agent must infer that the `days` parameter controls the scan window; no ranges, units, or further semantics are given. Defaults are present in the schema, so that part doesn't need to be repeated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Scan recent days for metrics that moved more than `threshold` standard deviations from your own trailing baseline.' It defines the detection criterion precisely, distinguishing it from generic trend or daily-data siblings. The final sentence 'Surfaces the handful of days worth talking about instead of a wall of numbers' clearly differentiates it from raw list/trend tools by emphasizing anomaly summarization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case—finding notable anomalies rather than viewing a full dataset—via 'instead of a wall of numbers,' but it never explicitly names sibling tools or states when to choose this over health_trend, health_daily, etc. There is no direct when-to-use/when-not-to-use guidance or exclusion criteria, leaving the routing decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the server holds valid Google Health credentials.
Call this first if any other tool returns a not_authorized error.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the error-recovery context but does not disclose other behavioral details such as cache behavior or credential refresh semantics. It is consistent with annotations and provides some useful context, earning a baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The primary purpose is stated first, followed immediately by the key usage directive. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only status check with an output schema present, the description fully equips an agent: it knows what the tool does and exactly when to call it. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is vacuously 100%. The description adds no parameter-level meaning, which is fine because there are none to document; per the baseline for 0 parameters, this scores a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Check'), resource ('server holds valid Google Health credentials'), and outcome. It clearly distinguishes this tool from the health_data_types, health_profile, and other data-retrieval siblings by focusing on authentication state rather than health data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this first if any other tool returns a not_authorized error.' This provides a concrete trigger condition and sequencing directive, leaving no ambiguity about when to invoke this tool instead of its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily aggregate for one data type over a date range (YYYY-MM-DD, inclusive).
Uses civil-day rollups, so days align to your local calendar rather than UTC.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| data_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds meaningful behavioral context beyond that by explaining that days use civil-day rollups and align to the local calendar rather than UTC, and that the date range is inclusive. This helps the agent understand timezone behavior without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core purpose is front-loaded, and the second sentence adds a distinct behavioral detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a read-only aggregate query, and an output schema exists so return value details are not required. However, given the many sibling tools and the undocumented data_type parameter, a slightly richer description would be needed for fully confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter semantics. It explains start and end as a YYYY-MM-DD inclusive range, which is useful, but it leaves data_type entirely undocumented and gives no examples or valid values. This is only partial compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as producing a daily aggregate for one data type over a date range. It is specific about the resource and scope, though it does not explicitly differentiate itself from siblings like health_daily_brief or health_trend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a daily aggregate for a single data type over a date range is needed. However, it provides no explicit guidance about when not to use it or which sibling tool would be a better alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call snapshot of a single day: sleep, resting HR, HRV, SpO2, breathing rate, skin temperature, steps and active zone minutes, each compared against your own trailing baseline.
This is the right first call for "how am I doing today". Defaults to today.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the tool returns a baseline comparison and defaults to today. This is genuine added context rather than a repeat of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The core capability is front-loaded, the baseline-comparison behavior is stated compactly, and the usage guidance follows naturally. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description covers the main behavioral details: what data is returned, how it is compared, the default date, and when to use it. It omits the exact date string format, but the output schema and type annotation make the tool safely callable. Complete enough for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden of explaining the single 'date' parameter. It does add value by stating 'Defaults to today' and implying the parameter selects the day, but it does not specify the accepted date format. This is partial compensation, not full coverage, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'One-call snapshot of a single day' and enumerates the specific metrics included (sleep, resting HR, HRV, etc.), making the resource and action unambiguous. It also adds the distinguishing trait 'each compared against your own trailing baseline'. However, it does not explicitly differentiate itself from the sibling health_daily, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'This is the right first call for "how am I doing today"' and 'Defaults to today'. This tells the agent when to prefer this tool, but it does not name alternatives or state when not to use it, so it lacks the explicit when/when-not structure of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every readable data type, with the ones a Fitbit Air produces flagged.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, and the description consistently describes a read-only listing operation. It adds useful behavioral context beyond the annotation by stating that every readable type is returned and that Fitbit Air-produced types are flagged, which shapes expectations without contradicting the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase adds value: the action, the scope, and the Fitbit Air classification flag.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only catalog tool with an output schema present, the description is sufficient. An agent knows exactly why to call it and what result to expect, and no invocation-time details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is effectively complete, so there is no parameter burden for the description to carry. Per the baseline for zero-parameter tools, a 4 is appropriate; there is nothing meaningful left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('every readable data type') and adds a distinguishing qualifier about Fitbit Air production flags. This makes it easy to tell apart from sibling health-data tools even without inspecting their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when an inventory of available data types is needed, and the openWorldHint annotation supports exploration. It does not explicitly name alternatives or exclusion conditions, but the sibling tools are clearly data-value tools rather than catalogs, so the intended context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read raw data points for one data type over a date range (YYYY-MM-DD, inclusive).
reconcile=True returns Google's merged cross-source stream (tracker + phone + manual entries deduplicated), which is almost always what you want.
This is the low-level escape hatch. For daily questions prefer health_daily or health_daily_brief - a single day of heart-rate can be 1440 points.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| data_type | Yes | ||
| page_size | No | ||
| reconcile | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description reinforces this with 'Read raw data points.' It adds valuable behavioral context beyond annotations: the cross-source reconcile behavior, deduplication, and the high-volume warning that motivates pagination awareness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then layered with the reconcile detail and the low-level guidance. Every sentence earns its place, though the three-paragraph split could be tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of low-level raw data retrieval, the description covers the most critical behavioral aspects: inclusivity of dates, reconcile semantics, and scale warning. It leaves data_type vocabulary to sibling tools like health_data_types, which is reasonable, and an output schema exists to describe returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter meaning. It does explain reconcile=True and the date format (YYYY-MM-DD, inclusive), but it does not explain data_type values, page_size behavior, or how paging works. The partial coverage makes it adequate but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair — 'Read raw data points' — and explicitly frames itself as 'the low-level escape hatch' versus daily-aggregated tools. This clearly separates it from siblings like health_daily and health_daily_brief.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent exactly when to prefer alternatives: 'For daily questions prefer health_daily or health_daily_brief' and warns that a single day of heart-rate can be 1440 points. It also explains when reconcile=True is appropriate ('almost always what you want'), leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Health profile, unit/timezone settings, and paired devices with sync state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the description carries a lower burden. It adds context by specifying the scope of the returned data (profile, unit/timezone settings, paired devices with sync state), which is useful behavioral information. However, it does not mention whether the data reflects the current user, whether units/timezone are editable or just reported, or any additional detail about the sync-state semantics beyond the label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of eleven words conveys the tool's full scope with zero filler. The key components are listed in a natural order: profile, then settings, then devices. There is no redundancy or repetition of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with an output schema and openWorldHint, the description is adequately complete. It tells the agent exactly what area of functionality this tool covers and the presence of an output schema lets the agent inspect the return shape. The description could be improved by explicitly saying 'current user' or noting that this is the baseline profile view distinct from health data summaries, but nothing critical is missing for safe invocability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so there are zero parameters to document. Per the baseline rule for 0-param tools, the description need not compensate for any schema gaps. The description appropriately matches the empty schema and adds no unnecessary parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (Google Health profile) and enumerates its content: unit/timezone settings and paired devices with sync state. This distinguishes it from sibling tools like health_daily, health_trend, and health_readiness, which focus on data and analytics rather than profile configuration. The only gap is the lack of an explicit action verb like 'get' or 'retrieve', but the resource is so specific that intent is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. It does not state e.g. 'use this to check the current user's profile settings' or 'for daily metrics use health_daily instead'. Given eight sibling tools covering related health data, the absence of any routing or exclusion guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recovery readiness for a day: HRV, resting HR, breathing rate and SpO2 each scored against your personal baseline, plus rolling sleep debt, combined into a train / hold / rest call with the reasoning shown.
Returns confidence and missing_inputs so you can tell a real signal from thin data. Informational only, not a medical assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description's 'Informational only' reinforces that. It adds meaningful behavior beyond the annotations by disclosing that confidence and missing_inputs are returned, that reasoning is shown, and that the result is not a medical assessment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written and front-loaded with the core purpose, followed by what is returned and the key safety caveat. Every sentence adds useful information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and read-only annotations, the description covers the main inputs, outputs, and important limitations such as the non-medical disclaimer. It is complete enough for an agent to invoke correctly, though explicit date formatting and sibling-tool routing would make it fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional date parameter with zero description coverage. The description adds that this is a per-day calculation, giving the date parameter meaning, but it does not specify the expected date format or behavior when the date is omitted. It is minimally adequate for a single optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact outcome, a per-day recovery readiness call combining HRV, resting HR, breathing rate, SpO2, and sleep debt into a train/hold/rest recommendation. This clearly distinguishes it from broader sibling tools like health_daily or health_trend by focusing on readiness scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a specific day's readiness and explicitly notes it is informational only and not a medical assessment. However, it does not mention when to prefer this tool over siblings such as health_daily or health_trend, leaving selection partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Week-over-week trend for one metric: weekly means, direction, and the change from the first week to the most recent.
Use this to answer "is my sleep actually getting worse" rather than reacting to a single bad night.
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | No | ||
| data_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, and the description adds what the agent can expect: weekly means, direction, and first-to-most-recent change. It goes beyond the schema by framing output semantics and by implying aggregation over multiple weeks, though it does not address edge cases like insufficient week history.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the definition is front-loaded and the usage guidance is immediately actionable. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple read-only trend tool with an output schema, but it leans on the agent to infer parameter semantics from titles and context. Without schema descriptions or enums, the missing data_type guidance prevents the description from being fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that the tool tracks 'one metric' (data_type) and implies weeks via 'week-over-week' and 'first week to most recent', but it never defines valid data_type values or precisely how the weeks parameter changes the calculation. Partial compensation, but a real gap remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific analytical purpose: computing a week-over-week trend for one metric, including weekly means, direction, and change from first to most recent week. This clearly distinguishes it from the daily, readiness, and anomaly siblings by focusing on trend over time rather than a single snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives an explicit use case: answer 'is my sleep actually getting worse' rather than reacting to a single bad night. It provides clear contextual guidance but does not name sibling alternatives or state when to prefer a different tool for non-trend questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0health_anomalieshealth_auth_statushealth_dailyhealth_daily_briefhealth_data_typeshealth_pointshealth_profilehealth_readinesshealth_trendEach tool has a clearly distinct purpose: auth check, data type listing, profile, daily multi-metric brief, weekly trend, readiness, anomaly scan, raw points, and daily aggregate. No overlap between tools; health_daily_brief and health_daily differ by scope (single day vs range) and metric count.
All tools follow a consistent health_ prefix with descriptive snake_case suffixes (auth_status, data_types, profile, daily_brief, trend, readiness, anomalies, points, daily). The pattern is uniform and predictable.
9 tools is a well-scoped number for a health data server. Each tool covers a distinct aspect of reading and analyzing health metrics without redundancy or bloat.
The tool surface covers authentication, data discovery, profile, daily snapshots, trends, readiness, anomalies, raw data, and daily aggregates. Minor gap: no direct way to get multiple metrics across a date range in one call, but this can be composed from existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect your wearables, rings and training apps, then ask your AI about your own health data.
Read wearables and lab health data — sleep, activity, workouts, timeseries, lab tests and orders.
Your own SLATE health data in your AI assistant: read, trend, plan and log. Never suggests a dose.
Private Apple Health metrics and workout detail for ChatGPT, Claude, and any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kirollosatef/google-health-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
