Skip to main content
Glama
Thecimal

Quantified Self MCP Server

by Thecimal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Compare two periods

compare_metric_periods
Read-onlyIdempotent

Compare a metric's average between two date ranges, e.g., this month vs. last month, with a baseline summary for each period.

Instructions

Compare one metric's average between two date ranges — e.g. "this month vs. last month" or "since starting a new medication vs. before." The two ranges may be any length and need not be adjacent or equal in size; each is summarized with its own baseline first.

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.
period_a_endYes
period_b_endYes
period_a_startYes
period_b_startYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
deltaNo
metricYes
period_aYes
period_bYes
pct_changeNo
period_a_statsYes
period_b_statsYes
period_a_evidenceYesCoverage/quality of the data a single-metric analytical result is based on. See evidence.build_evidence for how each field is computed.
period_b_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. Changed3 schema fields changed
    • addedOutput schema / properties / period_a_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"
+}
    • addedOutput schema / properties / period_b_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",
-  "period_a",
-  "period_b",
-  "period_a_stats",
-  "period_b_stats"
-]New value: +[
+  "metric",
+  "period_a",
+  "period_b",
+  "period_a_stats",
+  "period_b_stats",
+  "period_a_evidence",
+  "period_b_evidence"
+]
  2. Addedv1.0.16
  3. Removedv1.0.15
  4. Addedv1.0.11

TDQS

B3.4/5.0
Behavior4/5

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

The description adds meaningful behavioral context beyond the annotations: it states that returned data becomes part of the conversation sent to the model, warns about cloud privacy implications, and explains that each period is summarized with its own baseline. The readOnlyHint and idempotentHint annotations align with the description, and no contradiction is present. It does not fully detail output behavior, but the output schema covers that.

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 reasonably concise and front-loaded: the first sentence states the core purpose and examples, the second addresses period flexibility, and the privacy note is a separate relevant addition. No filler sentences are present, and every part contributes to correct usage. It could be slightly shorter, but the added context is worthwhile.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema reduces the need to describe return values, and the description covers the main purpose, period flexibility, and privacy implications. However, the description does not compensate for the poorly documented date parameters nor explicitly guide selection against sibling analytical tools. For a tool with five required parameters and a low schema coverage, this leaves some meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%, with four date-range parameters entirely undocumented. The description adds some meaning by explaining that these are date ranges and that they may have arbitrary lengths, but it fails to specify date formats, inclusivity of endpoints, or the semantics of the start/end relationship. This is a notable gap given the schema's low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Compare one metric's average between two date ranges.' It also provides concrete examples that clarify the intended use. However, it does not explicitly differentiate itself from sibling tools like calculate_metric_trend or find_metric_correlation, relying on the phrase 'average between two date ranges' to imply the distinction.

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

Usage Guidelines3/5

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

The description gives illustrative use cases ('this month vs. last month') and clarifies that periods need not be adjacent or equal. But it does not explicitly state when to prefer this tool over a sibling, nor does it mention any alternatives or exclusions. Usage guidance is implied rather than explicit.

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