What can you do with this server?

This server gives AI agents a local-first MCP interface to your personal health data, with read/write tools, analytics, and evidence-based provenance. * Read daily health metrics across 9 supported metrics (steps, sleep, heart rate, HRV, weight, etc.) * Export health data to CSV for long-range analysis without loading rows into context * Log daily metrics, raw timestamped measurements, and structured workout sessions * Clear or correct a single metric/day without affecting other data * Query raw measurements and workout sessions with filters * Inspect metric provenance by source and preview source-priority disagreements * Get single-metric history, baselines, trends, anomalies, period comparisons, and correlations * Scan all metrics for recent changes or get a full why-bundle for one metric on one date * Every analytics result includes coverage/confidence evidence, and private fields can be excluded via HEALTH_PRIVATE_FIELDS

Which integrations are available for this server?

Allows importing health data from Apple Health export files (XML) into the local database, as well as reading and logging daily health metrics.

How do I use Quantified Self MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Quantified Self MCP Server What was my average sleep and steps last 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.

de en es ja ko ru zh

Quantified Self MCP Server

by Thecimal

Overview Schema Source Related Servers Discussions Admin

Python

Local

Quantified Self MCP

PyPI License M8ven Score Quantified Self MCP Server MCP server – quality and maintenance score on Glama

Your health data. Your AI. Your machine.
A local-first MCP server that gives AI agents access to your personal health data — with privacy, provenance, and evidence built in.

· Documentation

What is it?

Quantified Self MCP gives an AI agent a local, structured interface to your own health history.

Instead of another health dashboard, you can ask your AI questions like:

Why did my HRV change recently?

How has my sleep changed over the last 30 days?

What happened to my resting heart rate after my workouts increased?

What patterns do you see across my recent health data?

Which metrics changed the most this month?

The AI retrieves the relevant data through MCP and analyzes it.

The goal isn't another health dashboard.
It's a trustworthy interface between your health history and your AI.

Related MCP server: apple-health-mcp

Why is it different?

🔒 Local-first

Your health database runs locally in SQLite.

You control where your data goes.

You can use a completely local AI stack:

Health Data
     ↓
Local SQLite
     ↓
Quantified Self MCP
     ↓
MCP Agent
     ↓
Local LLM

Cloud models are also supported. In that configuration, the MCP database remains local, but data returned by MCP tools may be sent to the model provider.

🤖 AI-native

Built specifically for MCP-compatible AI agents, rather than another standalone health application.

🔎 Evidence & provenance

Analytics can be traced back to the underlying health data and its provenance.

The goal is not simply:

HRV ↓ 24%

but understanding:

What data produced this result?
Where did it come from?
What period was analyzed?
How strong is the evidence?

Concretely, every trend, baseline, anomaly, comparison, and correlation carries a coverage/confidence object alongside its numbers, so the AI can talk about the result and the evidence behind it in the same breath:

Without evidence:

Your HRV decreased 24% over the last 30 days.

With evidence:

Your HRV decreased 24% over the last 30 days — but HRV was only logged on 71% of those days, so treat this trend cautiously rather than as a settled pattern.

The second answer is what calculate_metric_trend (and every other analytics tool) is designed to make possible: the tool returns the 24% figure and a confidence: "moderate" / coverage_ratio: 0.71 alongside it, and each tool's own description tells the calling model to fold that into its answer instead of reporting the number as if it came from a complete series.

📊 Longitudinal

Analyze health history across days, weeks, months, and years:

trends
baselines
anomalies
period comparisons
correlations
recent changes
metric explanations

📥 Import existing data

Bring your existing health history into the local database.

Supported imports include:

CSV
Apple Health exports

See the import documentation.

What can your AI do?

Read

Health metrics
Metric history
Raw measurements
Workout sessions
Data provenance

Analyze

Baselines
Trends
Anomalies
Period comparisons
Correlations

Explain

Recent changes
Metric changes
Supporting evidence
Data provenance

The MCP currently exposes 18 tools across data access, measurements, workouts, analytics, and personal intelligence.

See the tool reference for the complete list.

Supported data

Currently supported metrics include:

👟 Steps
😴 Sleep
❤️ Heart rate
❤️ Resting heart rate
📈 HRV
⚖️ Weight
🏋️ Workout minutes
🙂 Mood
💧 Water

The data model is extensible, so you can keep only the metrics you actually use.

Quick start

Install

pip install quantified-self-mcp

Import your data

CSV:

quantified-self-init-db your-health-data.csv

Apple Health:

quantified-self-init-db export.xml

Connect an MCP client

Configure your preferred MCP-compatible client to run:

quantified-self-mcp

Client-specific setup guides are available in docs/clients/.

Ask your AI

How has my sleep changed over the last 30 days?

That's it.

Privacy

Health data is sensitive.

Quantified Self MCP is designed around local ownership:

Your database stays on your machine.
No proprietary health-data cloud is required.
You choose the AI model.
You can run the entire stack locally.
Private metrics can be excluded from AI access.

For example:

HEALTH_PRIVATE_FIELDS=weight_kg,mood

Private fields remain stored locally but are excluded from MCP read and analytical operations.

See SECURITY.md for security considerations.

Architecture

                  AI Agent
                     │
                 MCP Protocol
                     │
                     ▼
          ┌─────────────────────┐
          │ Quantified Self MCP │
          │                     │
          │  Data · Analytics   │
          │  Evidence           │
          └──────────┬──────────┘
                     │
                     ▼
              Local SQLite
                     │
                     ▼
              Your Health Data

The MCP server is the bridge between your health history and your AI.

Documentation

Detailed documentation lives outside the README:

Open source

Quantified Self MCP is open source and built for the wider MCP ecosystem.

Contributions are welcome — especially around:

health-data imports
analytics
evidence and data quality
privacy
MCP client integrations
documentation

See CONTRIBUTING.md.

License

MIT

Your health data. Your AI. Your machine.
Local data. Open protocol. AI-powered insight.

Available Tools

18 tools

aggregate_measurementsPreview a source-priority resolution of a day's measurementsA

Read-onlyIdempotent

Preview what one day's raw measurements would roll up to if a conflicting metric were resolved using source_priority, alongside that day's actual current daily_metrics values.

daily_metrics is a database-maintained projection (see db/schema.sql): every log_measurement/import automatically keeps it in sync with all of that day's measurements the moment it's written, using each metric's fixed aggregation method (sum/mean/last — see aggregation_rules, or get_baseline's "method" field). It blends every source together and cannot be made to prefer one — there is no stored "priority" it can consult. So unlike before, this tool no longer writes anything: "aggregated" is only a preview of what source_priority would produce; "row" is the real, currently-stored value, computed from every source, which may well differ from "aggregated" whenever sources disagree.

If a metric has measurements from more than one source that day (e.g. an Apple Watch and a Garmin both logging resting_heart_rate), use get_metric_provenance first to see whether they actually disagree. To make daily_metrics itself reflect only one source going forward, remove the other source's data — clear_metric (which now removes every measurement behind that metric/day, not just a log_daily_metric value) followed by re-logging the preferred reading, or re-running its import with --replace.

Privacy note: this server and its SQLite file are entirely local, but the data returned by this tool becomes part of the conversation sent to whatever model the calling client is configured with. If that model runs in the cloud rather than on your machine, treat this the same as pasting the data into a chat with that provider.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	The day to preview, formatted YYYY-MM-DD.
`source_priority`	No	Ordered list of source names, e.g. ["Apple Watch", "Garmin"]. For any metric with more than one source that day, the first name in this list that's actually present wins in "aggregated" and the other source's readings for that metric are dropped from that preview. Omit to fall back to whichever source was imported most recently. Never affects "row" — see above.

Output Schema

ParametersJSON Schema

Name	Required	Description
`row`	Yes
`date`	Yes
`aggregated`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description goes well beyond them by stating the tool 'no longer writes anything' and explaining that 'aggregated' is only a preview while 'row' is the actual stored value. It also adds a privacy note about data becoming part of the conversation sent to the model, which is valuable behavioral context not captured 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but each section earns its place: it explains the database projection, the preview-vs-actual distinction, the recommended workflow with get_metric_provenance and clear_metric, and the privacy implications. It is front-loaded with the core purpose and avoids fluff, though a slightly tighter treatment of the schema background would improve it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with output schema already present, the description covers everything else an agent needs: the difference between 'aggregated' and 'row', fallback behavior when source_priority is omitted, the relationship to daily_metrics, and the prerequisite step of checking provenance. There is no critical gap that would prevent correct invocation or interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents both parameters with 100% coverage, including the date format and the ordered-list semantics of source_priority. The description reinforces the meaning but does not add substantial new parameter-level detail beyond what the schema's descriptions already provide, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Preview what one day's raw measurements would roll up to if a conflicting metric were resolved using source_priority, alongside that day's *actual* current daily_metrics values.' This clearly distinguishes it from sibling tools like get_metric_provenance and clear_metric by stating it is a read-only preview rather than a write or provenance inspection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when to use a different tool first: 'If a metric has measurements from more than one source that day... use get_metric_provenance first to see whether they actually disagree.' It also explains that to change daily_metrics, the agent should use clear_metric followed by re-logging or re-importing, not this tool. This provides clear routing between the preview and the mutating alternatives.

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

calculate_metric_trendCalculate metric trendA

Read-onlyIdempotent

Fit a simple straight-line trend to one metric over a window and report its direction, slope (change per day), and r_squared (how well a straight line actually fits — low r_squared means "noisy," not "flat").

Use this tool when:

the user asks whether one metric is trending up/down/flat over a continuous window (e.g. "is my weight trending down?", "how has my HRV changed?").

Do not use this tool when:

the user wants two specific, separately-defined ranges compared (e.g. "this month vs last month") rather than a single continuous slope -> use compare_metric_periods instead.
the user asks what's typical/normal rather than which direction it's moving -> use get_baseline instead.
the user asks about isolated unusual days rather than an overall direction -> use detect_metric_anomalies instead.

ParametersJSON Schema

Name	Required	Description
`metric`	Yes	One of steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms.
`end_date`	No	Last day to include, formatted YYYY-MM-DD. Defaults to today.
`start_date`	No	First day to include, formatted YYYY-MM-DD. Defaults to 30 days before end_date.

Output Schema

ParametersJSON Schema

Name	Required	Description
`range`	Yes
`trend`	Yes
`metric`	Yes
`evidence`	Yes	Coverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.
`claim_decision`	No	How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it.
`evidence_profile`	No	Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate.

TDQS

A4.6/5.0

Behavior5/5

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

The annotations already declare the tool read-only, idempotent, and non-destructive, so the description is free to add interpretive guidance: low r_squared means 'noisy,' not 'flat.' It also discloses that returned data becomes part of the conversation sent to the configured model, which is a meaningful behavioral/privacy caveat.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and uses scannable bullets for usage conditions, which makes selection easy. It is longer than strictly necessary, but the privacy note and sibling routing add substantive guidance rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich annotations, complete input schema, and presence of an output schema, the description covers everything an agent needs to decide when to use this tool and what to expect. It explains the distinction between slope and fit quality and appropriately routes ambiguous user intents to sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all three parameters at 100% coverage, including the metric enum, date formats, and defaults. The description reinforces 'one metric over a continuous window' but does not add significant parameter-level meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action: fit a straight-line trend to one metric over a window and report direction, slope, and r_squared. It clearly differentiates from siblings by naming compare_metric_periods, get_baseline, and detect_metric_anomalies as alternatives for different intents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit 'Use this tool when' and 'Do not use this tool when' sections with concrete example queries like 'is my weight trending down?' It names three sibling tools and the exact conditions under which each should be used instead.

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

clear_metricClear a single metricA

DestructiveIdempotent

Blank out (set to null) a single metric for a single day, without touching that day's other metrics. The counterpart to log_daily_metric for undoing a bad value — e.g. a mood logged for the wrong day, or a weight entered with the wrong units. Clears everything recorded for that metric/day — including individual log_measurement readings or imported rows, not just a value log_daily_metric wrote directly — so the metric genuinely goes back to "nothing recorded" rather than falling back to a blended value from whatever else is left.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	The day to clear a field for, formatted YYYY-MM-DD.
`field`	Yes	Which metric to blank out. One of: steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms.

Output Schema

ParametersJSON Schema

Name	Required	Description
`row`	No
`note`	No
`cleared`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

The description goes well beyond the annotations' destructiveHint by detailing the full scope of destruction: it clears everything recorded for that metric/day, including individual log_measurement readings and imported rows, not just values written by log_daily_metric. It also adds a privacy note about data becoming part of the conversation sent to a model, which annotations do not cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The main behavioral statement is front-loaded and precise, and the extra detail about clearing all related rows is necessary for a destructive tool. The privacy note adds relevant context but is somewhat tangential to invocation, keeping this from a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter destructive operation, the description fully covers what the tool does, the scope of the destruction, and a privacy consideration. The output schema exists, so return-value details are not the description's responsibility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already fully documents both parameters. The description reinforces the behavior ('set to null', 'single metric', 'single day') but does not add meaning beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a precise verb ('blank out / set to null') and identifies the exact resource ('a single metric for a single day'), making the operation unmistakable. It also distinguishes itself from the sibling log_daily_metric by explicitly naming it as the counterpart for undoing a bad value.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly explains when to use this tool: for undoing a bad value, with concrete examples like a mood logged for the wrong day or weight entered with wrong units. It does not enumerate explicit when-not-to-use cases or alternative tools, but the context is clear 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.

compare_metric_periodsCompare two periodsA

Read-onlyIdempotent

Compare one metric's average between two date ranges — e.g. "this month vs. last month" or "since starting a new medication vs. before." The two ranges may be any length and need not be adjacent or equal in size; each is summarized with its own baseline first.

Use this tool when:

the user names or implies two distinct date ranges to weigh against each other (e.g. "compare my average steps this month to last month", "since starting a new medication vs. before").

Do not use this tool when:

there's only one continuous window and the question is about direction over time, not two discrete ranges -> use calculate_metric_trend instead.
the user wants "what's normal" for a single window, not a before/after comparison -> use get_baseline instead.

ParametersJSON Schema

Name	Required	Description
`metric`	Yes	One of steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms.
`period_a_end`	Yes
`period_b_end`	Yes
`period_a_start`	Yes
`period_b_start`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`delta`	No
`metric`	Yes
`period_a`	Yes
`period_b`	Yes
`pct_change`	No
`claim_decision`	No	How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it.
`period_a_stats`	Yes
`period_b_stats`	Yes
`evidence_profile`	No	Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate.
`period_a_evidence`	Yes	Coverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.
`period_b_evidence`	Yes	Coverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive behavior. The description adds genuinely useful context: the two ranges need not be equal or adjacent, each is summarized with its own baseline first, and returned data may be sent to the configured model. The privacy note adds responsible data-handling context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the tool is easy to scan with clear headers. The privacy note adds length but is relevant; the 'Use this tool when' example partly repeats the opening example, a minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description handles sibling differentiation, behavioral summary, and privacy well, and an output schema exists to explain return shape. The main gap is parameter format — an agent still lacks the date syntax needed to call the tool correctly, and the phrase 'baseline first' is not fully clarified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%, so the description must compensate for the four undocumented date parameters. It explains that the ranges represent any two date periods, but it never specifies date format (e.g., YYYY-MM-DD), inclusivity, or how period_a relates to period_b concretely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Compare one metric's average between two date ranges.' The examples clarify the exact scenario, and the do-not-use section distinguishes it from calculate_metric_trend and get_baseline.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'Use this tool when' and 'Do not use this tool when' sections with named alternatives. This gives an agent clear decision rules for selecting this tool versus calculate_metric_trend or get_baseline.

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

detect_metric_anomaliesDetect metric anomaliesA

Read-onlyIdempotent

Flag days where one metric deviated sharply from its own baseline over the window, using a median/MAD-based modified z-score rather than a mean/stdev z-score — more robust for short, noisy personal-health series, where the mean/stdev version is easily dragged around by the very outliers it's supposed to catch.

Use this tool when:

the user asks whether anything looked unusual/off/weird on particular days for one metric (e.g. "was there anything unusual about my sleep last month?").

Do not use this tool when:

the user wants a general sense of what's typical, with no interest in flagging specific days -> use get_baseline instead.
the user asks about a steady increase/decrease over time rather than isolated spikes/dips -> use calculate_metric_trend instead.
the user already has one specific date in mind and wants the full "why" behind it (baseline, anomaly, trend, and correlations together) -> use explain_metric_change instead.

ParametersJSON Schema

Name	Required	Description
`metric`	Yes	One of steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms.
`end_date`	No	Last day to include, formatted YYYY-MM-DD. Defaults to today.
`threshold`	No	Modified z-score cutoff. 3.5 (the default, Iglewicz & Hoaglin's standard value) flags only clear outliers; lower it (e.g. 2.5) to see more borderline days.
`start_date`	No	First day to include, formatted YYYY-MM-DD. Defaults to 90 days before end_date.

Output Schema

ParametersJSON Schema

Name	Required	Description
`range`	Yes
`metric`	Yes
`evidence`	Yes	Coverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.
`anomalies`	Yes
`threshold`	Yes
`claim_decision`	No	How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it.
`evidence_profile`	No	Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral context: the statistical method's robustness rationale and a privacy note explaining that returned data becomes part of the model conversation. This exceeds the minimal annotation coverage, though the statistical rationale is more motivational than behavioral.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core behavior, then organized into clear usage sections and a privacy note. Every sentence serves a purpose: algorithm selection, usage routing, exclusions, and data-handling caution. It is longer than average but not bloated; the structure makes the length easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with an output schema and fully documented input schema, the description supplies everything needed to select and invoke it correctly: purpose, statistical method, when-to-use vs alternatives, exclusions, and privacy implications. No critical gap remains for correct tool selection or invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schemas provide 100% parameter documentation, including defaults, formats, and the metric enum list. The description reinforces that the tool handles one metric at a time, but it does not add substantive semantics beyond the schema. Baseline 3 applies because the schema already does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb ('Flag'), a precise resource ('days where one metric deviated sharply from its own baseline'), and the algorithmic approach (median/MAD modified z-score). It explicitly contrasts with mean/stdev z-score and names sibling tools that handle different cases, so an agent can distinguish it immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description has explicit 'Use this tool when' and 'Do not use this tool when' sections, with concrete example phrasings and named alternatives (get_baseline, calculate_metric_trend, explain_metric_change). This gives the agent clear routing criteria rather than leaving selection to inference.

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

explain_metric_changeExplain a metric changeA

Read-onlyIdempotent

Build an evidence bundle for "why did my look like that on ?": that day's value against a 90-day baseline, whether it qualifies as an anomaly, the trend leading into it, and any other metric that correlates with it strongly enough to be worth mentioning. Returns facts, not an explanation — turning "sleep was 2.6 stdev below baseline and resting heart rate correlates at r=0.71" into an actual answer for the person is what the calling model should do with these facts, not something this tool guesses at itself.

Do not use this tool when:

scanning across many metrics for what changed lately, without a specific metric/date in mind -> use get_recent_changes instead.
you only need one piece of this bundle (just the baseline, just the trend, just anomalies, or just a correlation) rather than the full why-explanation -> use get_baseline, calculate_metric_trend, detect_metric_anomalies, or find_metric_correlation directly instead.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	The day to explain, formatted YYYY-MM-DD.
`metric`	Yes	One of steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms.

Output Schema

ParametersJSON Schema

Name	Required	Description
`date`	Yes
`trend`	Yes
`value`	No
`metric`	Yes
`baseline`	Yes
`sessions`	No
`is_anomaly`	Yes
`baseline_range`	Yes
`claim_decision`	No	How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it.
`trend_evidence`	Yes	Coverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.
`narrative_facts`	Yes
`conflicting_days`	No
`evidence_profile`	No	Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate.
`modified_z_score`	No
`baseline_evidence`	Yes	Coverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.
`correlated_metrics`	Yes
`trend_claim_decision`	No
`trend_evidence_profile`	No

TDQS

A4.7/5.0

Behavior5/5

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

While annotations already declare readOnly, idempotent, and non-destructive, the description adds essential behavioral context: it states the tool returns facts, not explanations, and warns that returned data becomes part of the conversation and may be sent to a cloud model. This goes well beyond what annotations cover, giving the agent important privacy and usage boundaries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but tightly structured: it opens with the core purpose, explains the output's nature, then provides clear exclusion rules, and ends with a privacy caveat. Every sentence earns its place, and the most important guidance is front-loaded. The length is justified by the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (baseline, anomaly, trend, correlation) and the availability of an output schema, the description is exceptionally complete. It tells the agent exactly what the tool returns, when to avoid using it, and the privacy implications. Nothing an agent needs to make a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema documents both parameters fully (metric with a list of valid values, and date with format). The description adds little parameter-specific meaning beyond what's already in the schema. Since schema coverage is 100%, the baseline of 3 is appropriate, and the description doesn't need to repeat schema details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states precisely what the tool does: it builds an evidence bundle for explaining a metric change on a specified date, including baseline, anomaly, trend, and correlated metrics. It explicitly distinguishes itself from siblings by naming alternative tools for different scenarios, making it unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

A dedicated 'Do not use this tool when' section lists two distinct cases, each with specific alternative tool names and the conditions that trigger them. This gives the agent crystal-clear routing guidance beyond just a general description.

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

export_health_data_csvExport health data to CSVA

DestructiveIdempotent

Write daily health metrics for a date range to a CSV file on disk, next to the database, instead of returning every row through this tool's own result.

Unlike read_health_data, this is not capped at MAX_ROWS_RETURNED and the row values themselves are not included in this tool's response — only the resulting file's path and a row count are. That means a long-range export doesn't have to pass through a cloud LLM's context just to produce a file you can open yourself (in a spreadsheet, a notebook, another tool, etc.). Any metric listed in HEALTH_PRIVATE_FIELDS is still written as an empty cell in the file, since those fields shouldn't leave the database at all, not just stay out of the model's context.

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	No	Last day to include, formatted YYYY-MM-DD. Defaults to today.
`start_date`	No	First day to include, formatted YYYY-MM-DD. Defaults to 30 days before end_date. Ranges over ~10 years are rejected.

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	Yes
`range`	Yes
`rows_exported`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations mark destructiveHint=true and readOnlyHint=false, and the description fully supports this: it states it writes to disk, does not return row values, and only provides file path and row count. It goes beyond annotations by disclosing the privacy implication (data becomes part of the conversation) and the handling of HEALTH_PRIVATE_FIELDS as empty cells. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat long but each paragraph earns its place: purpose, privacy note, and comparison with read_health_data. It is front-loaded with the main action and uses structured paragraphs. Slightly verbose but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that writes to disk and has privacy implications, the description covers all necessary aspects: side effects, return value (path and row count), difference from read_health_data, private field behavior, and privacy guidance. The output schema exists, so return format is already specified. An agent has everything needed to decide and call this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage: both start_date and end_date have clear descriptions with formatting and defaults. The description adds no new semantic detail about the parameters beyond 'date range', so it stays at the baseline for well-covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair: 'Write daily health metrics for a date range to a CSV file on disk, next to the database.' It clearly distinguishes itself from read_health_data by contrasting the output (file path vs. rows) and the row cap. An agent immediately knows what this tool does and how it differs from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the alternative (read_health_data) and explains the differentiator: this tool is not capped at MAX_ROWS_RETURNED and avoids passing data through the model context. It also advises treating the export like pasting into a chat if the model is cloud-based. This gives the agent clear conditions for choosing this tool over alternatives.

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

find_metric_correlationFind correlation between two metricsA

Read-onlyIdempotent

Compute the Pearson correlation between two metrics over the same window, joined by date. Correlation, not causation: a strong r just means the two moved together, not that one caused the other.

Use this tool when:

the user names or implies two different metrics and asks whether they move together (e.g. "does my sleep affect my mood?", "did my HRV change after I increased my workouts?").

Do not use this tool when:

only one metric is in question -> use get_baseline, calculate_metric_trend, or detect_metric_anomalies instead, depending on what's being asked about that one metric.

ParametersJSON Schema

Name	Required	Description
`end_date`	No	Last day to include, formatted YYYY-MM-DD. Defaults to today.
`lag_days`	No	Shift metric_b this many days later before joining — 1 tests whether metric_a today predicts metric_b tomorrow (e.g. "does poor sleep tonight predict lower steps tomorrow?"). 0 (default) compares same-day values.
`metric_a`	Yes
`metric_b`	Yes
`start_date`	No	First day to include, formatted YYYY-MM-DD. Defaults to 90 days before end_date.

Output Schema

ParametersJSON Schema

Name	Required	Description
`n`	Yes
`r`	No
`note`	No
`lag_days`	Yes
`metric_a`	Yes
`metric_b`	Yes
`evidence_a`	No
`evidence_b`	No
`claim_decision`	No	How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it.
`evidence_profile`	No	Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate.
`sample_confidence`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds value by explaining the computation method (Pearson correlation), the join by date, the correlation-not-causation caveat, and a privacy note about data leaving the local server. These are behavior traits not in annotations, so the description is transparent and adds context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured: purpose statement, caveat, usage conditions, exclusion with alternatives, and a privacy note. It is front-loaded with the core meaning and uses clear bullet-like statements. Slightly longer than strictly necessary due to the privacy note, but each section adds useful guidance and does not waste words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (5 params, 2 required, output schema present), the description covers what the tool does, when to use it, exclusions, and adds a privacy context. The only gap is parameter details for metric_a/b, but the description implies they are metric names, which is likely obvious for an agent. With output schema existing, return values need no explanation. Overall it is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60% (end_date, lag_days, start_date have descriptions; metric_a and metric_b do not). The description does not provide explicit parameter names or value formats for metric_a/b, though it implies they are metric identifiers via examples. This partially compensates for the coverage gap but leaves meaning to inference. Baseline for 60% coverage is 3, and the description adds marginal value but not full compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states the tool computes Pearson correlation between two metrics joined by date, which is a specific verb+resource+method. It also distinguishes from single-metric tools by emphasizing 'two different metrics' and gives example phrasings. This is clear and differentiates from siblings like calculate_metric_trend or detect_metric_anomalies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description provides explicit 'Use this tool when' and 'Do not use this tool when' sections, naming specific alternative tools (get_baseline, calculate_metric_trend, detect_metric_anomalies) for single-metric queries. This gives agents clear decision criteria for routing to the correct tool.

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

get_baselineGet metric baselineA

Read-onlyIdempotent

Compute "what's normal" for one metric over a window: mean, median, and standard deviation. This is the number every other analytics tool below measures against, so a wider window (60-90+ days) gives a more stable baseline than the 30-day default read_health_data uses.

Use this tool when:

the user asks what's normal/typical/usual for one metric (e.g. "what's normal for my resting heart rate?"), with no particular day or direction of change in mind.

Do not use this tool when:

the user asks whether a metric is going up/down over time -> use calculate_metric_trend instead.
the user asks whether specific days looked unusual -> use detect_metric_anomalies instead.
the user wants two ranges compared against each other -> use compare_metric_periods instead.

ParametersJSON Schema

Name	Required	Description
`metric`	Yes	One of steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms.
`end_date`	No	Last day to include, formatted YYYY-MM-DD. Defaults to today.
`start_date`	No	First day to include, formatted YYYY-MM-DD. Defaults to 90 days before end_date.

Output Schema

ParametersJSON Schema

Name	Required	Description
`range`	Yes
`metric`	Yes
`baseline`	Yes
`evidence`	Yes	Coverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly, idempotent, and non-destructive annotations, the description discloses the default window behavior, stability tradeoffs, and the privacy implication that returned data becomes part of the model conversation. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with the core definition front-loaded, followed by compact usage bullets. The privacy note is somewhat long but provides important context that is not available elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, usage alternatives, parameter guidance, and privacy implications, while the output schema handles return-value expectations. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds actionable parameter guidance: it recommends a 60-90+ day window for stability and contrasts it with read_health_data's 30-day default. It also clarifies that the tool handles exactly one metric.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear, specific operation: compute what's normal for one metric over a window with mean, median, and standard deviation. It distinguishes itself from sibling analytics tools by emphasizing the single-metric baseline scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contains explicit 'Use this tool when' and 'Do not use this tool when' sections, naming calculate_metric_trend, detect_metric_anomalies, and compare_metric_periods with their respective trigger conditions. This gives an agent unambiguous routing guidance.

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

get_metric_historyGet metric historyA

Read-onlyIdempotent

Read one metric's day-by-day values, without the other six metrics read_health_data always includes. Use this when you only care about a single metric (e.g. before calling get_baseline or calculate_metric_trend yourself) and don't need the full multi-metric payload.

Use this tool when:

the user wants one specific metric's history/trend over time (e.g. "show my weight over the last 30 days", "how has resting heart rate changed this month").

Do not use this tool when:

the request is broad/general, across multiple metrics at once -> use read_health_data instead.

ParametersJSON Schema

Name	Required	Description
`metric`	Yes	One of steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms. Rejected if configured as private via HEALTH_PRIVATE_FIELDS.
`end_date`	No	Last day to include, formatted YYYY-MM-DD. Defaults to today.
`start_date`	No	First day to include, formatted YYYY-MM-DD. Defaults to 30 days before end_date.

Output Schema

ParametersJSON Schema

Name	Required	Description
`range`	Yes
`metric`	Yes
`points`	Yes
`evidence`	Yes	Coverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.

TDQS

A4.7/5.0

Behavior5/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 valuable context beyond annotations: a clear privacy note that returned data becomes part of the conversation sent to the configured model, and the behavioral scoping that it returns a single metric rather than the full multi-metric payload. No contradictions 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/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: the core purpose is in the first sentence, followed by clear when/do-not-use sections, then a privacy note. Every section earns its place, and there is no filler or repetition. The formatting with bullets makes it easily parseable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich input schema, output schema, and annotations, the description covers everything an agent needs: what the tool returns, when to use it, when not to, and the privacy implications of calling it. There are no significant gaps that would cause an agent to misinvoke or misuse the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100% and the schema already describes metric options, date formats, defaults, and privacy rejection behavior. The description adds example use cases like "show my weight over the last 30 days" that imply how start_date/end_date work, but it doesn't materially extend parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Read one metric's day-by-day values". It immediately distinguishes itself from the sibling read_health_data by noting what it omits ("without the other six metrics read_health_data always includes"). This makes it easy for an agent to select it over alternatives without examining schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description has explicit "Use this tool when" and "Do not use this tool when" sections. It gives concrete example user requests, names the alternative (read_health_data) for broad multi-metric requests, and even suggests a workflow (calling this before get_baseline or calculate_metric_trend). This is exactly the kind of decision-making guidance an agent needs.

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

get_metric_provenanceBreak a metric down by sourceA

Read-onlyIdempotent

Show one metric's raw measurements for one day, broken down by which source reported them — answers "which one is correct?" when e.g. an Apple Watch and a Garmin disagree on resting heart rate, instead of silently averaging two different devices into one number.

Do not use this tool when:

the user just wants a plain day-by-day history for the metric, with no need to see the per-source breakdown -> use get_metric_history instead.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	The day to inspect, formatted YYYY-MM-DD.
`metric`	Yes	Name of the metric to inspect, e.g. "resting_heart_rate".

Output Schema

ParametersJSON Schema

Name	Required	Description
`date`	Yes
`metric`	Yes
`sources`	Yes
`conflict`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, and the description adds meaningful context beyond that: it explains the data becomes part of the conversation and may be sent to a cloud model. This is a real behavioral disclosure about data flow and privacy that an agent could not infer from the schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured: purpose leads, a do-not-use block clearly distinguishes the sibling tool, and the privacy note is placed at the end. It is longer than strictly necessary because of the privacy explanation, but each paragraph earns its place and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple two-parameter input, full schema coverage, output schema presence, and complete annotations, the description covers what an agent needs to call this tool correctly. The only minor gap is that it does not spell out the exact return shape or whether source values are normalized, but the output schema covers that burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of the two parameters, including formats and examples for `date` and `metric`. The description does not add much beyond the schema, but the terms 'one day' and 'metric' reinforce the single-day, single-metric scope. The schema does the heavy lifting, so a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete action and resource: 'Show one metric's raw measurements for one day, broken down by which source reported them.' It directly distinguishes the tool from the sibling `get_metric_history` by emphasizing the per-source breakdown and the 'which one is correct?' use case. The verb and scope are specific enough that an agent can tell what it is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly names the alternative: 'Do not use this tool when... use `get_metric_history` instead.' It also gives a concrete triggering scenario (e.g., Apple Watch and Garmin disagreeing on resting heart rate), making both when-to-use and when-not-to-use clear.

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

get_recent_changesGet recent changesA

Read-onlyIdempotent

Scan every (non-private) metric for what's changed lately: a recent period vs. the four-times-as-long period before it (period-over-period shift), any anomalies inside the recent period, and a trend over it. The single best tool to start a "how have I been doing?" conversation with — it does the scanning across all metrics that would otherwise take one get_baseline/detect_metric_anomalies/calculate_metric_trend call per metric.

Do not use this tool when:

the user already named a specific metric and wants the full why-bundle for it (value, baseline, anomaly flag, trend, correlated metrics) -> use explain_metric_change instead.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Length of the "recent" window in days (default 7). The comparison baseline is the 4x-as-long period immediately before it, so a 7-day recent window compares against the preceding 28 days.

Output Schema

ParametersJSON Schema

Name	Required	Description
`changes`	Yes
`recent_range`	Yes
`baseline_range`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds a crucial behavioral note: the returned data becomes part of the conversation sent to the model, with a privacy implication. It also explains the scanning behavior across all metrics, which is beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: it opens with the core purpose, then gives explicit non-usage guidance, and ends with a privacy note. Each section earns its place without fluff, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that scans all metrics, it clearly explains what it does, when to use it, when not to, and the privacy implications. The output schema is provided elsewhere, so the description doesn't need to detail return values. It's complete for an agent to decide and call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter, days, is already fully described in the input schema (100% coverage) including its default and comparison baseline. The description doesn't add additional parameter details, matching the baseline of 3 when schema carries the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scans every non-private metric for changes, describing period-over-period shift, anomalies, and trend. It explicitly distinguishes itself from per-metric tools and names the alternative for specific-metric queries, so an agent can immediately understand its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit guidance: it's the best tool for a 'how have I been doing?' conversation, and it explicitly lists a condition to avoid (user named a specific metric) and directs to explain_metric_change. This gives both positive and negative usage context.

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

log_daily_metricLog a daily metricA

DestructiveIdempotent

Record one or more health metrics for a single day, creating that day's row if it doesn't already have one.

Only the metrics you pass are written — anything left as null is not touched, so logging just today's mood doesn't erase today's steps if they were set earlier. To undo a value logged by mistake, use clear_metric rather than trying to overwrite it with a placeholder.

Use this tool when:

the user is recording a simple day-level value for one of the nine fixed metrics below (e.g. "log my weight as 82 kg", "I walked 8,000 steps today").

Do not use this tool when:

the observation needs its own timestamp/source, or the day may have more than one reading of the same metric -> use log_measurement instead.
it's a workout/exercise session -> use log_workout_session instead (workout_minutes here is just the daily total, not the session itself).

ParametersJSON Schema

Name	Required	Description
`date`	Yes	The day to log, formatted YYYY-MM-DD.
`mood`	No	Mood rating on a 1-10 scale.
`steps`	No	Step count for the day. 0-200,000.
`hrv_ms`	No	Heart rate variability in milliseconds. 0-300.
`water_ml`	No	Water intake in millilitres. 0-10,000.
`weight_kg`	No	Body weight in kilograms. 1-500.
`heart_rate`	No	Non-resting heart rate reading in bpm. 20-250.
`sleep_hours`	No	Hours of sleep. 0-24.
`workout_minutes`	No	Minutes of exercise. 0-1,440.
`resting_heart_rate`	No	Resting heart rate in bpm. 20-250.

Output Schema

ParametersJSON Schema

Name	Required	Description
`row`	Yes
`logged`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the crucial merge behavior: null metrics are untouched and only passed metrics are written. It also adds a privacy note about data becoming part of the conversation and suggests clear_metric for undo. These are meaningful behavioral details that do not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a front-loaded core statement, a privacy section, a merge-behavior section, and explicit usage conditions. Despite its length, every section addresses a real agent decision and no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating tool with 10 parameters, the description covers sibling selection, partial-update semantics, privacy implications, and recovery via clear_metric. An output schema exists, so return-value details are not necessary. The tool is fully specified for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all 10 parameters with units and ranges, so the baseline is 3. The description adds context like 'workout_minutes here is just the daily total' and the null-not-touched rule, but does not need to repeat the schema's per-parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Record one or more health metrics for a single day', and explains the row-creation behavior. It also explicitly distinguishes itself from siblings like log_measurement and log_workout_session, so an agent can tell them apart without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description has clear 'Use this tool when' and 'Do not use this tool when' sections with concrete conditions and named alternatives. It routes timestamped readings to log_measurement and workout sessions to log_workout_session, leaving no ambiguity about selection.

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

log_measurementLog a raw measurementA

Record a single raw observation — one metric, one value, one point in time — rather than a whole day's summary. Use this instead of log_daily_metric when the source, exact time, or the fact that there were multiple readings that day matters (e.g. three separate workouts, or a wearable's periodic heart-rate samples).

Use this tool when:

recording one timestamped observation where the exact time, source, or possibility of multiple same-day readings matters (e.g. "record my blood pressure reading from my cuff at 7am").

Do not use this tool when:

it's just a single end-of-day value for a fixed metric -> use log_daily_metric instead.
it's a workout/exercise session -> use log_workout_session instead.

ParametersJSON Schema

Name	Required	Description
`unit`	No	Unit the value is in, e.g. "bpm", "kg". Optional.
`value`	Yes	The numeric reading.
`metric`	Yes	Name of the metric, e.g. "resting_heart_rate", "steps". Not free-form: must already have an entry in the aggregation_rules table (steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms, out of the box) — daily_metrics is a database-maintained projection over measurements (see db/schema.sql), so every metric written to it needs a known aggregation method (sum/mean/last) or there would be nothing telling the projection how to roll same-day readings up. metrics_schema lists the current set.
`source`	No	Where this came from, e.g. "Apple Watch", "manual". Optional.
`timestamp`	Yes	When the observation was taken, YYYY-MM-DD or a full ISO 8601 timestamp (YYYY-MM-DDTHH:MM:SS).
`source_type`	No	Category of source, e.g. "wearable", "manual", "app". Optional.

Output Schema

ParametersJSON Schema

Name	Required	Description
`measurement`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already convey write semantics (readOnlyHint=false), so the description adds useful context beyond them: a privacy caveat about data becoming part of the conversation sent to the model, local SQLite storage, and the fact that daily_metrics is a projection over measurements. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: the core definition and sibling distinction come first, followed by bulleted usage guidance and a privacy note. Every sentence adds value; there is no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with an output schema and annotations already present, the description covers purpose, when to use it, when not to use it, metric constraints via the schema, and privacy behavior. An agent has everything needed to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with rich parameter details (metric must exist in aggregation_rules, timestamp format, optional fields), so the description is not required to carry parameter documentation. It does not add much standalone parameter meaning beyond reinforcing the point-in-time nature of the reading.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('record') and resource ('a single raw observation') with clear scoping: one metric, one value, one point in time. It immediately distinguishes itself from a daily summary and from sibling tools, so an agent can tell log_measurement apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use this tool when' and 'Do not use this tool when' sections, naming concrete alternatives: log_daily_metric for end-of-day values and log_workout_session for workout sessions. The conditions for choosing this tool over alternatives are unambiguous.

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

log_workout_sessionLog a workout sessionA

Record one workout as a structured event — activity, timing, intensity, and heart-rate response — rather than folding it into the day's workout_minutes total. Use this alongside (not instead of) log_daily_metric/log_measurement for workout_minutes: this is what lets explain_metric_change say what the workout was, not just how long it ran. A day can have more than one session; each call adds a new row.

Use this tool when:

the user describes an actual workout/exercise session (e.g. "I went running for 40 minutes", "log today's strength workout").

Do not use this tool when:

the user only wants to record the day's total exercise minutes as a single number, with no activity type/timing/intensity -> use log_daily_metric (workout_minutes) or log_measurement instead.

ParametersJSON Schema

Name	Required	Description
`date`	Yes	The day the workout happened, YYYY-MM-DD.
`notes`	No	Free-text notes, e.g. route or how it felt. Optional.
`source`	No	Where this came from, e.g. "Apple Watch", "manual". Optional.
`intensity`	No	One of "low", "moderate", "high". Optional.
`start_time`	No	When it started, HH:MM (24-hour) or a full ISO timestamp. Optional.
`activity_type`	Yes	What kind of workout, e.g. "running", "cycling", "strength". Free-form.
`avg_heart_rate`	No	Average heart rate during the workout, bpm. Optional.
`max_heart_rate`	No	Peak heart rate during the workout, bpm. Optional.
`duration_minutes`	Yes	How long it lasted, in minutes.

Output Schema

ParametersJSON Schema

Name	Required	Description
`session`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, etc., but the description adds important behavior: 'each call adds a new row' clarifies non-idempotence specifics, and the privacy note about data becoming part of the conversation sent to the model is unique contextual disclosure. No contradictions 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a strong first sentence, followed by structured usage guidance and a privacy note. It is longer than the minimal two-sentence example, but every section contributes value given the tool's complexity and need to disambiguate from siblings. The explicitly labeled sections compensate for length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete enough for a 9-parameter tool with 100% schema coverage and an output schema. It covers when to use, when not, privacy implications, and multi-session behavior. No significant context is missing for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the schema fully documents each of the 9 parameters. The description adds a high-level grouping ('activity, timing, intensity, heart-rate response') but does not provide parameter-level semantics beyond the schema. Baseline of 3 applies since schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: 'Record one workout as a structured event — activity, timing, intensity, and heart-rate response.' It explicitly contrasts with log_daily_metric/log_measurement for workout_minutes and explains the relationship to explain_metric_change, distinguishing it from siblings without the need to open schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'Use this tool when' and 'Do not use this tool when' sections with concrete examples ('I went running for 40 minutes') and names the exact alternatives (log_daily_metric / log_measurement) for the excluded cases. This goes beyond mere context to actionable selection criteria.

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

read_health_dataRead health dataA

Read-onlyIdempotent

Read daily health metrics from the local database: steps, sleep hours, resting heart rate, weight (kg), workout minutes, mood, and water intake (ml).

Use this tool when:

the request is broad/general, across multiple metrics at once (e.g. "what health data do I have?", "overview of this week").

Do not use this tool when:

the user wants one specific metric's history/trend over time -> use get_metric_history instead.
the user wants raw/individual measurement rows (timestamp, source) -> use read_measurements instead.
the user wants workout sessions specifically -> use read_workout_sessions instead.
the user is asking why something changed, or wants a trend, anomaly, comparison, or correlation -> use explain_metric_change (one metric, one date) or get_recent_changes (scan across all metrics) instead.

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	No	Last day to include, formatted YYYY-MM-DD. Defaults to today.
`start_date`	No	First day to include, formatted YYYY-MM-DD. Defaults to 30 days before end_date. Ranges over ~10 years are rejected.

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes
`range`	Yes
`summary`	Yes
`coverage`	Yes	Multi-metric coverage for a Layer-1 result spanning several metrics at once. See evidence.build_coverage_summary for how each field is computed; unlike Evidence (one metric, gaps/freshness/recent_gap), this reports a coverage_percent per metric side by side.
`truncated`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds meaningful context beyond that: the data returned is daily aggregated metrics (not raw rows), the database is a local SQLite file, and returned data may be sent to the configured model — a privacy-relevant behavior an agent should weigh before invoking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but every section earns its place: a front-loaded metrics list, explicit routing rules, and a privacy note. The use of bullets under 'Use when' and 'Do not use when' makes the guidance scannable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the crowded sibling set (17 tools), the description fully disambiguates this tool from get_metric_history, read_measurements, read_workout_sessions, explain_metric_change, and get_recent_changes. Combined with rich annotations, full schema coverage, and an output schema, nothing needed to select or invoke the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents start_date and end_date with defaults and formatting. The description adds no new parameter-level detail, but under high schema coverage the baseline of 3 applies; no compensation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Read daily health metrics from the local database,' and lists the exact metrics covered (steps, sleep, heart rate, etc.). It also distinguishes itself from closely related siblings (get_metric_history, read_measurements, read_workout_sessions), so an agent knows exactly what this tool does and does not cover.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this tool when' section explicitly directs broad/general multi-metric requests to this tool, and the 'Do not use this tool when' section names four alternatives with the exact conditions that should route elsewhere. This is the strongest possible usage guidance — no inference is required.

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

read_measurementsRead raw measurementsA

Read-onlyIdempotent

Read individual measurement rows (not the daily_metrics aggregate), most recent first. Use this to see exactly when and where each reading came from, rather than just a day's summarized value.

Use this tool when:

the user wants raw/individual observations (e.g. "what measurements have I recorded?"), including their timestamp or source.

Do not use this tool when:

the user wants a broad, multi-metric overview -> use read_health_data instead.
the user wants one metric's day-by-day history -> use get_metric_history instead.
the user wants workout sessions -> use read_workout_sessions instead.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum rows to return (default 200).
`metric`	No	Only return this metric. Omit for all metrics.
`source`	No	Only return rows from this source, e.g. "Apple Watch". Omit for all sources.
`end_date`	No	Only return rows on/before this date (YYYY-MM-DD). Omit for no upper bound.
`start_date`	No	Only return rows on/after this date (YYYY-MM-DD). Omit for no lower bound.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`measurements`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark the tool readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds meaningful behavioral context beyond that: results are ordered most recent first, the tool returns raw rows rather than aggregates, and the privacy note discloses that returned data becomes part of the conversation sent to the model. 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/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then structured into clear usage and exclusions lists, followed by a well-scoped privacy note. Every sentence earns its place; the formatting makes it easy for an agent to scan for the decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, optional-parameter tool with a rich output schema and full schema coverage, the description provides everything an agent needs: what the tool returns, ordering behavior, when to prefer alternatives, and privacy implications. There is no meaningful gap in operational or decision context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all five optional parameters. The description adds only indirect context (e.g., that results include timestamps and sources) but does not need to explain parameter syntax or semantics since the schema already handles that burden. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') with a precise resource ('individual measurement rows'), and immediately distinguishes the tool from the daily_metrics aggregate. It also names the data orientation (most recent first) and what kind of detail it exposes (timestamp/source), making its purpose unambiguous and distinct from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool with a concrete user-intent example, and provides a dedicated 'Do not use this tool when' section that names three sibling alternatives (read_health_data, get_metric_history, read_workout_sessions). This gives an agent clear routing guidance with no inference required.

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

read_workout_sessionsRead workout sessionsA

Read-onlyIdempotent

Read individual workout sessions (not the daily_metrics workout_minutes total), most recent day first. Use this to see what each workout actually was — activity, timing, intensity, heart rate — rather than just a day's summed minutes.

Use this tool when:

the user asks about workouts/exercise sessions specifically (e.g. "what workouts did I do this week?", "show my recent gym sessions").

Do not use this tool when:

the user just wants the daily workout_minutes total, not individual sessions -> use read_health_data or get_metric_history instead.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum rows to return (default 200).
`end_date`	No	Only return sessions on/before this date (YYYY-MM-DD). Omit for no upper bound.
`start_date`	No	Only return sessions on/after this date (YYYY-MM-DD). Omit for no lower bound.
`activity_type`	No	Only return sessions of this activity type. Omit for all types.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`sessions`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds genuinely useful behavioral context: ordering is 'most recent day first,' the tool returns session-level detail rather than daily totals, and it discloses a privacy implication about data becoming part of the conversation. These are meaningful traits not captured by the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core definition, followed by structured usage guidance and a relevant privacy note. Every section earns its place: the first sentence states the tool's scope, the bullets give actionable routing rules, and the privacy note is important for local-vs-cloud model contexts. No filler is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich annotations, full parameter schema coverage, and presence of an output schema, the description supplies all remaining context an agent needs: when to use it, when not to, how results are ordered, and what data is returned. The alternative tools are explicitly named, so the surrounding tool ecosystem is adequately addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit, start_date, end_date, and activity_type fully. The description reinforces the overall intent but does not add parameter-specific detail beyond what the input schema provides, matching the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource: 'Read individual workout sessions,' and immediately disambiguates from the daily_metrics workout_minutes total. It also enumerates the meaningful fields returned (activity, timing, intensity, heart rate) and contrast with daily aggregates, making the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use this tool when' and 'Do not use this tool when' sections with concrete example queries and names the alternatives (read_health_data, get_metric_history). An agent can confidently route between this tool and its siblings without further inference.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.20Sep 20, 2026

Changedcalculate_metric_trend2 fields changed

addedOutput schema / properties / claim_decision

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "must_state": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "permitted_phrasing_class": {
+          "type": "string"
+        },
+        "template": {
+          "type": "string"
+        },
+        "tier": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "permitted_phrasing_class",
+        "must_state",
+        "template"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it."
+}

addedOutput schema / properties / evidence_profile

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "analysis": {
+          "type": "string"
+        },
+        "dimensions": {
+          "items": {
+            "properties": {
+              "can_block": {
+                "default": true,
+                "type": "boolean"
+              },
+              "details": {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              "dimension": {
+                "enum": [
+                  "sample",
+                  "temporal",
+                  "robustness",
+                  "missingness",
+                  "practical",
+                  "measurement_validity",
+                  "provenance"
+                ],
+                "type": "string"
+              },
+              "reason_codes": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "status": {
+                "enum": [
+                  "adequate",
+                  "negligible",
+                  "not_assessed",
+                  "weak",
+                  "concern",
+                  "blocking"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "dimension",
+              "status"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "effect": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "metric": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "metric",
+        "analysis",
+        "dimensions"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate."
+}

Changedcompare_metric_periods2 fields changed

addedOutput schema / properties / claim_decision

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "must_state": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "permitted_phrasing_class": {
+          "type": "string"
+        },
+        "template": {
+          "type": "string"
+        },
+        "tier": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "permitted_phrasing_class",
+        "must_state",
+        "template"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it."
+}

addedOutput schema / properties / evidence_profile

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "analysis": {
+          "type": "string"
+        },
+        "dimensions": {
+          "items": {
+            "properties": {
+              "can_block": {
+                "default": true,
+                "type": "boolean"
+              },
+              "details": {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              "dimension": {
+                "enum": [
+                  "sample",
+                  "temporal",
+                  "robustness",
+                  "missingness",
+                  "practical",
+                  "measurement_validity",
+                  "provenance"
+                ],
+                "type": "string"
+              },
+              "reason_codes": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "status": {
+                "enum": [
+                  "adequate",
+                  "negligible",
+                  "not_assessed",
+                  "weak",
+                  "concern",
+                  "blocking"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "dimension",
+              "status"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "effect": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "metric": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "metric",
+        "analysis",
+        "dimensions"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate."
+}

Changeddetect_metric_anomalies2 fields changed

addedOutput schema / properties / claim_decision

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "must_state": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "permitted_phrasing_class": {
+          "type": "string"
+        },
+        "template": {
+          "type": "string"
+        },
+        "tier": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "permitted_phrasing_class",
+        "must_state",
+        "template"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it."
+}

addedOutput schema / properties / evidence_profile

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "analysis": {
+          "type": "string"
+        },
+        "dimensions": {
+          "items": {
+            "properties": {
+              "can_block": {
+                "default": true,
+                "type": "boolean"
+              },
+              "details": {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              "dimension": {
+                "enum": [
+                  "sample",
+                  "temporal",
+                  "robustness",
+                  "missingness",
+                  "practical",
+                  "measurement_validity",
+                  "provenance"
+                ],
+                "type": "string"
+              },
+              "reason_codes": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "status": {
+                "enum": [
+                  "adequate",
+                  "negligible",
+                  "not_assessed",
+                  "weak",
+                  "concern",
+                  "blocking"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "dimension",
+              "status"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "effect": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "metric": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "metric",
+        "analysis",
+        "dimensions"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate."
+}

Changedexplain_metric_change6 fields changed

addedOutput schema / properties / claim_decision

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "must_state": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "permitted_phrasing_class": {
+          "type": "string"
+        },
+        "template": {
+          "type": "string"
+        },
+        "tier": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "permitted_phrasing_class",
+        "must_state",
+        "template"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it."
+}

addedOutput schema / properties / correlated_metrics / items / properties / claim_decision

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "must_state": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "permitted_phrasing_class": {
+          "type": "string"
+        },
+        "template": {
+          "type": "string"
+        },
+        "tier": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "permitted_phrasing_class",
+        "must_state",
+        "template"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it."
+}

addedOutput schema / properties / correlated_metrics / items / properties / evidence_profile

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "analysis": {
+          "type": "string"
+        },
+        "dimensions": {
+          "items": {
+            "properties": {
+              "can_block": {
+                "default": true,
+                "type": "boolean"
+              },
+              "details": {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              "dimension": {
+                "enum": [
+                  "sample",
+                  "temporal",
+                  "robustness",
+                  "missingness",
+                  "practical",
+                  "measurement_validity",
+                  "provenance"
+                ],
+                "type": "string"
+              },
+              "reason_codes": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "status": {
+                "enum": [
+                  "adequate",
+                  "negligible",
+                  "not_assessed",
+                  "weak",
+                  "concern",
+                  "blocking"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "dimension",
+              "status"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "effect": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "metric": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "metric",
+        "analysis",
+        "dimensions"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate."
+}

addedOutput schema / properties / evidence_profile

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "analysis": {
+          "type": "string"
+        },
+        "dimensions": {
+          "items": {
+            "properties": {
+              "can_block": {
+                "default": true,
+                "type": "boolean"
+              },
+              "details": {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              "dimension": {
+                "enum": [
+                  "sample",
+                  "temporal",
+                  "robustness",
+                  "missingness",
+                  "practical",
+                  "measurement_validity",
+                  "provenance"
+                ],
+                "type": "string"
+              },
+              "reason_codes": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "status": {
+                "enum": [
+                  "adequate",
+                  "negligible",
+                  "not_assessed",
+                  "weak",
+                  "concern",
+                  "blocking"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "dimension",
+              "status"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "effect": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "metric": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "metric",
+        "analysis",
+        "dimensions"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate."
+}

addedOutput schema / properties / trend_claim_decision

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "must_state": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "permitted_phrasing_class": {
+          "type": "string"
+        },
+        "template": {
+          "type": "string"
+        },
+        "tier": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "permitted_phrasing_class",
+        "must_state",
+        "template"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / trend_evidence_profile

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "analysis": {
+          "type": "string"
+        },
+        "dimensions": {
+          "items": {
+            "properties": {
+              "can_block": {
+                "default": true,
+                "type": "boolean"
+              },
+              "details": {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              "dimension": {
+                "enum": [
+                  "sample",
+                  "temporal",
+                  "robustness",
+                  "missingness",
+                  "practical",
+                  "measurement_validity",
+                  "provenance"
+                ],
+                "type": "string"
+              },
+              "reason_codes": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "status": {
+                "enum": [
+                  "adequate",
+                  "negligible",
+                  "not_assessed",
+                  "weak",
+                  "concern",
+                  "blocking"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "dimension",
+              "status"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "effect": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "metric": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "metric",
+        "analysis",
+        "dimensions"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedfind_metric_correlation2 fields changed

addedOutput schema / properties / claim_decision

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "must_state": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "permitted_phrasing_class": {
+          "type": "string"
+        },
+        "template": {
+          "type": "string"
+        },
+        "tier": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "permitted_phrasing_class",
+        "must_state",
+        "template"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it."
+}

addedOutput schema / properties / evidence_profile

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "analysis": {
+          "type": "string"
+        },
+        "dimensions": {
+          "items": {
+            "properties": {
+              "can_block": {
+                "default": true,
+                "type": "boolean"
+              },
+              "details": {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              "dimension": {
+                "enum": [
+                  "sample",
+                  "temporal",
+                  "robustness",
+                  "missingness",
+                  "practical",
+                  "measurement_validity",
+                  "provenance"
+                ],
+                "type": "string"
+              },
+              "reason_codes": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "status": {
+                "enum": [
+                  "adequate",
+                  "negligible",
+                  "not_assessed",
+                  "weak",
+                  "concern",
+                  "blocking"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "dimension",
+              "status"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "effect": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "metric": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "metric",
+        "analysis",
+        "dimensions"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate."
+}

Changedget_recent_changes2 fields changed

addedOutput schema / properties / changes / items / properties / claim_decision

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "must_state": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "permitted_phrasing_class": {
+          "type": "string"
+        },
+        "template": {
+          "type": "string"
+        },
+        "tier": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "permitted_phrasing_class",
+        "must_state",
+        "template"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "How strongly this result may be stated. tier is insufficient, suggestive, detectable_not_meaningful or supported; every entry in must_state has to be mentioned when reporting it."
+}

addedOutput schema / properties / changes / items / properties / evidence_profile

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "analysis": {
+          "type": "string"
+        },
+        "dimensions": {
+          "items": {
+            "properties": {
+              "can_block": {
+                "default": true,
+                "type": "boolean"
+              },
+              "details": {
+                "additionalProperties": true,
+                "type": "object"
+              },
+              "dimension": {
+                "enum": [
+                  "sample",
+                  "temporal",
+                  "robustness",
+                  "missingness",
+                  "practical",
+                  "measurement_validity",
+                  "provenance"
+                ],
+                "type": "string"
+              },
+              "reason_codes": {
+                "items": {
+                  "type": "string"
+                },
+                "type": "array"
+              },
+              "status": {
+                "enum": [
+                  "adequate",
+                  "negligible",
+                  "not_assessed",
+                  "weak",
+                  "concern",
+                  "blocking"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "dimension",
+              "status"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "effect": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "metric": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "metric",
+        "analysis",
+        "dimensions"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per-dimension evidence quality behind this result (sample, temporal, missingness, ...). Dimensions without an evaluator yet are 'not_assessed' and cap the claim, never count as adequate."
+}

4 tool updatesv1.0.19Sep 18, 2026

Changedaggregate_measurements2 fields changed

changedInput schema / properties / date / description

Previous value: -"The day to aggregate, formatted YYYY-MM-DD."New value: +"The day to preview, formatted YYYY-MM-DD."

changedInput schema / properties / source_priority / description

Previous value: -"Ordered list of source names, e.g. [\"Apple\nWatch\", \"Garmin\"]. For any metric with more than one source\nthat day, the first name in this list that's actually present\nwins and the other source's readings for that metric are\ndropped from the aggregate. Omit to fall back to whichever\nsource was imported most recently."New value: +"Ordered list of source names, e.g. [\"Apple\nWatch\", \"Garmin\"]. For any metric with more than one source\nthat day, the first name in this list that's actually present\nwins in \"aggregated\" and the other source's readings for that\nmetric are dropped from that preview. Omit to fall back to\nwhichever source was imported most recently. Never affects\n\"row\" — see above."

Changedexplain_metric_change3 fields changed

addedOutput schema / properties / conflicting_days

Added value: +{
+  "default": 0,
+  "type": "integer"
+}

addedOutput schema / properties / correlated_metrics / items / properties / sample_confidence
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / correlated_metrics / items / required

Previous value: -[
-  "metric_a",
-  "metric_b",
-  "lag_days",
-  "n"
-]New value: +[
+  "metric_a",
+  "metric_b",
+  "lag_days",
+  "n",
+  "sample_confidence"
+]

Changedfind_metric_correlation2 fields changed

addedOutput schema / properties / sample_confidence
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "metric_a",
-  "metric_b",
-  "lag_days",
-  "n"
-]New value: +[
+  "metric_a",
+  "metric_b",
+  "lag_days",
+  "n",
+  "sample_confidence"
+]

Changedlog_measurement1 field changed

changedInput schema / properties / metric / description

Previous value: -"Name of the metric, e.g. \"resting_heart_rate\", \"steps\".\nFree-form — not limited to daily_metrics' fixed columns."New value: +"Name of the metric, e.g. \"resting_heart_rate\", \"steps\".\nNot free-form: must already have an entry in the\naggregation_rules table (steps, sleep_hours,\nresting_heart_rate, weight_kg, workout_minutes, mood,\nwater_ml, heart_rate, hrv_ms, out of the box) — daily_metrics\nis a database-maintained projection over measurements (see\ndb/schema.sql), so every metric written to it needs a known\naggregation method (sum/mean/last) or there would be nothing\ntelling the projection how to roll same-day readings up.\nmetrics_schema lists the current set."

4 tool updatesv1.0.17Sep 16, 2026

Changedcalculate_metric_trend1 field changed

addedOutput schema / properties / trend / properties / span_days

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedexplain_metric_change1 field changed

addedOutput schema / properties / trend / properties / span_days

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedget_recent_changes2 fields changed

addedOutput schema / properties / changes / items / properties / evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / changes / items / required

Previous value: -[
-  "metric",
-  "kind",
-  "detail"
-]New value: +[
+  "metric",
+  "kind",
+  "detail",
+  "evidence"
+]

Changedread_health_data2 fields changed

addedOutput schema / properties / coverage

Added value: +{
+  "description": "Multi-metric coverage for a Layer-1 result spanning several metrics\nat once. See evidence.build_coverage_summary for how each field is\ncomputed; unlike Evidence (one metric, gaps/freshness/recent_gap),\nthis reports a coverage_percent per metric side by side.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_percent": {
+      "type": "number"
+    },
+    "days_expected": {
+      "type": "integer"
+    },
+    "days_with_data": {
+      "type": "integer"
+    },
+    "metrics": {
+      "additionalProperties": {
+        "type": "number"
+      },
+      "type": "object"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "period": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "period",
+    "days_expected",
+    "days_with_data",
+    "coverage_percent",
+    "missing_days",
+    "metrics",
+    "confidence"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "range",
-  "rows",
-  "truncated",
-  "summary"
-]New value: +[
+  "range",
+  "rows",
+  "truncated",
+  "summary",
+  "coverage"
+]

7 tool updatesSep 15, 2026

Changedcalculate_metric_trend2 fields changed

addedOutput schema / properties / evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "metric",
-  "range",
-  "trend"
-]New value: +[
+  "metric",
+  "range",
+  "trend",
+  "evidence"
+]

Changedcompare_metric_periods3 fields changed

addedOutput schema / properties / period_a_evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / period_b_evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "metric",
-  "period_a",
-  "period_b",
-  "period_a_stats",
-  "period_b_stats"
-]New value: +[
+  "metric",
+  "period_a",
+  "period_b",
+  "period_a_stats",
+  "period_b_stats",
+  "period_a_evidence",
+  "period_b_evidence"
+]

Changeddetect_metric_anomalies2 fields changed

addedOutput schema / properties / evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "metric",
-  "range",
-  "threshold",
-  "anomalies"
-]New value: +[
+  "metric",
+  "range",
+  "threshold",
+  "anomalies",
+  "evidence"
+]

Changedexplain_metric_change5 fields changed

addedOutput schema / properties / baseline_evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / correlated_metrics / items / properties / evidence_a

Added value: +{
+  "anyOf": [
+    {
+      "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+      "properties": {
+        "confidence": {
+          "type": "string"
+        },
+        "coverage_ratio": {
+          "type": "number"
+        },
+        "expected_days": {
+          "type": "integer"
+        },
+        "freshness_days": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "gaps": {
+          "items": {
+            "properties": {
+              "days": {
+                "type": "integer"
+              },
+              "end": {
+                "type": "string"
+              },
+              "start": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "start",
+              "end",
+              "days"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "measurement_count": {
+          "type": "integer"
+        },
+        "missing_days": {
+          "type": "integer"
+        },
+        "observed_days": {
+          "type": "integer"
+        },
+        "observed_end": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "observed_start": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "recent_gap_days": {
+          "type": "integer"
+        },
+        "requested_end": {
+          "type": "string"
+        },
+        "requested_start": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "requested_start",
+        "requested_end",
+        "expected_days",
+        "observed_days",
+        "coverage_ratio",
+        "missing_days",
+        "measurement_count",
+        "gaps",
+        "recent_gap_days",
+        "confidence"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / correlated_metrics / items / properties / evidence_b

Added value: +{
+  "anyOf": [
+    {
+      "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+      "properties": {
+        "confidence": {
+          "type": "string"
+        },
+        "coverage_ratio": {
+          "type": "number"
+        },
+        "expected_days": {
+          "type": "integer"
+        },
+        "freshness_days": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "gaps": {
+          "items": {
+            "properties": {
+              "days": {
+                "type": "integer"
+              },
+              "end": {
+                "type": "string"
+              },
+              "start": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "start",
+              "end",
+              "days"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "measurement_count": {
+          "type": "integer"
+        },
+        "missing_days": {
+          "type": "integer"
+        },
+        "observed_days": {
+          "type": "integer"
+        },
+        "observed_end": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "observed_start": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "recent_gap_days": {
+          "type": "integer"
+        },
+        "requested_end": {
+          "type": "string"
+        },
+        "requested_start": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "requested_start",
+        "requested_end",
+        "expected_days",
+        "observed_days",
+        "coverage_ratio",
+        "missing_days",
+        "measurement_count",
+        "gaps",
+        "recent_gap_days",
+        "confidence"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / trend_evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "metric",
-  "date",
-  "baseline_range",
-  "baseline",
-  "is_anomaly",
-  "trend",
-  "correlated_metrics",
-  "narrative_facts"
-]New value: +[
+  "metric",
+  "date",
+  "baseline_range",
+  "baseline",
+  "is_anomaly",
+  "trend",
+  "correlated_metrics",
+  "narrative_facts",
+  "baseline_evidence",
+  "trend_evidence"
+]

Changedfind_metric_correlation2 fields changed

addedOutput schema / properties / evidence_a

Added value: +{
+  "anyOf": [
+    {
+      "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+      "properties": {
+        "confidence": {
+          "type": "string"
+        },
+        "coverage_ratio": {
+          "type": "number"
+        },
+        "expected_days": {
+          "type": "integer"
+        },
+        "freshness_days": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "gaps": {
+          "items": {
+            "properties": {
+              "days": {
+                "type": "integer"
+              },
+              "end": {
+                "type": "string"
+              },
+              "start": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "start",
+              "end",
+              "days"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "measurement_count": {
+          "type": "integer"
+        },
+        "missing_days": {
+          "type": "integer"
+        },
+        "observed_days": {
+          "type": "integer"
+        },
+        "observed_end": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "observed_start": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "recent_gap_days": {
+          "type": "integer"
+        },
+        "requested_end": {
+          "type": "string"
+        },
+        "requested_start": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "requested_start",
+        "requested_end",
+        "expected_days",
+        "observed_days",
+        "coverage_ratio",
+        "missing_days",
+        "measurement_count",
+        "gaps",
+        "recent_gap_days",
+        "confidence"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / evidence_b

Added value: +{
+  "anyOf": [
+    {
+      "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+      "properties": {
+        "confidence": {
+          "type": "string"
+        },
+        "coverage_ratio": {
+          "type": "number"
+        },
+        "expected_days": {
+          "type": "integer"
+        },
+        "freshness_days": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "gaps": {
+          "items": {
+            "properties": {
+              "days": {
+                "type": "integer"
+              },
+              "end": {
+                "type": "string"
+              },
+              "start": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "start",
+              "end",
+              "days"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "measurement_count": {
+          "type": "integer"
+        },
+        "missing_days": {
+          "type": "integer"
+        },
+        "observed_days": {
+          "type": "integer"
+        },
+        "observed_end": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "observed_start": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "recent_gap_days": {
+          "type": "integer"
+        },
+        "requested_end": {
+          "type": "string"
+        },
+        "requested_start": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "requested_start",
+        "requested_end",
+        "expected_days",
+        "observed_days",
+        "coverage_ratio",
+        "missing_days",
+        "measurement_count",
+        "gaps",
+        "recent_gap_days",
+        "confidence"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Changedget_baseline2 fields changed

addedOutput schema / properties / evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "metric",
-  "range",
-  "baseline"
-]New value: +[
+  "metric",
+  "range",
+  "baseline",
+  "evidence"
+]

Changedget_metric_history2 fields changed

addedOutput schema / properties / evidence

Added value: +{
+  "description": "Coverage/quality of the data a single-metric analytical result is\nbased on. See evidence.build_evidence for how each field is computed.",
+  "properties": {
+    "confidence": {
+      "type": "string"
+    },
+    "coverage_ratio": {
+      "type": "number"
+    },
+    "expected_days": {
+      "type": "integer"
+    },
+    "freshness_days": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "gaps": {
+      "items": {
+        "properties": {
+          "days": {
+            "type": "integer"
+          },
+          "end": {
+            "type": "string"
+          },
+          "start": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "start",
+          "end",
+          "days"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "measurement_count": {
+      "type": "integer"
+    },
+    "missing_days": {
+      "type": "integer"
+    },
+    "observed_days": {
+      "type": "integer"
+    },
+    "observed_end": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "observed_start": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "recent_gap_days": {
+      "type": "integer"
+    },
+    "requested_end": {
+      "type": "string"
+    },
+    "requested_start": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "requested_start",
+    "requested_end",
+    "expected_days",
+    "observed_days",
+    "coverage_ratio",
+    "missing_days",
+    "measurement_count",
+    "gaps",
+    "recent_gap_days",
+    "confidence"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "metric",
-  "range",
-  "points"
-]New value: +[
+  "metric",
+  "range",
+  "points",
+  "evidence"
+]

27 tool updatesv1.0.16Sep 15, 2026

Addedaggregate_measurements
Addedcalculate_metric_trend
Removedclear_daily_metric
Removedclear_daily_metrics_range
Addedclear_metric
Addedcompare_metric_periods
Removeddelete_measurement
Removeddelete_workout
Addeddetect_metric_anomalies
Addedexplain_metric_change
Addedexport_health_data_csv
Addedfind_metric_correlation
Addedget_baseline
Addedget_metric_history
Addedget_metric_provenance
Addedget_recent_changes

Changedlog_daily_metric15 fields changed

addedInput schema / properties / date / description

Added value: +"The day to log, formatted YYYY-MM-DD."

addedInput schema / properties / heart_rate

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Non-resting heart rate reading in bpm. 20-250."
+}

addedInput schema / properties / hrv_ms

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Heart rate variability in milliseconds. 0-300."
+}

addedInput schema / properties / mood

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Mood rating on a 1-10 scale."
+}

addedInput schema / properties / resting_heart_rate / description
```
Added value: +"Resting heart rate in bpm. 20-250."
```
addedInput schema / properties / sleep_hours / description
```
Added value: +"Hours of sleep. 0-24."
```

addedInput schema / properties / steps / description

Added value: +"Step count for the day. 0-200,000."

addedInput schema / properties / water_ml

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Water intake in millilitres. 0-10,000."
+}

addedInput schema / properties / weight_kg

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Body weight in kilograms. 1-500."
+}

addedInput schema / properties / workout_minutes

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Minutes of exercise. 0-1,440."
+}

addedOutput schema / properties / logged

Added value: +{
+  "additionalProperties": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "number"
+      }
+    ]
+  },
+  "type": "object"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / row

Added value: +{
+  "properties": {
+    "date": {
+      "type": "string"
+    },
+    "heart_rate": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "hrv_ms": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "mood": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "resting_heart_rate": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "sleep_hours": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "steps": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "water_ml": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "weight_kg": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "workout_minutes": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    }
+  },
+  "required": [
+    "date"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "logged",
+  "row"
+]

removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

Changedlog_measurement14 fields changed

removedInput schema / properties / date

Removed value: -{
-  "type": "string"
-}

addedInput schema / properties / metric

Added value: +{
+  "description": "Name of the metric, e.g. \"resting_heart_rate\", \"steps\".\nFree-form — not limited to daily_metrics' fixed columns.",
+  "type": "string"
+}

removedInput schema / properties / metric_name
```
Removed value: -{
-  "type": "string"
-}
```

removedInput schema / properties / notes

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

addedInput schema / properties / source

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Where this came from, e.g. \"Apple Watch\", \"manual\". Optional."
+}

addedInput schema / properties / source_type

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Category of source, e.g. \"wearable\", \"manual\", \"app\". Optional."
+}

addedInput schema / properties / timestamp

Added value: +{
+  "description": "When the observation was taken, YYYY-MM-DD or a full\nISO 8601 timestamp (YYYY-MM-DDTHH:MM:SS).",
+  "type": "string"
+}

addedInput schema / properties / unit / description

Added value: +"Unit the value is in, e.g. \"bpm\", \"kg\". Optional."

addedInput schema / properties / value / description
```
Added value: +"The numeric reading."
```

changedInput schema / required

Previous value: -[
-  "date",
-  "metric_name",
-  "value"
-]New value: +[
+  "timestamp",
+  "metric",
+  "value"
+]

addedOutput schema / properties / measurement

Added value: +{
+  "properties": {
+    "created_at": {
+      "type": "string"
+    },
+    "id": {
+      "type": "integer"
+    },
+    "metric": {
+      "type": "string"
+    },
+    "source": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "source_type": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "timestamp": {
+      "type": "string"
+    },
+    "unit": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "value": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "id",
+    "timestamp",
+    "metric",
+    "value",
+    "created_at"
+  ],
+  "type": "object"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "measurement"
+]

removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

Removedlog_workout
Addedlog_workout_session
Removedread_finance_data

Changedread_health_data9 fields changed

addedInput schema / properties / end_date / description

Added value: +"Last day to include, formatted YYYY-MM-DD. Defaults to today."

addedInput schema / properties / start_date / description

Added value: +"First day to include, formatted YYYY-MM-DD.\nDefaults to 30 days before end_date. Ranges over ~10 years are rejected."

addedOutput schema / properties / range

Added value: +{
+  "properties": {
+    "end_date": {
+      "type": "string"
+    },
+    "start_date": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "start_date",
+    "end_date"
+  ],
+  "type": "object"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / rows

Added value: +{
+  "items": {
+    "properties": {
+      "date": {
+        "type": "string"
+      },
+      "heart_rate": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "hrv_ms": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "mood": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "resting_heart_rate": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "sleep_hours": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "steps": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "water_ml": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "weight_kg": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "workout_minutes": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      }
+    },
+    "required": [
+      "date"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / summary

Added value: +{
+  "properties": {
+    "days_with_data": {
+      "type": "integer"
+    },
+    "heart_rate": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "hrv_ms": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "mood": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "resting_heart_rate": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "sleep_hours": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "steps": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "water_ml": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "weight_kg": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "workout_minutes": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "days_with_data",
+    "steps",
+    "sleep_hours",
+    "resting_heart_rate",
+    "weight_kg",
+    "workout_minutes",
+    "mood",
+    "water_ml",
+    "heart_rate",
+    "hrv_ms"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / truncated
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "range",
+  "rows",
+  "truncated",
+  "summary"
+]

removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

Addedread_measurements
Addedread_workout_sessions
Removedupdate_daily_metric
Removedupdate_measurement
Removedupdate_workout

27 tool updatesv1.0.15Sep 15, 2026

Removedaggregate_measurements
Removedcalculate_metric_trend
Addedclear_daily_metric
Addedclear_daily_metrics_range
Removedclear_metric
Removedcompare_metric_periods
Addeddelete_measurement
Addeddelete_workout
Removeddetect_metric_anomalies
Removedexplain_metric_change
Removedexport_health_data_csv
Removedfind_metric_correlation
Removedget_baseline
Removedget_metric_history
Removedget_metric_provenance
Removedget_recent_changes

Changedlog_daily_metric15 fields changed

removedInput schema / properties / date / description

Removed value: -"The day to log, formatted YYYY-MM-DD."

removedInput schema / properties / heart_rate

Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Non-resting heart rate reading in bpm. 20-250."
-}

removedInput schema / properties / hrv_ms

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Heart rate variability in milliseconds. 0-300."
-}

removedInput schema / properties / mood

Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Mood rating on a 1-10 scale."
-}

removedInput schema / properties / resting_heart_rate / description
```
Removed value: -"Resting heart rate in bpm. 20-250."
```
removedInput schema / properties / sleep_hours / description
```
Removed value: -"Hours of sleep. 0-24."
```

removedInput schema / properties / steps / description

Removed value: -"Step count for the day. 0-200,000."

removedInput schema / properties / water_ml

Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Water intake in millilitres. 0-10,000."
-}

removedInput schema / properties / weight_kg

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Body weight in kilograms. 1-500."
-}

removedInput schema / properties / workout_minutes

Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Minutes of exercise. 0-1,440."
-}

removedOutput schema / properties / logged

Removed value: -{
-  "additionalProperties": {
-    "anyOf": [
-      {
-        "type": "integer"
-      },
-      {
-        "type": "number"
-      }
-    ]
-  },
-  "type": "object"
-}

addedOutput schema / properties / result
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / row

Removed value: -{
-  "properties": {
-    "date": {
-      "type": "string"
-    },
-    "heart_rate": {
-      "anyOf": [
-        {
-          "type": "integer"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "hrv_ms": {
-      "anyOf": [
-        {
-          "type": "number"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "mood": {
-      "anyOf": [
-        {
-          "type": "integer"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "resting_heart_rate": {
-      "anyOf": [
-        {
-          "type": "integer"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "sleep_hours": {
-      "anyOf": [
-        {
-          "type": "number"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "steps": {
-      "anyOf": [
-        {
-          "type": "integer"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "water_ml": {
-      "anyOf": [
-        {
-          "type": "integer"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "weight_kg": {
-      "anyOf": [
-        {
-          "type": "number"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "workout_minutes": {
-      "anyOf": [
-        {
-          "type": "integer"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    }
-  },
-  "required": [
-    "date"
-  ],
-  "type": "object"
-}

changedOutput schema / required

Previous value: -[
-  "logged",
-  "row"
-]New value: +[
+  "result"
+]

addedOutput schema / x-fastmcp-wrap-result
```
Added value: +true
```

Changedlog_measurement14 fields changed

addedInput schema / properties / date
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / metric

Removed value: -{
-  "description": "Name of the metric, e.g. \"resting_heart_rate\", \"steps\".\nFree-form — not limited to daily_metrics' fixed columns.",
-  "type": "string"
-}

addedInput schema / properties / metric_name
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / notes

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

removedInput schema / properties / source

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Where this came from, e.g. \"Apple Watch\", \"manual\". Optional."
-}

removedInput schema / properties / source_type

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Category of source, e.g. \"wearable\", \"manual\", \"app\". Optional."
-}

removedInput schema / properties / timestamp

Removed value: -{
-  "description": "When the observation was taken, YYYY-MM-DD or a full\nISO 8601 timestamp (YYYY-MM-DDTHH:MM:SS).",
-  "type": "string"
-}

removedInput schema / properties / unit / description

Removed value: -"Unit the value is in, e.g. \"bpm\", \"kg\". Optional."

removedInput schema / properties / value / description
```
Removed value: -"The numeric reading."
```

changedInput schema / required

Previous value: -[
-  "timestamp",
-  "metric",
-  "value"
-]New value: +[
+  "date",
+  "metric_name",
+  "value"
+]

removedOutput schema / properties / measurement

Removed value: -{
-  "properties": {
-    "created_at": {
-      "type": "string"
-    },
-    "id": {
-      "type": "integer"
-    },
-    "metric": {
-      "type": "string"
-    },
-    "source": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "source_type": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "timestamp": {
-      "type": "string"
-    },
-    "unit": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "value": {
-      "type": "number"
-    }
-  },
-  "required": [
-    "id",
-    "timestamp",
-    "metric",
-    "value",
-    "created_at"
-  ],
-  "type": "object"
-}

addedOutput schema / properties / result
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "measurement"
-]New value: +[
+  "result"
+]

addedOutput schema / x-fastmcp-wrap-result
```
Added value: +true
```

Addedlog_workout
Removedlog_workout_session
Addedread_finance_data

Changedread_health_data9 fields changed

removedInput schema / properties / end_date / description

Removed value: -"Last day to include, formatted YYYY-MM-DD. Defaults to today."

removedInput schema / properties / start_date / description

Removed value: -"First day to include, formatted YYYY-MM-DD.\nDefaults to 30 days before end_date. Ranges over ~10 years are rejected."

removedOutput schema / properties / range

Removed value: -{
-  "properties": {
-    "end_date": {
-      "type": "string"
-    },
-    "start_date": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "start_date",
-    "end_date"
-  ],
-  "type": "object"
-}

addedOutput schema / properties / result
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / rows

Removed value: -{
-  "items": {
-    "properties": {
-      "date": {
-        "type": "string"
-      },
-      "heart_rate": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "hrv_ms": {
-        "anyOf": [
-          {
-            "type": "number"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "mood": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "resting_heart_rate": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "sleep_hours": {
-        "anyOf": [
-          {
-            "type": "number"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "steps": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "water_ml": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "weight_kg": {
-        "anyOf": [
-          {
-            "type": "number"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "workout_minutes": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      }
-    },
-    "required": [
-      "date"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

removedOutput schema / properties / summary

Removed value: -{
-  "properties": {
-    "days_with_data": {
-      "type": "integer"
-    },
-    "heart_rate": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    },
-    "hrv_ms": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    },
-    "mood": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    },
-    "resting_heart_rate": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    },
-    "sleep_hours": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    },
-    "steps": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    },
-    "water_ml": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    },
-    "weight_kg": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    },
-    "workout_minutes": {
-      "properties": {
-        "avg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "max": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        },
-        "min": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ],
-          "default": null
-        }
-      },
-      "type": "object"
-    }
-  },
-  "required": [
-    "days_with_data",
-    "steps",
-    "sleep_hours",
-    "resting_heart_rate",
-    "weight_kg",
-    "workout_minutes",
-    "mood",
-    "water_ml",
-    "heart_rate",
-    "hrv_ms"
-  ],
-  "type": "object"
-}

removedOutput schema / properties / truncated
```
Removed value: -{
-  "type": "boolean"
-}
```

changedOutput schema / required

Previous value: -[
-  "range",
-  "rows",
-  "truncated",
-  "summary"
-]New value: +[
+  "result"
+]

addedOutput schema / x-fastmcp-wrap-result
```
Added value: +true
```

Removedread_measurements
Removedread_workout_sessions
Addedupdate_daily_metric
Addedupdate_measurement
Addedupdate_workout

3 tool updatesv0.3.0Sep 13, 2026

Changedexplain_metric_change1 field changed

addedOutput schema / properties / sessions

Added value: +{
+  "default": [],
+  "items": {
+    "properties": {
+      "activity_type": {
+        "type": "string"
+      },
+      "avg_heart_rate": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "created_at": {
+        "type": "string"
+      },
+      "date": {
+        "type": "string"
+      },
+      "duration_minutes": {
+        "type": "integer"
+      },
+      "id": {
+        "type": "integer"
+      },
+      "intensity": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "max_heart_rate": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "notes": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "source": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "start_time": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      }
+    },
+    "required": [
+      "id",
+      "date",
+      "activity_type",
+      "duration_minutes",
+      "created_at"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Addedlog_workout_session
Addedread_workout_sessions

16 tool updatesv1.0.11Sep 13, 2026

Addedaggregate_measurements
Addedcalculate_metric_trend

Changedclear_metric2 fields changed

changedInput schema / properties / field / description

Previous value: -"Which metric to blank out. One of: steps, sleep_hours,\nresting_heart_rate, weight_kg, workout_minutes, mood, water_ml."New value: +"Which metric to blank out. One of: steps, sleep_hours,\nresting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms."

changedOutput schema / properties / row / anyOf

Previous value: -[
-  {
-    "properties": {
-      "date": {
-        "type": "string"
-      },
-      "mood": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "resting_heart_rate": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "sleep_hours": {
-        "anyOf": [
-          {
-            "type": "number"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "steps": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "water_ml": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "weight_kg": {
-        "anyOf": [
-          {
-            "type": "number"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      },
-      "workout_minutes": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null
-      }
-    },
-    "required": [
-      "date"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "properties": {
+      "date": {
+        "type": "string"
+      },
+      "heart_rate": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "hrv_ms": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "mood": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "resting_heart_rate": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "sleep_hours": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "steps": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "water_ml": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "weight_kg": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "workout_minutes": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      }
+    },
+    "required": [
+      "date"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

Addedcompare_metric_periods
Addeddetect_metric_anomalies
Addedexplain_metric_change
Addedexport_health_data_csv
Addedfind_metric_correlation
Addedget_baseline
Addedget_metric_history
Addedget_metric_provenance
Addedget_recent_changes

Changedlog_daily_metric4 fields changed

addedInput schema / properties / heart_rate

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Non-resting heart rate reading in bpm. 20-250."
+}

addedInput schema / properties / hrv_ms

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Heart rate variability in milliseconds. 0-300."
+}

addedOutput schema / properties / row / properties / heart_rate

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / row / properties / hrv_ms

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Addedlog_measurement

Changedread_health_data5 fields changed

addedOutput schema / properties / rows / items / properties / heart_rate

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / rows / items / properties / hrv_ms

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedOutput schema / properties / summary / properties / heart_rate

Added value: +{
+  "properties": {
+    "avg": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "max": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "min": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / summary / properties / hrv_ms

Added value: +{
+  "properties": {
+    "avg": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "max": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "min": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    }
+  },
+  "type": "object"
+}

changedOutput schema / properties / summary / required

Previous value: -[
-  "days_with_data",
-  "steps",
-  "sleep_hours",
-  "resting_heart_rate",
-  "weight_kg",
-  "workout_minutes",
-  "mood",
-  "water_ml"
-]New value: +[
+  "days_with_data",
+  "steps",
+  "sleep_hours",
+  "resting_heart_rate",
+  "weight_kg",
+  "workout_minutes",
+  "mood",
+  "water_ml",
+  "heart_rate",
+  "hrv_ms"
+]

Addedread_measurements

3 tool updatesv1.0.8Sep 7, 2026

Changedclear_metric6 fields changed

addedOutput schema / properties / cleared
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / note

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / row

Added value: +{
+  "anyOf": [
+    {
+      "properties": {
+        "date": {
+          "type": "string"
+        },
+        "mood": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "resting_heart_rate": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "sleep_hours": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "steps": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "water_ml": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "weight_kg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "workout_minutes": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "required": [
+        "date"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "cleared"
+]

removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

Changedlog_daily_metric5 fields changed

addedOutput schema / properties / logged

Added value: +{
+  "additionalProperties": {
+    "anyOf": [
+      {
+        "type": "integer"
+      },
+      {
+        "type": "number"
+      }
+    ]
+  },
+  "type": "object"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / row

Added value: +{
+  "properties": {
+    "date": {
+      "type": "string"
+    },
+    "mood": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "resting_heart_rate": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "sleep_hours": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "steps": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "water_ml": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "weight_kg": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    },
+    "workout_minutes": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null
+    }
+  },
+  "required": [
+    "date"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "logged",
+  "row"
+]

removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

Changedread_health_data7 fields changed

addedOutput schema / properties / range

Added value: +{
+  "properties": {
+    "end_date": {
+      "type": "string"
+    },
+    "start_date": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "start_date",
+    "end_date"
+  ],
+  "type": "object"
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / rows

Added value: +{
+  "items": {
+    "properties": {
+      "date": {
+        "type": "string"
+      },
+      "mood": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "resting_heart_rate": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "sleep_hours": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "steps": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "water_ml": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "weight_kg": {
+        "anyOf": [
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "workout_minutes": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      }
+    },
+    "required": [
+      "date"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / summary

Added value: +{
+  "properties": {
+    "days_with_data": {
+      "type": "integer"
+    },
+    "mood": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "resting_heart_rate": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "sleep_hours": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "steps": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "water_ml": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "weight_kg": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    },
+    "workout_minutes": {
+      "properties": {
+        "avg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "max": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        },
+        "min": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "days_with_data",
+    "steps",
+    "sleep_hours",
+    "resting_heart_rate",
+    "weight_kg",
+    "workout_minutes",
+    "mood",
+    "water_ml"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / truncated
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "range",
+  "rows",
+  "truncated",
+  "summary"
+]

removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

2 tool updatesv1.0.4Sep 2, 2026
- Addedclear_metric
- Addedlog_daily_metric

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-09-21 10:30 across 18 tools

Disambiguation5/5

Each tool targets a distinct action-resource pair: logging vs reading vs analyzing, and daily metrics vs raw measurements vs workout sessions vs cross-metric analytics. The descriptions reinforce this with explicit 'use when' / 'do not use when' cross-references that point to the correct alternative, so no two tools genuinely overlap.

Naming Consistency5/5

All 18 tools follow a consistent snake_case verb_noun pattern, with stable verb groups (log_*, read_*, get_*, calculate_, compare_, find_, detect_, explain_, clear_, aggregate_, export_). This makes the set highly predictable and easy to navigate.

Tool Count4/5

At 18 tools, the set is slightly above the ideal 3-15 band, but the count is justified by the domain's breadth: logging, reading, measurement provenance, and analytics each form a coherent cluster. No tool feels redundant, though the total is on the heavier side.

Completeness4/5

The server covers the full lifecycle for daily metrics (log, read, clear, export) and provides a rich analytics surface including baseline, trend, anomalies, correlation, period comparison, and an explainable-change bundle. The notable gap is the inability to delete or update logged workout sessions, and no direct update path for measurements, but these are workable limitations.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Era ContextOAuth
app.era
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Finance Knowledge & Memory
1
mcpmyadminOAuth
ai.mcpmyadmin
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Databases Security
2
MCP Hub — your personal data for AIOAuth
church.ai.mcp
Your personal data for AI — Telegram, bank, courses, Zoom & more, scoped to you.
Communication Text Summarization App Automation
2
Dot - AI Data AnalystOAuth
io.github.zurferr
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Search Databases Data Visualization
2

Related MCP Servers

Apple Health MCP Server
Health & Wellness Databases App Automation
neiltron
A
license
A
quality
A
maintenance
An MCP server that allows users to query and analyze their Apple Health data using SQL and natural language, utilizing DuckDB for fast and efficient health data analysis.
Updated 3 days ago (2026-09-20 04:53 UTC)
2
3
73 npm
568
MIT
apple-health-mcp
Health & Wellness Fitness Tracking Databases
smarzola
A
license
Not graded
quality
C
maintenance
Loads Apple Health export data into a local SQLite database and exposes tools to query health metrics and workout records via natural language.
Updated 3 months ago (2026-06-21 09:22 UTC)
3
MIT
mydata
Finance Fitness Tracking Databases
bibekg
A
license
Not graded
quality
D
maintenance
Enables querying personal data synced from services like Lunch Money and Strava using SQL via Claude.
Updated 8 months ago (2026-02-01 02:37 UTC)
15 npm
1
MIT
mcp-sqlite-tools-plus
Databases Data Platforms
MauricioPerera
A
license
B
quality
D
maintenance
Enables AI agents to interact with local SQLite databases with full CRUD, schema introspection, foreign key relations, generated columns, and multi-format import/export (CSV, JSON, XLSX) through natural language.
Updated 3 months ago (2026-06-29 02:40 UTC)
26
10 npm
MIT