Skip to main content
Glama
sikcapri

SuperGlookoQuery

by sikcapri
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Local

Enriched bolus log

get_enriched_bolus_log
Read-only

Retrieve enriched bolus logs with CGM context and insulin settings to evaluate dosing accuracy, detect interrupted deliveries, and analyze user overrides.

Instructions

Every bolus in the window, each enriched with the context needed to judge whether it was the right dose: the interpolated CGM value at the moment of delivery, and the ISF, carb ratio, target and DIA in force at that time.

Each record also carries delivered vs programmed units (delivered < programmed means the bolus was interrupted, flagged interrupted=true); the calculator recommendation broken into recCorrection, recCarbs and recTotal; whether the user overrode it (override: "above" or "below"); the bloodGlucoseInput and its source the calculator used; the bolus class; and isManual.

Use it to investigate insulin stacking, bolus-calculator accuracy, interrupted deliveries and user overrides. Filter with "classes" to pull only the bolus types you care about and keep the response small.

Capped to 92 days per call. All glucose values are in the configured unit; times are plain wall clock time (device-local), not UTC.

Returns: count, the classes filter applied, and a boluses array of enriched records (each with time, units, delivered, programmed, interrupted, recCorrection, recCarbs, recTotal, override, bgInput, bgSource, cgm_val, class, isManual, and a context object of the settings in force).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYesRequired. Window end as an ISO 8601 timestamp, e.g. 2026-06-20T00:00:00.000Z — plain wall clock time, same caveat as start (the "Z" is a format artifact, not a UTC claim). Treated as inclusive and must be after start. All timestamps returned by this API are likewise plain wall clock time, unconverted.
startYesRequired. 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.
classesNoOptional filter. Array of bolus classes to include. Valid values (use these exact strings): "Meal Bolus" (carb-only dose), "Manual Correction Bolus" (user-initiated correction for a high), "System Correction Bolus" (algorithm-initiated correction), "Meal With Correction Bolus" (combined carb + correction dose). Provide one or more to combine, e.g. ["Manual Correction Bolus", "System Correction Bolus"]. Omit or leave empty to return all classes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses critical behavioral details: time is plain wall clock (not UTC), glucose values are in configured units, the 92-day cap, and the meaning of delivered vs programmed (interruption flag). It also outlines the response structure and setting context. This transparency is exceptional and far exceeds what annotations alone provide.

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 lengthy but well-organized, front-loading the core purpose then progressively detailing usage, constraints, and return object. Every sentence adds substantive information without redundancy. While it could be tightened, the structure is logical and aids comprehension, earning a 4 rather than a 5 for its verbosity.

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?

Given the tool's complexity (3 parameters, 2 required, rich return object) and the absence of an output schema, the description is highly complete. It explicitly enumerates the return fields, explains the interruption flag, override semantics, and the settings context object, and covers constraints like the 92-day cap and time-zone handling. Nothing an agent needs to call 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?

The input schema already provides detailed descriptions for all three parameters, including time-zone caveats and valid class enum values. The description adds extra strategic value by recommending the classes filter to 'keep the response small,' which enriches usage semantics beyond the schema. With 100% schema coverage, this goes above the baseline of 3.

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 specific purpose: return every bolus in the window, enriched with contextual data (CGM, settings, overrides) to judge dose correctness. It clearly distinguishes itself from siblings by emphasizing enrichment and analysis use cases, making it easy for an agent to select this tool over alternatives like get_split_bolus_log or get_daily_insulin.

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 explicit use-case guidance: 'Use it to investigate insulin stacking, bolus-calculator accuracy, interrupted deliveries and user overrides.' It also advises on the classes filter to keep responses small. However, it does not explicitly mention when NOT to use it or contrast it with sibling tools, which would make the guidance fully complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools