Skip to main content
Glama
Thecimal

Quantified Self MCP Server

by Thecimal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

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

aggregate_measurements
Read-onlyIdempotent

Preview how daily measurements would aggregate if conflicting sources were resolved by your chosen priority, and compare with 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 (sum/mean/last — see aggregation_rules, or get_baseline's "method" field). 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.

Input Schema

TableJSON 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

TableJSON 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.4/5.0
Behavior5/5

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

The description goes far beyond the annotations' readOnlyHint/destructiveHint by explaining that the tool writes nothing, how the stored daily_metrics projection is maintained, the full source-selection fallback algorithm, how 'aggregated' differs from 'row', and a privacy caveat about data entering the conversation. This is rich behavioral context that an agent genuinely needs.

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 structured into clear paragraphs covering mechanics, edge-case guidance, and privacy. It is somewhat long for a two-parameter read-only tool, and a small amount of content overlaps with the schema descriptions, but it is dense and every section earns its place.

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, the output schema exists, and the annotations already cover read-only/idempotent safety, the description supplies everything an agent needs: the exact computation semantics, the fallback ranking logic, the distinction between hypothetical and actual values, a cross-tool precondition, and a privacy note. No critical context 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 already provides 100% parameter coverage, including detailed descriptions of date format, source_priority ordering, omission behavior, and the fact that source_priority never affects 'row'. The tool description adds surrounding conceptual context about the stored priority list but does not need to add parameter syntax. 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 precise 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.' It clearly separates the hypothetical 'aggregated' result from the real stored 'row' value, making the tool's unique role unmistakable among the many metric-reading siblings.

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

Usage Guidelines4/5

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

The description gives concrete conditional guidance: if a metric has measurements from more than one source, 'use get_metric_provenance first to see whether they actually disagree.' This tells the agent when to check another tool before invoking this one. It does not exhaustively enumerate when not to use the tool or name all alternative tools, but the provided workflow is clear and actionable.

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

Deploy Server

Other Tools