Skip to main content
Glama
Quantified Self MCP Server

Quantified Self MCP Server

Preview a source-priority resolution of a day's measurements

aggregate_measurements
Read-onlyIdempotent

Preview a day's aggregated measurements using source priority to resolve conflicts, and compare against the actual stored daily metrics.

Instructions

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 the moment it's written, using each metric's fixed aggregation method: summed for steps, sleep_hours, workout_minutes and water_ml; averaged for resting_heart_rate, mood, heart_rate and hrv_ms; the latest reading for weight_kg (see aggregation_rules). When a metric has measurements from more than one source on a day, the projection uses only one source's observations — never a blend of devices. It takes the highest-ranked present source in the stored source priority list (manual log_daily_metric entries rank first by default); if none is ranked, the source that observed the most hours of that day, then the one with the latest observation, then by name. This tool writes nothing: "aggregated" previews what the source_priority you pass would produce; "row" is the real, currently-stored value, which differs from "aggregated" whenever the stored priority differs from the one you pass.

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.

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date": "<date>"
    },
    "name": "aggregate_measurements"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesThe day to preview, formatted YYYY-MM-DD.
source_priorityNoOrdered 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 use the stored priority list and the same fallback the stored projection uses. Never affects "row" — see above.

Output Schema

NameRequiredDescriptionDefault
rowYes
dateYes
aggregatedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.23
    • 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 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."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 use the stored\npriority list and the same fallback the stored projection\nuses. Never affects \"row\" — see above."
  2. Changed2 schema fields changedv1.0.19
    • 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."
  3. Addedv1.0.16
  4. Removedv1.0.15
  5. Addedv1.0.11

TDQS

A4.5/5.0
Behavior5/5

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

Far beyond the annotations, it discloses the resolution algorithm (highest-ranked present source in the stored priority list, manual entries ranked first, then most hours observed, then latest observation, then name), that sources are never blended, and the crucial "aggregated" vs "row" divergence when the passed priority differs from the stored one. It also flags a real behavioral trait annotations cannot express: returned data enters the conversation sent to the calling client's model, which matters for cloud-hosted models. The "writes nothing" line merely restates readOnlyHint, but the rest is substantive.

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

Conciseness3/5

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

The purpose is front-loaded and no sentence is pure filler, but the middle paragraph is a long digression into how daily_metrics is maintained ("see db/schema.sql", per-metric aggregation methods, multi-level tie-breaking) that a caller largely does not need in order to invoke a two-parameter preview. Source-file references and multi-clause em-dash sentences make it denser than the tool's complexity warrants.

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, two-parameter preview with a full output schema and complete schema coverage, nothing an agent needs is missing: it knows what is computed, what the parameter changes, what is never changed, and what to check first when sources conflict. The privacy caveat is a bonus that closes the last ambiguity about handling the returned data.

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% and the schema description already explains the ordering/dropping behavior and that "row" is never affected, so the schema does most of the work. The description adds real meaning on top: the explicit consequence that non-winning sources' readings are dropped from the preview, and that omitting the parameter falls back to the stored priority with the same tie-breaking chain used by the projection.

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?

"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" gives a specific verb (preview), a specific resource (a day's measurements plus the daily_metrics projection), and explicitly separates the "aggregated" preview from the "row" value. This is clearly distinct from siblings like read_health_data or get_metric_history, which return data rather than a hypothetical resolution.

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?

It states the core usage context (preview a hypothetical source_priority before relying on it) and names a concrete prerequisite alternative: "use get_metric_provenance first" when multiple sources disagree. It also implicitly excludes writes ("This tool writes nothing"), but gives no explicit when-not-to-use guidance relative to read_health_data or get_metric_history, which would have made this a 5.

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