Skip to main content
Glama

Glucose readings for a window (filterable by band)

get_glucose

Fetch timestamped CGM readings for a date range, filtering to low, high, or in-range bands to isolate glucose excursions or view the full trace.

Instructions

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

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.
bandNoOptional (default: "all"). Which readings to return. "low" = below the low boundary (hypo); "high" = above the high boundary (hyper); "target" = in range, between the boundaries inclusive; "all" = every reading, each tagged with its band.all
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.
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.
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.
Install Server

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden, and it is unusually thorough: it discloses the 21-day cap, that times are device-local wall-clock rather than UTC, that glucose values use the configured unit, that thresholds can be overridden, and what the returned object contains. This goes well beyond a minimal read-only statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is longer than average, every sentence earns its place: purpose, filtering semantics, use-case guidance, caveats, and return shape are each covered once and in logical order. It is front-loaded with the core purpose and avoids redundant restatements of the tool name.

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?

There is no output schema, so the description correctly compensates by enumerating the return fields: window, thresholdsUsed, band, count, and the readings array with its per-point fields. Combined with the time-zone warning, the 21-day cap, and explicit sibling-tool routing, an agent has everything needed to invoke and interpret this tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents all six parameters in detail, including enums, defaults, requirements, and the wall-clock caveat. The description usefully reinforces the band semantics and the meaning of the optional boundaries, but it does not add significant new per-parameter meaning beyond what the schema already provides.

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 opens with a precise statement: 'Individual timestamped CGM readings for a window', which names the resource, the verb, and the scope. It also distinguishes itself from siblings by clarifying that this returns raw points, while get_chart_series is downsampled and get_diabetes_summary/get_trend are aggregate tools.

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?

The description explicitly tells the agent when to use band='low'/'high' vs 'all', and names concrete alternatives for other use cases: get_chart_series for wide charts, get_diabetes_summary or get_trend for aggregate stats. It also warns about the 21-day cap, leaving no ambiguity about when this tool is appropriate.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rilhia/podquery-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server