Skip to main content
Glama
Thecimal

Quantified Self MCP Server

by Thecimal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Read raw measurements

read_measurements
Read-onlyIdempotent

Fetch individual health measurement rows, most recent first, with timestamps and sources. Use for raw observations, not daily aggregates.

Instructions

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.

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
limitNoMaximum rows to return (default 200).
metricNoOnly return this metric. Omit for all metrics.
sourceNoOnly return rows from this source, e.g. "Apple Watch". Omit for all sources.
end_dateNoOnly return rows on/before this date (YYYY-MM-DD). Omit for no upper bound.
start_dateNoOnly return rows on/after this date (YYYY-MM-DD). Omit for no lower bound.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
measurementsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.29
    • addedOutput schema / properties / measurements / items / properties / value / anyOf
      Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedOutput schema / properties / measurements / items / properties / value / type
      Removed value: -"number"
  2. Addedv1.0.16
  3. Removedv1.0.15
  4. Addedv1.0.11

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious context: results are ordered most-recent-first, and the privacy note discloses that returned data becomes part of the conversation sent to the configured model, which is a data-egress trait not conveyed by any annotation or schema.

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 and scope are front-loaded in the first sentence, and the when/when-not lists are scannable. The privacy note is several lines long but earns its place by disclosing a real behavioral risk; overall slightly verbose but well organized.

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?

With an output schema present, return values need not be explained, and the description still covers ordering, scope, filtering intent, alternatives, and a privacy caveat. Nothing an agent needs to invoke this 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 all five parameters (limit, metric, source, start_date, end_date) are already documented in the schema with defaults and formats. The description adds only the ordering ('most recent first') and the raw-vs-aggregate scope, so baseline 3 applies.

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 precise verb and resource ('read individual measurement rows') and immediately distinguishes the output from the daily_metrics aggregate, contrasting raw rows against summarized values. An agent can tell this apart from sibling tools without opening any schema.

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 an explicit 'Use this tool when' section and a 'Do not use this tool when' section that names three specific alternatives (read_health_data, get_metric_history, read_workout_sessions) with the condition that selects each. Routing is fully specified 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.

Deploy Server

Other Tools