The single best starting point for any overview question ("how was my control yesterday / over the last 3 weeks / last 6 months"). Returns fixed-size aggregates no matter how long the span, so it is cheap to call over months and tolerates very long windows.

TIP: because this tool is uncapped, a deliberately wide call (e.g. start 2000-01-01T00:00:00.000Z, end tomorrow) is the quickest way to discover how much data the system actually holds: the returned reportRange.start and reportRange.end are the first and last readings present in the archive. Use it as an orientation call before drilling into a specific period.

Insulin uses the project-wide rule: bolus is summed from individual events; basal comes from Glooko's per-day totals. The basal/bolus split is reported as percentages on a per-day-rate basis (a useful balance metric for a closed-loop system). GMI and CV are computed from the CGM readings.

Best/worst day and hour are ranked decisively: Time In Range first, then closeness to the glucose target in force at each reading (median absolute deviation), then variability, and each carries those figures so the ranking is explainable.

Returns: reportRange (start, end, days, reflecting the actual data present), glucoseControl (averageBG, gmiEstimatedA1c, stdDev, coefficientOfVariation, variability flag, timeInRange/timeLow/timeHigh, cgmReadingCount); glucoseExtremes (highest and lowest readings, each with every timestamped instance); bestWorst (bestDay, worstDay, bestHour, worstHour, each with tir, medianAbsTargetDev, cv); insulin (observedDays, bolusUnits, bolusUnitsPerDay, bolusEventCount, avgUnitsPerBolus, and when Glooko daily data exists basalUnits, basalDayCount, averageBasalUnitsPerDay, basalPercent, bolusPercent); bolusArchitecture (counts by bolus type); carbs (carbsGrams, carbsPerDay, carbEntryCount); and settings (the time-segmented profiles in force). All timestamps are plain wall clock time (see start/end parameter notes), not UTC.

Glooko's own per-day insulin totals shown verbatim: basal units, bolus units and the combined total for each day, plus a window aggregate.

Use this when you specifically want the device-reported daily totals (for example a day-by-day basal/bolus table, or "what was my total daily dose each day"). Note: the bolus here is Glooko's pre-aggregated daily figure. For bolus aggregated from individual events (the project-wide method used everywhere else), use get_diabetes_summary or get_trend. Basal is only available from Glooko, so this and those tools share the same basal source.

The most recent day may be flagged provisional if it is still today and not yet finalised.

Returns: source ("glooko-daily"), a days array (date, basalUnits, bolusUnits, totalUnits, provisional), and an aggregate (daysWithData, basalUnits, bolusUnits, totalUnits, basalUnitsPerDay, bolusUnitsPerDay, totalUnitsPerDay, basalPercent). All dates are wall-clock (device-local) days.

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).

Time In Range and average glucose pooled by clock-hour across the whole window, so every reading that fell in the 07:00 hour on any day is combined into one 07:00 row, and so on for all 24 hours.

Use it for "why am I always high/low at a certain time" questions, recurring circadian patterns, the dawn phenomenon and evening highs.

Hours are the device's own wall-clock hour (not UTC) — this already IS the patient's local hour at the time each reading was taken, so present it as-is with no conversion.

Returns: a byHour array of up to 24 rows, each with hour (wall clock, "HH:00"), averageBG, timeInRange, timeLow, timeHigh and the reading count for that hour. Glucose values are in the configured unit.

Every Omnipod 5 setting change that was in effect during the window, in chronological order: DIA, max basal rate, and the time-segmented target, ISF and carb-ratio profiles.

Use it to establish which settings were active at a given time (essential before judging a bolus or an excursion), or to see how settings have been adjusted over a long span.

Glucose-based values (target, ISF) are in the configured unit. Effective timestamps are plain wall clock time (device-local), not UTC; the per-segment "from" times are pump-schedule clock-hours.

Returns: a settings array, each entry with its effective timestamp, DIA_hours, maxBasalRate, and the targetBg, isf and carbRatio profiles (each a list of {from, value} time segments).

Glucose, insulin and carb aggregates split into time buckets across a span, for "how have things changed month by month over the last year" style questions.

Each bucket is computed independently from the raw readings (not by averaging averages), so a year split by month returns 12 correct rows in a single call without pulling raw data back to you. Prefer this over making many separate summary calls for a multi-period comparison.

Insulin per bucket follows the same rule as elsewhere: bolus is summed from individual events; basal comes from Glooko's per-day totals. Each bucket also reports observedDays (the real decimal span of data in it) and a coverage percentage, so you can judge which rows to trust.

Returns: bucketCount and a buckets array. Each row has: bucket (period key), start, end, observedDays; glucose (avg, timeInRange, timeLow, timeHigh, stdDev, coefficientOfVariation, gmiEstimatedA1c, cgmReadingCount); insulin (bolusUnits, bolusUnitsPerDay, bolusEventCount, avgUnitsPerBolus, and when Glooko daily data exists basalUnits, basalDayCount, averageBasalUnitsPerDay, basalPercent, bolusPercent); carbs (carbsGrams, carbsPerDay, carbEntryCount); and coverage (cgmReadingCount, expectedReadingCount, coveragePercent, trustworthy).

Glucose downsampled to a target number of points for drawing a chart, with a min/max band per point so spikes are not lost, plus bolus events as overlay markers.

Use this whenever the patient wants a GRAPH or CHART of glucose over a window, or when illustrating "what a good/bad day looked like" — a picture of the trace is far more useful here than a table of numbers. It returns a few hundred points instead of every 5-minute reading, so it is far cheaper than get_glucose and a chart cannot show more points than its pixel width anyway. Reserve get_glucose for close-up numeric inspection of a short window, not for wide charts.

IMPORTANT — this tool returns DATA, not a picture: after calling it, actually render the points as a visual line/area chart with time on the x-axis and glucose on the y-axis, shading the target range and marking boluses, rather than only describing the numbers in prose. Producing that chart is the point of calling this tool at all.

HOW TO RENDER IT — DO NOT use a quick/built-in auto-chart shortcut for this: any lightweight "visualize this data" feature that infers its own axis from a plain array almost always falls back to plotting by point POSITION (1, 2, 3, ...) because it never looks at the t field or the xAxis data below — this has been confirmed to happen and produces a meaningless, unlabelled time axis. Instead, BUILD A CUSTOM CHART YOURSELF (e.g. an HTML/SVG or JS-charting-library artifact you write) where you explicitly control the x-axis scale and can use the xAxis data below directly. If your environment offers both a quick chart shortcut and the ability to write custom HTML/code, always choose the custom option for this tool's output.

X-AXIS — READ THIS CAREFULLY, this is commonly gotten wrong: the x-axis MUST be a genuine TIME SCALE, NEVER a plain category/index axis showing point position (1, 2, 3, ... maxPoints, or "286"). Points are NOT evenly spaced in time (a sensor gap or the short-fidelity path below means the interval between consecutive points can vary), so an index axis silently distorts time and every tick is meaningless to the reader.

To make this hard to get wrong, the response includes a ready-made xAxis object — USE IT DIRECTLY instead of inventing your own tick scheme:

• xAxis.ticks: an array of {t, label} already spaced sensibly for the window's span (every 3-4 hours for anything up to ~10 days, daily beyond that). Plot these as the x-axis tick marks, using label as the tick text VERBATIM — do not recompute your own tick positions or labels.

• xAxis.days: one {startT, endT, label} entry per calendar day the window touches (e.g. "Wed 17 Jun"), present whenever the window spans more than a single day. For a multi-day chart, this is what makes it read correctly: divide the plot into these segments with a vertical divider at each boundary, and print each segment's label centred underneath — e.g. three equal sections labelled "Wed 17 Jun", "Thu 18 Jun", "Fri 19 Jun" for a 3-day window, each showing that day's own hour ticks above it. This is exactly the "N equally spaced, dated sections" layout a multi-day glucose chart needs. days is empty for a single-day window (nothing to divide) and for very long windows (too many days to label individually — ticks switches to one date label per tick there instead).

• A gap in the data (missing points) must still show as a visual gap or interrupted line against this time scale — never compressed away.

Glucose values are in the configured unit; times are plain wall clock time (device-local), not UTC.

Returns: unit, a points array (t, avg, min, max, n per point), an events array of bolus markers for overlay, and xAxis (spanHours, ticks, days) as described above.

Generates a clinical-report-style glucose chart for a window (or several separate windows via ranges) — line trace colour-coded in-range/low/high, a shaded target-range band, a min/max spread band, bolus markers (hoverable in their own right for that bolus's units/ carbs/type, in addition to the aligned CGM reading's own tooltip), a header stat row (time in range, average glucose, time low, time high), a legend, and hover tooltips — saves it to a file, and opens it directly in the patient's default web browser. USE THIS instead of get_chart_series whenever the patient wants to SEE a chart.

Multi-day charts open with a Chronological/Overlay toggle: chronological is the usual continuous timeline; overlay re-plots every calendar day on a shared 0-24h axis (colour-coded per day, with a day legend) so days can be compared directly. Use ranges instead of start/end when the patient wants to compare specific, possibly non-contiguous dates together (e.g. "the 20th, 23rd and 30th") — every requested day gets equal width on the axis regardless of the calendar gap between them. The page also has a day-filter chip per day (in both views) so the patient can hide/show individual days themselves, with the header stats recalculating for whichever days are still visible — you never need a new call just to compare a subset of the days already shown.

The page also includes a "Day details" panel per calendar day (open by default for a single day, collapsed for multiple), with that day's full glucose control (average, GMI, TIR/low/high, std dev, CV), extremes (highest/lowest with times), best/worst hour, insulin (bolus units/count/ avg, basal units, bolus-basal split), bolus type counts, carbs, and the settings in force — the SAME figures get_diabetes_summary would return for that single day, computed by the identical aggregator so the two never disagree. Hiding a day's filter chip hides its detail panel too.

DATA RESOLUTION: a routine call (no resolution/maxPoints given) already plots every single CGM reading with NO smoothing for a typical window (a day, a week, a full month) — the point budget only kicks in on wider windows, where it keeps each bucket's true min/max so no low or high excursion is ever smoothed away, only the moment-to-moment trace between them is thinned. When a call DOES get thinned this way, the result includes a downsample object naming the raw vs plotted reading counts — treat that as an invitation to offer the patient a choice, not as data that has become unavailable: mention it in plain terms ("I plotted a lightly smoothed version of this wide a window — want the full-detail version instead? It may take a little longer to load") and, if they want more detail, re-call with resolution set to how much of the real data to use — 1 for every single reading, 2 for every other one, 3 for every third, and so on. Never decide this smoothing tradeoff silently on the patient's behalf beyond the routine default.

CRITICAL — how to respond after calling this, this is what keeps it fast: this tool does the displaying itself. Do NOT copy, re-type, rebuild, or paste the chart as an artifact/code block/canvas yourself — reproducing a large HTML page as your own output is exactly the slow path this tool exists to avoid, and it is unnecessary work since the browser window is already open by the time you respond. If the JSON result has openAttempted: true, just tell the patient in one short sentence that the chart has opened in their browser — do not describe or restate its contents in detail, do not emit any HTML/code, and treat the tool call as already complete. If openAttempted: false, the auto-open could not be launched from this machine (e.g. no recognised default-browser command) — tell the patient to open the file at the returned filePath themselves; only in that fallback case, or if embedHtml was explicitly requested, does the response also include a full html field. Do NOT reach for a quick/built-in "auto-visualize this data" shortcut either — this tool already produces the real chart.

Times are plain wall clock time (device-local), not UTC.

Returns: ranges (the resolved windows actually used), dayCount, unit, pointCount, bolusCount, filePath (where the page was saved), openAttempted (whether the browser launch was attempted without an immediate error), downsample (only present when the plotted points were thinned from the raw CGM readings — see DATA RESOLUTION above), and — only as a fallback — html.

What the Omnipod 5 was doing with basal over time: delivering normally, pausing it (suspend), running at its ceiling (max), or running blind on a fixed preset because it lost CGM signal (limited).

IMPORTANT: these are STATES describing the algorithm's behaviour, NOT insulin amounts. "suspend" means paused, "max" means at the ceiling; neither is a number of units. (For basal units, use get_daily_insulin.)

Use it to investigate lows (was basal already suspended beforehand?), rebound patterns (max, then suspend, then a low), how hard the system is working, and whether excursions coincided with limited mode (algorithm not adjusting at all).

Times are plain wall clock time (device-local), not UTC. Capped to a generous span since it returns collapsed intervals, not raw points.

Returns: a summary of minutes and percentage per state (normal/suspend/max/limited) and, unless includeIntervals is false, an intervals array (state, start, end, minutes).

Pod changes (the Omnipod is replaced roughly every 3 days) and CGM sensor changes, as timestamped events, kept as two separate lists.

These are point-in-time markers, not amounts. They are most useful as CONTEXT for nearby glucose disruption: a fresh pod can run high for the first hours while the cannula settles, and a new sensor can read erratically while it warms up. Use them to check whether an unexplained high or a run of odd readings lines up with a recent change. Treat any such link as a possible contributing factor, never assert it as the cause.

Times are plain wall clock time (device-local), not UTC.

Returns: podChanges and sensorChanges arrays of wall-clock timestamps, plus a count for each.

Individual timestamped CGM readings for a window, optionally filtered to just the part of the range you care about.

The "band" option decides which readings come back: "low" (below the low boundary, i.e. hypos), "high" (above the high boundary), "target" (in range), or "all" (every reading, each tagged with its band). Use "low"/"high" to pull only excursions for a close look without dragging in thousands of normal readings; "all" gives the full trace.

This returns raw points, so it is capped to 21 days. For a wide chart use get_chart_series (downsampled); for aggregate stats use get_diabetes_summary or get_trend rather than computing over a raw array yourself.

Glucose values are in the configured unit; times are plain wall clock time (device-local), not UTC.

Returns: window, thresholdsUsed (lower, upper, unit), the band requested, count, and a readings array (time, value, velocity, plus band when band="all").

A focused look around a single event (typically a meal bolus): exactly 30 minutes before and 3 hours after the timestamp you pass.

Use it to judge a post-meal excursion and how well a dose worked, without pulling whole days. Find the event time first (e.g. from get_enriched_bolus_log), then pass it here.

Glucose values are in the configured unit; times are plain wall clock time (device-local), not UTC.

Returns: targetEvent (the timestamp you passed), unit, a glucoseTimeline array (time, value) across the window, and an associatedBoluses array of enriched bolus records that fall in the window.