Skip to main content
Glama
sikcapri

SuperGlookoQuery

by sikcapri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Compare two periods side by side

compare_periods
Read-only

Compare two diabetes data windows to answer before/after questions about glucose control, insulin use, and CGM coverage after a therapy or settings change.

Instructions

Compares two windows in one call, for before/after questions such as "how has my control changed since I switched to a fully closed-loop mode (CamAPS Liberty)", a new sensor, or a settings change. Pass period A (the earlier or baseline window) and period B (the later one); each is summarised the same way get_diabetes_summary does.

Returns: periodA and periodB, each with range, averageBG, gmiEstimatedA1c, stdDev, coefficientOfVariation, timeInRange, timeLow, timeHigh, cgmReadingCount, coveragePercent, bolusUnitsPerDay, bolusEventsPerDay, averageBasalUnitsPerDay, totalUnitsPerDay, basalPercent and carbsPerDay; and delta (period B minus period A for each, null when either side lacks it). The two windows can be different lengths, every figure is a rate or percentage, not a total. It does NOT include loop-mode usage: if get_camaps_pump_mode_breakdown is available, call it for each window to see how much of each was spent in automatic/Liberty/etc. Fewer boluses and carb entries in a fully closed-loop window may be expected, rather than missing data. coveragePercent is the share of each window that actually has CGM data: TIR is the share of the readings that exist, so when it is well below 100 (say under 70) the TIR covers only part of that period, and a comparison against a fuller period is weaker. A window with no CGM readings has null glucose metrics and null deltas, it is never treated as 0% time in range. Windows with very few days are noisy: say so when comparing under about a week.

Input Schema

NameRequiredDescriptionDefault
endAYesPeriod A (baseline) end, ISO 8601 wall-clock.
endBYesPeriod B (comparison) end, ISO 8601 wall-clock.
lowerNoOptional. Low (hypo) boundary in the chosen unit; readings below it count as time-low. Omit to use the server default (OMNI_LOWER). Pass only to override for this one call, e.g. to ask about time under a different threshold.
unitsNoOptional. Glucose unit for this call. Omit to use the unit configured on the server (OMNI_UNITS). One of: "mmol" (mmol/L) or "mgdl" (mg/dL). Pass only to override the configured unit for this one call.
upperNoOptional. High (hyper) boundary in the chosen unit; readings above it count as time-high. Omit to use the server default (OMNI_UPPER). Pass only to override for this one call.
startAYesPeriod A (baseline) start, ISO 8601 wall-clock. Required. Window start as an ISO 8601 timestamp, e.g. 2026-06-19T00:00:00.000Z. IMPORTANT: despite the trailing "Z", this is plain WALL CLOCK time, not true UTC — Glooko records only the literal date/time the patient's device showed, with no timezone attached. Use the patient's own wall-clock digits directly (no conversion): resolve "yesterday" or "last 3 weeks" straight into the matching wall-clock date and time. Treated as inclusive.
startBYesPeriod B (comparison) start, ISO 8601 wall-clock.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description goes well beyond that with null semantics for empty windows, the fact that every figure is a rate/percentage rather than a total, the meaning of coveragePercent and its effect on TIR validity, and a noise warning for windows under about a week. These are exactly the behavioral traits an agent needs to report results honestly.

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 the A/B ordering are front-loaded, and each paragraph carries a distinct payload (returns, exclusions, caveats). The long enumeration of return fields is justified because no output schema exists, though it is dense and could be tightened slightly.

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 no output schema, the description supplies the full return shape plus delta semantics (B minus A, null when either side lacks it). Combined with the coverage and small-window caveats and the cross-tool routing hint, an agent can call and interpret this tool without further context.

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. The description adds real meaning on top: period A is explicitly the baseline/earlier window, period B the comparison/later one, and the two may be of different lengths. It adds nothing about the optional lower/upper/units overrides, but the schema already documents those thoroughly.

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 (compare two windows in one call) and anchors it to the canonical question type: before/after a closed-loop mode switch, sensor, or settings change. It also distinguishes itself from get_diabetes_summary by saying each period is summarised the same way that tool does, and from get_camaps_pump_mode_breakdown by naming what it omits.

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?

Gives explicit when-to-use (before/after comparisons), explicit ordering (A = earlier/baseline, B = later), explicit pairing instruction (call get_camaps_pump_mode_breakdown per window for loop-mode usage), and explicit exclusions (no loop-mode data). It even pre-empts interpretation errors — fewer boluses/carbs in a closed-loop window is expected data, not missing data.

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