Skip to main content
Glama
Thecimal

Quantified Self MCP Server

by Thecimal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Aggregate measurements into a day

aggregate_measurements
Idempotent

Roll up one day's raw measurements into a daily_metrics row, summing activities, averaging vitals, and resolving conflicting sources by priority.

Instructions

Roll up one day's raw measurements into that day's daily_metrics row, so existing analytics tools (which all read daily_metrics) benefit from data logged via log_measurement. Steps/water/workout_minutes sum across the day, resting_heart_rate/mood average, weight_kg takes the latest reading — see logic.MEASUREMENT_AGGREGATION.

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, then pass source_priority to pick a winner rather than blending two devices' readings into one meaningless average.

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 aggregate, 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 and the other source's readings for that metric are dropped from the aggregate. Omit to fall back to whichever source was imported most recently.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowYes
dateYes
aggregatedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.16
  2. Removedv1.0.15
  3. Addedv1.0.11

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true), it discloses the per-metric aggregation semantics (sums, averages, latest reading), the fallback to most-recently-imported source when source_priority is omitted, and a privacy caveat about data reaching a cloud model. That is rich behavioral context an agent cannot get from structured fields.

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?

Front-loaded with the core action and aggregation rules, then the multi-source caveat, then the privacy note. Every section is useful but the privacy paragraph is lengthy relative to the calling decision, making it slightly heavier than needed.

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?

An output schema exists so return values need not be described, and the description covers aggregation logic, the alternative tool, parameter semantics, and the privacy implication. Nothing needed to invoke it correctly 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%, so baseline is 3, but the description adds genuine meaning: it explains why source_priority exists ('rather than blending two devices' readings into one meaningless average') and the resolution order, which the schema states tersely as first-present-wins.

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 ('Roll up one day's raw measurements into that day's daily_metrics row') and explicitly frames the downstream beneficiary (analytics tools reading daily_metrics). It also distinguishes itself from log_measurement, which is named as the source of the data being aggregated.

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?

Gives clear context: run it to make log_measurement data visible to analytics, and route to get_metric_provenance first when multiple sources disagree, then use source_priority to pick a winner. No explicit 'when not to use' but the multi-source branch is a genuine alternative-selection rule.

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