A read-only local MCP server that exposes personal Google Health (Fitbit, Pixel Watch) data, calculated metrics, and summaries to AI agents.
Get daily health facts (get_daily_health_facts): Retrieve calculated health metrics for a specific date — sleep data, resting heart rate, HRV, activity values — plus 7-day/28-day baseline comparisons.
Get daily health pulse (get_daily_health_pulse): Fetch a deterministic, human-readable English summary of your daily health status for a given date.
Get health history (get_health_history): Query normalized daily metrics (e.g., sleep minutes, steps, resting heart rate, HRV) for an inclusive date range of up to 90 days, with optional field filtering.
Get health data status (get_health_data_status): Check authorization status, last sync time, and local data coverage — without exposing any credentials.
Get health data catalog (get_health_data_catalog): List all supported detailed data types (e.g., sleep stages, intraday heart rate, HRV, activity intervals) along with their local record coverage dates.
Get full-fidelity health records (get_health_records): Retrieve complete, detailed Google Health records (sleep stage segments, timestamped heart rate samples, etc.) for a date range, with data type filtering and pagination (up to 500 records).
Get health records by time window (get_health_window): Query detailed health records overlapping an exact ISO 8601 time window (max 7 days), ideal for correlating health data with calendar events, workouts, or sleep periods, with pagination support.
Delivers daily health pulse messages and allows Discord users to query health data through Hermes integration.
Synchronizes Fitbit health data (steps, sleep, heart rate, etc.) into the local database using the Google Health API.
Integrates with Google Health API v4 to fetch and synchronize health data from sources like Fitbit and Pixel Watch, providing daily metrics and historical records.
Allows the Hermes AI agent to access health facts, baselines, and daily pulse messages via a read-only MCP server for contextual conversations and memory.
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 what's my daily pulse?"
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.
A self-hosted health service for Google Health API v4. It synchronizes Fitbit, Pixel Watch, and compatible health data, preserves timestamped records locally, calculates reproducible 7-day and 28-day comparisons, and exposes both summaries and full-fidelity data to Hermes Agent through a read-only MCP server.
You can do anything you want with this repo. Codex was used to code it. Use at your own risk. For Mac users, there should not be much of a difference. I will test it on a Mac later and update the repository if there are any issues.
Google Health API
→ OAuth 2.0 + encrypted tokens
→ FastAPI / healthctl
→ SQLCipher-encrypted database + encrypted sensitive payloads
→ deterministic baselines
→ local read-only MCP server
→ Hermes (optional)
→ DiscordThe health core works without Hermes. If Hermes, the subscription, or a rate limit is unavailable, the service can produce a deterministic English template message.
Related MCP server: personal-health-mcp
Requirement: Python 3.11 or newer.
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -e ".[dev]"
Copy-Item .env.example .env
healthctl seed-demo
healthctl daily-pulse --no-hermesAlternatively, healthctl setup creates .env interactively without displaying the
client secret. OAuth client credentials are stored in data/credentials.enc, not
.env.
Existing installations should run this once after upgrading:
healthctl migrate-securityThis converts an existing plaintext SQLite database to SQLCipher, moves Google OAuth
client credentials out of .env, protects the master key with Windows DPAPI, and
restricts local file permissions.
For real data:
Run healthctl serve.
In a second terminal, run healthctl authorize.
Run healthctl sync.
Run healthctl daily-pulse --no-hermes.
See docs/windows-setup.md for the complete Windows, Hermes, Codex, Discord, MCP, and scheduler setup.
healthctl serve and the MCP server are separate:
healthctl serve starts the local FastAPI service on 127.0.0.1:8765. It is needed
for the Google OAuth callback and only if you want to use the REST endpoints.
The local MCP server uses stdio. Hermes starts google-health-mcp automatically when
it loads the configured google-health MCP connection.
You do not need to keep healthctl serve running for MCP access, synchronization
through the CLI, or daily-pulse generation.
To use health tools from Discord continuously, the Hermes gateway must be running.
To refresh the local database, run healthctl sync manually or schedule
healthctl run-daily.
The service binds only to 127.0.0.1:8765 by default.
healthctl serveMethod | Path | Purpose |
|
| Configuration and sync status without secrets |
|
| Start Google OAuth |
|
| Receive the OAuth callback |
|
| Revoke Google access |
|
| Synchronize a date range |
|
| Generate facts and a message |
Examples:
Invoke-RestMethod -Method Post `
-Uri http://localhost:8765/v1/sync `
-ContentType application/json `
-Body '{"start_date":"2026-05-15","end_date":"2026-06-20"}'
Invoke-RestMethod -Method Post `
-Uri http://localhost:8765/v1/daily-pulse `
-ContentType application/json `
-Body '{"use_hermes":true,"send":false}'Uvicorn access logs are disabled by the CLI server so OAuth codes do not appear in query-string logs.
The database stores two complementary layers.
Normalized daily values:
Sleep duration, sleep period, awake time, awakenings, and efficiency
Light, deep, and REM sleep when available
Steps
Light, moderate, and vigorous activity minutes
Exercise count, duration, and types
Daily resting heart rate
Daily HRV/RMSSD
Full-fidelity records preserve the complete structured Google payload and timestamps for every supported stream under the configured activity, health-metrics, and sleep scopes. This includes:
Complete sleep sessions, stage segments, and out-of-bed segments
Intraday heart rate, HRV, oxygen saturation, and respiratory measurements
Heart-rate zones, activity intervals, sedentary periods, and exercise details
Energy, distance, floors, VO2 max, body measurements, and temperature records
Daily rollups for total calories and calories in heart-rate zones
The complete SQLite database, including normalized metrics, timestamps, indexes,
OAuth states, and tokens, is encrypted with SQLCipher. Sensitive payloads and OAuth
tokens retain an additional Fernet encryption layer. Google OAuth client credentials
are stored in an encrypted credential file rather than .env.
On Windows, the local master key at data/token.key is wrapped with DPAPI for the
current Windows account. The data directory, database, key, credential store, and
.env use ACLs restricted to that account and SYSTEM. Secrets must be decrypted in
application memory while in use; no application can protect them from malware already
running as the same signed-in user.
The default daily sync uses 35 days for compact baseline metrics and two recent days
for full-resolution records. This avoids re-downloading hundreds of thousands of
one-second heart-rate samples every morning. Detailed records accumulate locally as
the scheduled sync advances. Configure HEALTH_DETAILED_SYNC_LOOKBACK_DAYS from 1 to
90 for a larger initial backfill.
healthctl setup
healthctl migrate-security
healthctl serve
healthctl authorize
healthctl sync
healthctl facts [--date YYYY-MM-DD]
healthctl daily-pulse [--send] [--no-hermes]
healthctl run-daily [--send]
healthctl seed-demo
healthctl doctorThe project includes a read-only stdio MCP server for Hermes and other local MCP clients:
google-health-mcp --project-dir C:\path\to\Google-HealthIt exposes:
Calculated daily facts and 7-day/28-day baselines
The deterministic English daily pulse
Selected normalized history for up to 90 days
A catalog of all detailed data types and their local coverage
Full-fidelity records for a date range with bounded pagination
Exact timestamp-window queries for calendar and workout correlation
Authorization, sync, and local data-coverage status
It does not expose OAuth tokens, Google credentials, synchronization, revocation, or database-write operations. Detailed health payloads are intentionally available to the local agent, but each call is date bounded, limited to at most 500 records, and pageable.
Hermes normally starts this executable automatically. You should not run it manually unless you are testing an MCP client.
The repository includes skills/google-health/SKILL.md. It teaches Hermes how to choose the correct health tool, correlate exact windows with calendar events, handle timezones and personal baselines, and use memory without copying raw health data into it.
Install it into the active Hermes profile:
$SkillsRoot = if (Test-Path "$env:LOCALAPPDATA\hermes\skills") {
"$env:LOCALAPPDATA\hermes\skills"
} else {
"$HOME\.hermes\skills"
}
$Target = Join-Path $SkillsRoot "personal\google-health"
New-Item -ItemType Directory -Force $Target | Out-Null
Copy-Item .\skills\google-health\SKILL.md $Target\SKILL.md -ForceStart a new Hermes session after installing or changing the skill.
Never put secrets in issues, chat messages, or Git.
Only read-only Google Health scopes are requested.
The complete health database is encrypted at rest with SQLCipher.
OAuth client credentials are encrypted outside .env; tokens are encrypted inside
the SQLCipher database with an additional Fernet layer.
Hermes Discord access is restricted through DISCORD_ALLOWED_USERS.
The FastAPI service binds to localhost by default and provides no public multi-user authentication.
Health guidance describes trends; it does not provide diagnoses or treatment.
A centrally hosted service requires a different security architecture, privacy review, Google OAuth verification, and recurring restricted-scope security review.
pytest
ruff check .Return calculated health facts and 7/28-day baselines for one recovery date.
The recovery date contains sleep, resting heart rate, and HRV. Activity values intentionally refer to the previous calendar day. Use YYYY-MM-DD or omit the date for today in the configured timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| recovery_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a key non-obvious behavior: 'Activity values intentionally refer to the previous calendar day.' It also clarifies the scope (one recovery date) and the default (today). No mention of side effects, but as a read operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two short paragraphs. The first sentence front-loads the purpose. The second paragraph adds necessary detail. No extraneous information, though the first sentence could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with an output schema, the description covers the essential context: purpose, parameter format, and a behavioral quirk (activity lag). It does not mention error handling or missing data, but overall it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but there is only one parameter. The description adds significant meaning: date format (YYYY-MM-DD), optionality, and default behavior (today). This goes well beyond the raw schema which only provides type constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return calculated health facts and 7/28-day baselines for one recovery date' with a specific verb and resource. It also details the data elements (sleep, resting heart rate, HRV). However, it does not explicitly differentiate from sibling tools like get_daily_health_pulse, though the unique mention of baselines and activity lag provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides syntactic guidance on using the date parameter ('Use YYYY-MM-DD or omit the date for today'), but no guidance on when to use this tool versus sibling tools (e.g., get_daily_health_pulse, get_health_history). The agent receives no context on alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the deterministic English daily health summary for one date.
| Name | Required | Description | Default |
|---|---|---|---|
| recovery_date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions 'deterministic', indicating consistent output, but lacks disclosure of side effects, authentication needs, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is too brief to cover necessary details. It achieves conciseness at the cost of structure and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter and no annotations, the description leaves many unknowns. While an output schema exists, the description itself is insufficient for a complete understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'recovery_date' parameter's format, meaning, or default behavior. The parameter name is not self-explanatory without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a daily health summary for one date, using a specific verb and resource. However, it does not explicitly distinguish from siblings like get_daily_health_facts, though the term 'pulse' implies a summary nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives, or what conditions apply. The description provides no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every supported detailed data type and its local record coverage.
| 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?
No annotations are provided, so the description must convey behavioral traits. It indicates a read-only listing operation, but does not disclose performance guarantees, result size, or whether the list is exhaustive. It is transparent about what it lists but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence (11 words) that is front-loaded with the action 'List.' No wasted words, very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, output schema present) and no sibling tool with similar scope, the description is mostly complete. However, 'local record coverage' could benefit from elaboration, but the output schema likely clarifies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so the description carries the burden. It adds meaning by specifying what is listed ('supported detailed data type and its local record coverage'), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'every supported detailed data type and its local record coverage,' which is a specific verb ('list') and resource. It distinguishes from siblings like get_health_history (which lists actual records) and get_daily_health_facts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not directly state when to use this tool vs alternatives, but its purpose ('list all data types and coverage') implies it is for discovering available data types. No explicit exclusion or condition is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return authorization, last-sync, and local data-coverage status without secrets.
| 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?
With no annotations available, the description carries full responsibility for behavioral disclosure. It states the tool returns data 'without secrets' but does not indicate whether it is read-only, requires authentication, has rate limits, or what happens on error. The lack of side-effect or permission context limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's output and a key constraint (without secrets). Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic return content but lacks detail on what each status field means and how this tool relates to siblings. With an output schema present, the description could be more self-contained. For a simple tool with no parameters, it is adequate but leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% (trivially). The description adds no parameter meaning, but none is needed. Baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns three specific status components (authorization, last-sync, local data-coverage) and explicitly excludes secrets. It uses a specific verb 'Return' and distinguishes itself from sibling tools like get_daily_health_facts or get_health_records which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. There is no mention of prerequisites, typical usage scenarios, or exclusions. The agent must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return normalized daily metrics for an inclusive date range of up to 90 days.
Optionally request only selected fields such as sleep_minutes, steps, resting_heart_rate, or hrv_rmssd_ms. This tool is read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | ||
| end_date | Yes | ||
| fields | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly states the tool is read-only and limits date range to 90 days, which are important behaviors. However, it does not disclose potential error cases, data origin, or what happens when the range exceeds 90 days. With no annotations provided, the description carries the burden and offers moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding value. It front-loads the primary action and includes key constraints and options with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the date range limit and optional fields, but lacks prerequisites, error conditions, or format details for dates. Given the output schema likely covers return values, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description adds meaning by specifying 'inclusive date range of up to 90 days' and listing example fields like sleep_minutes, steps. But it omits the date format (e.g., YYYY-MM-DD), so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns normalized daily metrics for an inclusive date range, with optional field filtering. It also declares read-only. However, it does not explicitly differentiate this tool from siblings like get_daily_health_facts or get_daily_health_pulse, which have similar names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only implies usage for retrieving historical metrics but lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return encrypted-at-rest, full-fidelity Google Health records.
Dates are inclusive YYYY-MM-DD values. Use the catalog first, request only the data types needed, and paginate with limit/offset. Sleep records include complete stage segments; sample data such as heart rate retains its observation timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | ||
| end_date | Yes | ||
| data_types | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses encryption at rest, full-fidelity data, date inclusivity, pagination behavior, and specifics about sleep records and heart rate samples. This provides valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. The main purpose is front-loaded, and every sentence adds value without redundancy. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. It covers usage order (catalog first), data type selection, pagination, and special data fidelity aspects. Slightly more detail on data_types format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds semantics for dates ('inclusive YYYY-MM-DD values') and mentions pagination parameters. However, it does not explain the format or possible values for the 'data_types' parameter, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the resource ('encrypted-at-rest, full-fidelity Google Health records'). It distinguishes from sibling tools like get_daily_health_facts by emphasizing 'full-fidelity' and mentioning specific data types like sleep and heart rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use the catalog first, request only the data types needed, and paginate with limit/offset.' It also notes inclusive date formats. However, it does not explicitly state when not to use this tool or name alternative tools for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return detailed records overlapping an exact ISO 8601 time window.
This is intended for correlations with calendar events, workouts, sleep periods, and other timestamped tools. Naive timestamps use the configured local timezone. The maximum window is seven days and results are bounded and pageable.
| Name | Required | Description | Default |
|---|---|---|---|
| start_time | Yes | ||
| end_time | Yes | ||
| data_types | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description covers key behaviors: it returns records, uses ISO 8601 timestamps with local timezone handling for naive timestamps, and limits the window to seven days with bounded, pageable results. It does not explicitly state read-only status, but as a get operation, it is implied. The description sufficiently discloses potential pitfalls like timezone handling and pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, each adding essential information: core purpose, intended usage, timezone handling, window limit, and pagination. No extraneous words, well front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values are covered), the description covers the main aspects: what the tool does, when to use it, timezone behavior, window constraints, and pagination. The only gap is the lack of explanation for the data_types parameter, which could affect agent decision-making. Overall, it is quite complete for a tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage. The description explains start_time and end_time as forming an ISO 8601 time window and mentions naive timestamp handling, which adds meaning. However, it does not describe data_types (nullable array of strings), limit, or offset, leaving their semantics entirely to schema defaults. This partial explanation results in a baseline score of 3 for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return detailed records overlapping an exact ISO 8601 time window', which specifies the verb and resource. The context for correlations with other timestamped tools further clarifies its purpose and distinguishes it from siblings like get_daily_health_facts which are for daily aggregates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'correlations with calendar events, workouts, sleep periods, and other timestamped tools'. It also mentions constraints: maximum window of seven days and pagination. While it does not explicitly list when not to use or alternative tools, the context is strong enough for an AI to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_daily_health_factsget_daily_health_pulseget_health_data_catalogget_health_data_statusget_health_historyget_health_recordsget_health_windowScored across 7 tools
Tools have distinct purposes but some overlap exists: get_daily_health_facts and get_daily_health_pulse both return daily summaries (one factual, one narrative), and get_health_history vs get_health_records both provide data at different granularities. Descriptions help differentiate, but minor ambiguity remains.
All tool names follow the verb_noun pattern with snake_case, consistently using 'get_' prefix. The naming is uniform and predictable (e.g., get_daily_health_facts, get_health_data_catalog).
With 7 tools, the set is well-scoped for a health data server. Each tool serves a distinct purpose (daily summary, history, records, catalog, status, time window) without unnecessary bloat or deficiency.
The tool set provides thorough read-only coverage: daily facts, narrative summaries, historical trends, full-fidelity records, time-window queries, and metadata. Missing write operations (create/update/delete) are reasonable if the server is query-only. Minor gaps like direct metric extraction are mitigated by history and records tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for the Healthie EHR & telehealth API: patients, appointments, charting, tasks.
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Read-only health context MCP server for Iris users.
Multi-tenant hosted MCP server for Oura Ring — 21 read-only tools, OAuth per user.