Loading ToolBench
A Model Context Protocol server that reads data from a FreeStyle glucose sensor.
Two well-named, read-only tools with excellent descriptions (194 - 250 chars each) that clearly state limitations and data caveats. Input schemas are properly typed with enums and defaults. Tool annotations (readOnlyHint, openWorldHint) are present and correct. Error handling is thoughtful, ConfigError and UpstreamContractError are caught and explained to the LLM with actionable recovery hints. Output structure is documented in code (renderReading, asJson). Main gaps: output schemas are not formally documented in the tool registration (only visible in implementation); no pagination or result limits (though history is capped at 12h upstream); parameter descriptions could be slightly more explicit about unit conversion semantics.
Read the most recent glucose measurement from the FreeStyle sensor, with the instant it was actually measured. The value is the latest one upstream holds, not a live reading — always report `measured_at` rather than calling it 'now'. Informational only: this is not a medical device and must not be used for any treatment decision.
Glucose readings over the last N hours (max 12), with time-in-range computed against the account's own target band. Upstream holds only about 12 hours of detailed data and ignores any longer request, so the response always states the range it actually covered and sets `truncated` when that is less than asked — report that range, never the one requested. Collection gaps are listed separately and are not interpolated across; a percentage over a series with gaps describes only the covered time. Informational only: not a medical device, and not a basis for any treatment decision. This is not an HbA1c or GMI estimate — those need weeks of data.
Output schemas not formally documented in tool registration. Callers must infer structure from implementation (renderReading returns {value, unit, measured_at, raw_trend_arrow}; history adds target_range, readings[], gaps[], time_in_range). LLMs cannot plan downstream operations without explicit schema.
Parameter descriptions for 'unit' are minimal (18 chars: 'Unit for the returned values...'). Should explain that storage is always mg/dL and unit only affects display, with conversion semantics. Current description is under the 50-char baseline for clarity.
No documented error cases or recovery paths in tool registration. Error handling exists in code (explain() function), but LLMs cannot see it. Tool descriptions should hint at failure modes: 'May fail if credentials are missing (run mcp-freestyle-login) or if upstream API changes.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
raw_trend_arrow field is intentionally undocumented (comment: 'integer mapping is undocumented and unverified'). This is defensible for safety, but the output schema should explicitly note that this field is present but not translated, and LLMs should not interpret it.