01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost up 5%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
26.7 / 30
03Economics
18.0 / 20
04Discoverability
11.1 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
7 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
cgm_agent_manifest |
params_unexplained |
Returns the wellness-cgm-mcp agent manifest: tool list, supported clients, env vars, recommended first calls, capabilities, privacy posture, and community links. `client` selects the target client (claude, codex, cursor, windsurf, hermes, openclaw, or generic) so the manifest/recommended-first-calls content can be tailored to that client. |
cgm_capabilities |
no_return_description |
Returns a capabilities object listing supported providers, which providers are configured (via env vars), available metrics, and privacy modes. |
cgm_glucose_window |
params_unexplained |
Returns all EGVs over the last N hours (default 24). `hours` is the window REQUESTED; `hours_covered` and `observed_window` state what the provider actually returned. FreeStyle Libre (LibreLink Up) caps a live read at ~12h regardless of the request, so any wider ask comes back short and `notes` says so — read the covered window, not the requested one. `hours` sets the requested lookback window in hours (1-72; default 24). |
cgm_authorize_url |
params_unexplained |
Read-only OAuth URL generation; does not exchange tokens. Not a state mutation of glucose data. Gated by: user must open URL themselves (explicit user action). Builds the Dexcom OAuth authorize URL. The user opens it, grants access, and Dexcom redirects to your registered DEXCOM_REDIRECT_URI with an auth code. If credentials are missing, returns a hint with the exact env vars needed. `state` is an optional OAuth state value echoed back on redirect for CSRF protection. |
cgm_quickstart |
params_unexplained |
Returns a personalized 3-step walkthrough for getting wellness-cgm-mcp from mock mode → live mode (Dexcom). Call this first when the user asks 'how do I connect my CGM?' `client` selects the target client (claude, codex, cursor, windsurf, hermes, openclaw, or generic) so the walkthrough steps are tailored to that client. |
cgm_profile_update |
no_return_description |
Persist a partial patch to the shared Delx Wellness profile. Requires explicit_user_intent: true. Rejects any field containing oauth/token/secret/password/cookie/refresh/api_key/session — the profile is for non-secret wellness context only. Returns the updated profile object, or a rejection/error indicating why the patch was refused. |
cgm_libre_status |
no_return_description |
Reports FreeStyle Libre (LibreLink Up) configuration: region, whether LIBRELINKUP_EMAIL/PASSWORD (or a token) are set, whether a patient id is pinned, and whether reads will be live or mock. Use this to confirm the Libre path is wired before calling glucose tools with CGM_PROVIDER=libre. Returns a status object with these configuration fields. |
Selection evidence
Confusable tool pairs.
7 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
cgm_connection_status |
cgm_libre_status |
medium | Both report whether reads are live vs mock and describe the active connection; a task like 'is my Libre connected and getting live data?' fits either. cgm_connection_status is provider-agnostic, cgm_libre_status is Libre-specific, and only the description details differ. |
cgm_glucose_now |
cgm_glucose_window |
medium | Phrasings like 'show me my latest glucose readings' or 'what is my glucose right now and over the last few hours' could select the single-value tool over the range tool, or vice versa, since both return EGV data. |
cgm_libre_status |
cgm_libre_login |
medium | Both confirm the LibreLink Up path works: status reports credentials/region/live-vs-mock wiring, while login authenticates and lists sensors. A task like 'verify my Libre setup works' or 'make sure my Libre is connected' is ambiguous between checking config and performing the login. |
cgm_agent_manifest |
cgm_capabilities |
medium | Both answer 'what can this server do': the manifest lists tools and capabilities, while capabilities lists providers, metrics, and privacy modes. A generic 'what are your capabilities?' or 'list what's available' task could map to either. |
cgm_quickstart |
cgm_onboarding |
medium | Both are guided setup flows triggered by 'how do I get started'. Quickstart is the 3-step CGM connection walkthrough, while onboarding is the 11-question profile flow; a user asking 'get me started / set this up' gives no signal about which flow they mean. |
cgm_quickstart |
cgm_demo |
low | A task like 'show me how this works before I connect anything' could pull the demo payloads instead of the quickstart walkthrough, though each has fairly distinct intent (illustrate output vs steps to go live). |
cgm_authorize_url |
cgm_libre_login |
low | Both handle CGM authentication for different providers (Dexcom OAuth URL vs LibreLink Up login). A task phrased as 'log me into my CGM / authorize my connection' without naming the provider could pick the wrong one since neither description names the other provider. |
Compare the field