Skip to main content
Glama
Thecimal

Quantified Self MCP Server

by Thecimal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get metric baseline

get_baseline
Read-onlyIdempotent

Calculate baseline statistics (mean, median, standard deviation) for a health metric over a date range to establish a normal reference for comparison.

Instructions

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.

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
metricYesOne of steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml, heart_rate, hrv_ms.
end_dateNoLast day to include, formatted YYYY-MM-DD. Defaults to today.
start_dateNoFirst day to include, formatted YYYY-MM-DD. Defaults to 90 days before end_date.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rangeYes
metricYes
baselineYes
evidenceYesCoverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema 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"
+]
  2. Addedv1.0.16
  3. Removedv1.0.15
  4. Addedv1.0.11

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral context beyond those: a privacy note explaining that returned data becomes part of the conversation and may reach a cloud model. This is valuable, non-obvious behavior that an agent should know before invoking the tool.

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 computation, then gives window-selection guidance, then closes with an important privacy disclosure. It is slightly longer than minimal, but the privacy note earns its place given the sensitivity of the data, and no sentence is redundant.

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 simple read-only tool with full schema coverage, an output schema, and clear annotations, the description covers what it computes, how to choose a useful window, and the critical privacy caveat. Nothing an agent needs in order to call it correctly or decide whether to use it 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 the baseline is 3, but the description goes further by advising that a wider window (60-90+ days) yields a more stable baseline. That adds practical meaning for setting start_date/end_date beyond the schema's structural defaults.

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 ('Compute') and names exactly what the tool returns: a baseline for one metric over a window, with mean, median, and standard deviation. It also distinguishes the tool from siblings by calling it the number every other analytics tool measures against.

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 clear context for when to use this tool, especially the note that a wider 60-90+ day window produces a more stable baseline than read_health_data's 30-day default. It does not explicitly list when-not-to-use cases or detailed exclusions, but the alternative is named and contrasted.

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