Wellness CGM MCP

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read. The description adds content-level context (the manifest's sections) and mentions 'privacy posture,' which is relevant given the privacy_mode parameter, but it discloses no new behavioral traits beyond what the annotations and schema already provide. No contradiction with annotations.

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

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

A single, front-loaded sentence states the core purpose first and then lists the manifest's contents. The enumeration is long but every item adds information about what the tool returns. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complexity is low: both parameters are optional and enum-constrained, so the schema carries most of the parameter burden. There is no output schema, but the description's detailed enumeration of the manifest's sections (tool list, supported clients, env vars, capabilities, etc.) substitutes well for a return-format description. The only minor gap is that the client parameter's effect on the returned content is not spelled out.

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

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

Schema description coverage is 50%: the privacy_mode parameter is fully documented in the schema (explaining summary/structured/raw and identifier omission), while the client parameter has only an enum with no description. The description's mention of 'supported clients' loosely hints at the client parameter's purpose, but it doesn't elaborate the parameter's effect on output. The description partially compensates for the coverage gap but leaves the client parameter's semantics implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Returns') and a specific resource ('the wellness-cgm-mcp agent manifest'), then enumerates the manifest's contents (tool list, supported clients, env vars, recommended first calls, capabilities, privacy posture, community links). This is precise and distinguishes it from siblings like cgm_capabilities and cgm_quickstart by framing it as the comprehensive self-description artifact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is the entry-point/introspection tool by listing 'recommended first calls' and 'capabilities' as contents, but it never explicitly says when to use this versus the overlapping siblings cgm_capabilities, cgm_quickstart, or cgm_onboarding. No exclusions or alternatives are named, so routing is left to inference.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces these by stating it is read-only and not a state mutation. Beyond that, it adds behavioral details: the requirement of explicit user action (gating) and the error behavior when credentials are missing, which are not in the annotations. No contradiction exists.

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

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

The description is concise, about four sentences, and front-loads the key read-only nature. It efficiently conveys purpose, gating, and error handling without redundancy. Minor improvement would be to structure the parameter explanation separately, but overall it is well organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one optional parameter, no output schema), and the description covers purpose, gating, and error behavior. However, it omits any explanation of the 'state' parameter, which is critical for proper OAuth usage (e.g., CSRF protection). Without that, an agent might not know whether to pass a state value or what it should be. This gap prevents a higher score.

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

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

The schema has a single parameter 'state' with no description, and schema coverage is 0%. The description does not explain what 'state' is for (e.g., CSRF protection, callback state), nor does it provide any guidance on how to set it. With zero schema coverage, the description had a responsibility to document this parameter, and it fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: it builds a Dexcom OAuth authorize URL and explicitly notes it does not exchange tokens or mutate glucose data. This distinguishes it from sibling tools like cgm_glucose_now or cgm_connection_status, so an agent can identify it as the OAuth authorization step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when the tool is relevant (OAuth authorization) and highlights a critical requirement: the user must open the URL themselves. It also mentions that missing credentials yield a hint with the exact env vars, which guides error handling. It does not explicitly name alternatives, but the sibling set is clearly different in scope, so the usage context is reasonably clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds a minor behavioral detail (configured providers come from env vars) but doesn't disclose output format, ordering, or any other behavioral traits. Since annotations carry the safety burden, a 3 is appropriate – the description adds some context but not rich behavioral detail.

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

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

A single, tightly written sentence that front-loads the verb 'Lists' and packs all key output categories without redundancy. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one optional parameter, the description covers the primary outputs (providers, metrics, privacy modes) and the parameter is fully documented. It doesn't explicitly state the return structure, but given no output schema and the clear 'lists' verb, it's sufficient for an agent to call it correctly. Minor gap: could mention that it returns an inventory or list format, but not essential.

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

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

The input schema has 100% coverage: the privacy_mode parameter is fully described with its enum values and effects. The tool description adds no additional parameter information, so the baseline 3 is correct – the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Lists' and clearly scopes the resource: supported/configured providers (via env vars), available metrics, and privacy modes. This content distinguishes it from sibling tools like cgm_data_inventory or cgm_connection_status, so an agent can identify it as the capabilities inventory tool without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage ('if you need to know what's supported, use this') but provides no explicit alternatives or exclusions. It does not mention when not to use it or how it compares to sibling tools like cgm_privacy_audit. This is an implied usage, not explicit guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it reports mock vs live data, whether credentials are present, and provider-specific env/region. This enriches the agent's understanding without contradicting the annotations.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and packs in the key details (provider, selection reason, credentials, mock vs live, env/region) without any fluff. Every word earns its place, and the structure is easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple status tool with one optional parameter and no output schema, the description covers the main return items (provider, reason, credentials, mock/live, env, region). It does not specify the exact return format, but that is typically inferred for status tools. The description is adequate for an agent to call it correctly.

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

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

The input schema has 100% description coverage, so the parameter privacy_mode is already well-documented. The description does not add extra meaning about the parameter beyond restating its purpose. The schema fully explains the enum values, so the description adds no significant value here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: reporting the active CGM provider, selection reason, credential presence, and mock vs live data, with provider-specific details. It uses a specific verb ('reports') and resource ('active CGM provider'), and the details (Dexcom env, Libre region) distinguish it from broader tools like cgm_capabilities or cgm_libre_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking connection status but does not explicitly state when to use it versus alternatives. It does not mention sibling tools or exclusions, so the agent must infer from the tool's name and description that it is the go-to for connectivity status. No explicit guidance is provided.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral context: it explains that the actual computed window (hours_covered) can be shorter than the requested window due to FreeStyle Libre's ~12h cap, and that notes flags this. It also warns against overstating coverage. This goes beyond the annotations and is crucial for correct interpretation of results. No contradiction with annotations.

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

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

The description is two sentences, with the first sentence enumerating the stats and the second explaining the coverage limitation. It is dense with important information and avoids fluff. The critical caveat is front-loaded after the metric list. While slightly technical, it is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description explains the key output stats and the crucial caveat about hours_covered. It also specifies time-in-range thresholds. However, it does not describe the exact structure of the returned object (e.g., how 'notes' is presented) or handle edge cases like no data. For a summary tool with this complexity, it covers the essential behavioral and output aspects sufficiently, but a bit more detail on the output format would make it fully complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. However, the description introduces a mismatch: it refers to 'window_hours' while the actual parameter is 'hours'. This creates confusion rather than adding clarity. It also mentions 'hours_covered' and 'observed_window' which are output fields, not parameters. The description fails to reinforce the parameter name and adds potential misdirection, lowering its contribution to parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'Returns' and the resource 'daily glucose stats', listing specific metrics (mean, median, stdev, GMI, CV, time-in-range). This clearly differentiates it from siblings like cgm_glucose_now or cgm_time_in_range by specifying the comprehensive summary nature. No ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides behavioral context about the hours_covered caveat but does not explicitly state when to choose this tool over alternatives like cgm_glucose_window or cgm_time_in_range. It implies it is for a daily summary but lacks explicit 'use when' or 'use instead' guidance. The note about not reporting beyond hours_covered is a usage rule but not tool selection guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds little beyond naming the returned content (metric catalog, TIR ranges, GMI formula) — which is more purpose than behavior. No contradictions, but no additional behavioral disclosure (e.g., privacy implications of the privacy_mode param) beyond what the schema already states.

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

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

A single sentence with the core purpose front-loaded ('Returns the metric catalog plus thresholds') followed by a compact parenthetical of specifics. Zero waste, every word earns its place. The structure is ideal for fast agent scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only, idempotent, non-destructive inventory tool with one optional parameter, the description is largely sufficient. The absence of an output schema means the description is the only return-format signal, and 'metric catalog plus thresholds' gives a reasonable sense of the payload. The main gap is the lack of differentiation from cgm_capabilities/cgm_agent_manifest, which slightly weakens completeness for tool-selection purposes.

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

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

Schema description coverage is 100% — the single optional parameter privacy_mode is fully documented in the schema, including its enum values and what each mode omits (summary omits identifiers; structured/raw return full payload). The description adds no parameter detail, so the baseline 3 applies since the schema carries the semantic burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Returns') and names a concrete resource ('metric catalog') plus its contents (thresholds, TIR ranges, GMI formula reference). This is clear about what the tool delivers. However, it does not distinguish itself from siblings like cgm_capabilities or cgm_agent_manifest, which could plausibly return overlapping catalog-like data, so the differentiation burden is unmet.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus any of the 18 siblings. There are no exclusions, no when-not-to-use hints, and no mention of which sibling handles cases this tool does not (e.g., cgm_capabilities or cgm_agent_manifest). An agent has no stated basis to choose this over an alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds value by clarifying that the payloads are 'realistic example payloads' rather than real data, and that usage is for pre-configuration preview. This is useful context beyond the annotations.

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

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

The description is two sentences with no wasted words. The first sentence states the core action and the resources involved, and the second sentence gives the usage context. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple demo tool with one optional parameter and no output schema, the description covers the essential aspects: what it returns, which payloads it covers, and when to use it. It does not detail the privacy_mode parameter, but that is fully specified in the schema. It does not describe return structure, but for a demo tool that is not critical.

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

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

The schema description coverage is 100% because the privacy_mode parameter has a clear description in the input schema. The tool description does not mention the parameter at all, but it doesn't need to; the schema already fully explains it. Therefore, the description adds no additional semantic value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Returns') and a concrete resource ('realistic example payloads of cgm_glucose_now, cgm_daily_summary, and cgm_meal_response'). It also gives the intended use case ('before configuring Dexcom'), which clearly distinguishes this demo tool from the real data-fetching siblings like cgm_glucose_now.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this to help users see what the connector will return before configuring Dexcom', which gives a clear context for when to use it. It does not explicitly mention alternatives or when not to use it, but the purpose is distinct enough that an agent can infer it should be used for previews rather than real data retrieval.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the trend arrow is included 'if available', which is useful, but it does not disclose potential latencies, connection requirements, or whether the value is cached. Given the annotations, the description adds minimal extra behavioral context, so a 3 is appropriate.

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

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

The description is a single, tightly worded sentence that front-loads the core function (returning the EGV) and the optional trend arrow. There is no filler, and every word earns its place, making it highly efficient and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must convey the return value, and it does state the key output (EGV and trend arrow). It omits details like units (mg/dL vs mmol/L) and timestamp, but for a simple getter with a single optional parameter, this is largely sufficient for an agent to call it correctly. A more complete description might mention units or error cases, but it is not critically missing.

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

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

The sole parameter, privacy_mode, is fully described in the schema with an enum and explanatory text, achieving 100% coverage. The description does not mention this parameter at all, so it adds no semantic meaning beyond what the schema already provides. Since the schema carries the full burden, the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Returns' and clearly identifies the resource as 'most recent EGV' with an optional 'trend arrow'. This precisely distinguishes it from siblings like cgm_glucose_window (which implies a time range) and cgm_daily_summary (which implies aggregation), leaving no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives such as cgm_glucose_window for historical data or cgm_daily_summary for daily aggregates. It implies a single-point current reading via 'most recent', but it lacks exclusions or prerequisites, so an agent may not know the optimal selection context.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds critical behavioral context beyond annotations: the LibreLink Up provider caps live reads at ~12h regardless of request, and the response includes 'hours_covered' and 'observed_window' fields with notes to indicate shortfall. This directly informs the agent how to interpret results, going well beyond the structured data.

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

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

Two sentences with no filler. The purpose and default are front-loaded, followed by the critical caveat about the provider cap and how to read the response. Every sentence earns its place, and the structure is clear and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description's mention of 'hours_covered', 'observed_window', and 'notes' fills a critical gap. It covers the default, the request/response discrepancy, and the safety profile (via annotations). For a simple read-only window query, nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 50%: privacy_mode has a schema description, but hours has none. The description compensates by explaining that 'hours' is the REQUESTED window and that actual coverage may differ, introducing the related output fields 'hours_covered' and 'observed_window'. This adds significant meaning to the undocumented parameter, though it does not elaborate on privacy_mode beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Returns'), resource ('EGVs'), and scope ('over the last N hours') with a default of 24. It distinguishes itself from siblings like cgm_glucose_now (current glucose) by focusing on historical windows, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is for historical glucose retrieval but does not explicitly state when to use this tool over alternatives like cgm_glucose_now or cgm_daily_summary. It provides operational guidance about the 12h cap but lacks explicit selection criteria, leaving the agent to infer usage context.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds substantial behavioral detail beyond those: window truncation by the provider, the caveat that 'No hypos' is only true for hours_covered, ADA level thresholds, and the recovery_time definition. It also includes a medical disclaimer. No contradiction with annotations; it enriches them significantly.

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

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

The description is long but information-dense. It leads with the core purpose, then output fields, then provider caveats, and ends with the disclaimer. Each sentence earns its place — no fluff. The structure is logical, though the length might slightly challenge quick scanning. It's appropriately sized for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description fully specifies return values (event fields, totals, recommendations). It covers edge cases (window truncation, threshold interpretation, provider limits) and provides a safety disclaimer. For an agent to correctly call and interpret results, nothing essential is missing. This is as complete as it needs to be.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds clinical meaning to parameters (e.g., threshold_mg_dl as ADA Level 1, severe_threshold as Level 2) and clarifies that `window` is the requested span while observed_window reflects actual data. It also explains how response_format and privacy_mode affect output. This goes beyond the schema's plain descriptions, justifying a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb-resource pair — 'Detect hypoglycemia events between `from` and `to` ISO dates' — and enumerates the exact output fields (started_at, severity, recovery_time_minutes, etc.). It clearly distinguishes this tool from siblings like cgm_glucose_window or cgm_time_in_range by focusing specifically on hypo events and their structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides strong context for when to use it: it handles date ranges and outputs event arrays with thresholds. It also explains provider-specific behavior (12h cap on live reads) that affects interpretation. However, it never explicitly names alternative tools or states when NOT to use it, leaving the agent to infer from sibling names. A direct 'use this instead of X' would push it to 5.

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

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

The description adds meaningful behavior beyond the annotations: it never returns the auth token, and when credentials are missing it returns mock=true with a synthetic connection. These are important behavioral disclosures that an agent cannot derive from the readOnly/idempotent hints.

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

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

Three sentences, each carrying distinct value: what the tool does, when it should be used, and the two notable edge behaviors. No filler or redundant restating of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers credential source, output behavior, the no-token guarantee, and the mock fallback. With no output schema, it leaves the exact normal return shape somewhat implicit, but 'list the sensors' is sufficient for an agent to call it correctly.

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

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

Schema coverage is 100%, and the schema fully documents the optional privacy_mode parameter and its values. The description adds no parameter-specific meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Authenticate against LibreLink Up using LIBRELINKUP_EMAIL / LIBRELINKUP_PASSWORD') and a secondary outcome ('list the sensors'). It does not explicitly name sibling alternatives like cgm_authorize_url to differentiate itself, so it stops just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: it is meant as an end-to-end verification before reading glucose and can be used for demoing without credentials. It does not state exclusions or explicitly compare itself to sibling auth-related tools, but the intended when-to-use is inferable.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description adds value by detailing what configuration is reported. It doesn't mention side effects or output format, but for a read-only status check this is sufficient beyond the annotation coverage.

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

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

Two sentences with no wasted words. The first sentence lists the reported items, the second gives the usage context. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple status/configuration tool, the description covers what it reports and when to use it. It lacks an explicit return format, but the lack of an output schema makes that less critical. It also gives a clear pre-call use case, which is helpful.

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

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

The input schema already documents the single optional parameter (privacy_mode) with a clear enum and description, achieving 100% schema coverage. The description does not add any parameter-specific guidance beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'reports' and enumerates the exact configuration items (region, credential presence, patient id pinning, live/mock mode). It also gives the purpose ('confirm the Libre path is wired'), which distinguishes it from generic status tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool: before calling glucose tools with CGM_PROVIDER=libre. It doesn't provide exclusions or name alternative siblings, but the use case is clear and actionable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context about the computation sequence (baseline → peak → return-to-baseline) and the output band categories, which goes beyond what annotations provide. No contradiction with annotations.

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

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

A single, information-dense sentence that front-loads the primary verb and resource, followed by output details. No wasted words, and the structure is perfectly efficient for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description explains what the tool returns (peak delta, peak time, band), which is essential. It does not elaborate on edge cases or the meaning of the band, but for a read-only computation with comprehensive schema and annotations, it is sufficiently complete. Slight deduction for not mentioning how the band is derived, though not critical.

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

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

Schema description coverage is 100%, so all parameters (meal_time, privacy_mode, window_hours) are fully documented in the schema. The description adds no additional parameter-level detail, aligning with the baseline of 3 when the schema carries the burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the operation ('Compute glucose response to a meal') and the exact outputs (peak delta, peak time, band). It is specific to a meal-response calculation, clearly distinct from sibling tools like cgm_glucose_window or cgm_daily_summary, and leaves no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a meal-response analysis is needed but does not explicitly state when to prefer this tool over alternatives, nor does it mention any prerequisites or exclusions. The intent is inferable but not directly guided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond this by specifying 'non-secret data only, stored at ~/.delx-wellness/profile.json,' giving concrete behavioral detail about data handling. The 'Read-only' statement is fully consistent with annotations — no contradiction.

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

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

The purpose is front-loaded and the description is largely efficient. Minor redundancy: the standalone 'Read-only.' fragment repeats the readOnlyHint annotation, and the final clause is a slight run-on. No sentence is wasted, but it could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with 2 optional parameters and no output schema, the description covers what it returns, why it's used, data storage location, and the safety profile. The '11-question onboarding flow' hints at the return structure, which partially compensates for the missing output schema. Reasonably complete for its complexity.

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

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

Schema coverage is 100% with both parameters (locale, privacy_mode) fully documented via enums and descriptions. The description adds marginal value by noting 'non-secret data only,' which loosely contextualizes privacy_mode, but the schema carries the parameter documentation burden. Baseline 3 is appropriate given the high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Returns the 11-question onboarding flow for the shared Delx Wellness profile.' The specificity (11 questions, shared profile) makes it clearly distinguishable from siblings like cgm_quickstart, cgm_profile_get, and cgm_agent_manifest without needing to inspect their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear, actionable directive: 'The agent should ask these questions next so wellness-cgm-mcp... can personalize responses.' This tells the agent when and why to invoke it. It doesn't explicitly name alternatives or exclusion conditions among the 18 siblings, but the context is concrete and actionable.

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

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

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the bar is lowered. The description adds meaningful scope context by listing the categories of information returned. It doesn't describe the output format or whether the audit reflects live configuration, but given annotation coverage this is acceptable.

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

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

A single, front-loaded sentence that leads with the verb and then enumerates the covered scopes in compact list form. There is zero waste; every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only privacy audit with one optional, fully-documented parameter and no output schema, the description adequately conveys what the tool returns. The four enumerated coverage areas give an agent enough to decide and invoke correctly; a dedicated explanation of output shape is not strictly necessary here.

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

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

Schema description coverage is 100% — the privacy_mode parameter is fully documented with its enum values (summary/structured/raw) and behavior. The description adds no parameter-level detail, so the baseline of 3 applies since the schema carries the full burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Returns') and a specific resource: the privacy audit of wellness-cgm-mcp. It enumerates precisely what is covered — local storage, what is sent to Dexcom, what is never logged, and agent rules — which distinguishes it from sibling data-retrieval tools like cgm_glucose_now or cgm_connection_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose is self-evident enough that an agent seeking privacy/logging information would naturally select this tool, but the description offers no explicit when-to-use vs. alternative guidance, no exclusion conditions, and names no sibling to disambiguate against. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the file path and the reason for the read (picking time-in-range profile), which is useful context but not substantial behavioral disclosure beyond annotations. No contradiction.

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

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

Two sentences: the first states the action and file, the second explains purpose and read-only nature. Front-loaded with the core functionality, no wasted words. Extremely efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with no output schema, the description explains what it returns, where from, and why it's used. The parameter is covered by schema. It doesn't describe return format or error handling, but for this tool that's not critical. It's complete enough for an agent to decide when to call it.

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

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

The single parameter privacy_mode is fully documented in the schema (enum summary/structured/raw with description). The tool description does not mention the parameter or its effect, but since schema coverage is 100%, the baseline is 3. No additional value is added, but none is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific verb 'Returns' and resource 'shared Delx Wellness profile', names the exact file path, and explains its purpose in choosing time-in-range profiles. It distinguishes itself from sibling cgm_profile_update by focusing on read-only retrieval. This is a precise, self-contained purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: get the profile to surface diabetes status for selecting time-in-range settings. It doesn't explicitly say when NOT to use it or mention alternatives, but the read-only nature and purpose give clear context. Given sibling cgm_profile_update, the intent is obvious, though explicit exclusion would push it to 5.

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

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

With no annotations, the description carries the burden of disclosing behavior. It discloses the rejection of secret-containing fields and the requirement for explicit user intent, which is useful. However, it does not mention side effects, merge semantics, or error behavior, leaving some behavioral aspects unspecified.

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

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

The description is two sentences, front-loaded with the core action and resource, and includes the critical intent requirement and rejection rule. Every sentence earns its place, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a partial-patch tool with nested objects, the schema covers parameter structure, and the description covers intent and security constraints. It lacks explicit alternative guidance and merge behavior, but these are minor given the sibling set and the schema's clarity. Overall, it is sufficiently complete for correct invocation.

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

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

Schema coverage is 100%, so both parameters are documented. The description adds value by specifying that the patch rejects fields with sensitive tokens (oauth/token/secret/etc.), which is a constraint beyond the schema's generic description. This meaningfully enhances parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Persist a partial patch') and the resource ('shared Delx Wellness profile'). It distinguishes from siblings like cgm_profile_get by implying update vs read, and mentions the partial patch nature, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear precondition (explicit_user_intent must be true) and a constraint (reject secret fields), but it does not explicitly compare to sibling tools like cgm_profile_get or state when not to use it. The usage context is implied but not fully spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the return content (3-step, personalized, mock→live walkthrough), consistent with a non-mutating read operation. No contradiction with annotations; it complements them.

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

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

Two sentences with zero waste. The core function is front-loaded in the first sentence, and the usage trigger follows immediately. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a fairly simple tool with optional enum params and no output schema. The description covers core purpose and usage trigger. However, the undocumented 'client' parameter is a real gap — an agent has no guidance on how to choose a client value — and the description doesn't describe the walkthrough's output structure.

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

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

Schema coverage is only 50% — the client parameter has no schema description and the tool description doesn't compensate for it. Neither parameter (client, privacy_mode) is explained in the description. The 'client' enum values (claude, codex, cursor...) lack any guidance on selection, and the description adds zero parameter-level meaning beyond what the schema partially provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Returns a personalized 3-step walkthrough') with clear scope (mock mode → live mode for Dexcom). The specificity of 'mock → live transition' helps distinguish it from siblings like cgm_connection_status, though it doesn't explicitly differentiate from cgm_onboarding, which could conceptually overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use trigger: 'Call this first when the user asks how do I connect my CGM?' This is actionable routing guidance. However, it doesn't name alternatives or exclusion conditions, such as when cgm_onboarding or cgm_connection_status should be preferred instead.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: it pulls from cgm_glucose_window data, falls back to mock in unauth mode, and explains the GMI formula. It does not describe the full output format in detail, but the listed return fields and defaults give sufficient behavioral clarity.

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

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

The description is moderately long but every sentence adds value: purpose, use cases, return fields, parameter presets, defaults, and data source. It is front-loaded with the core purpose and usage, and structured logically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters and no output schema, the description compensates fully by listing all return fields (total_readings, readings_in_window, mean_glucose, median_glucose, GMI), explaining presets and defaults, and noting the fallback behavior. Nothing essential is missing for correct invocation.

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

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

Schema coverage is 100% with per-parameter descriptions, but the description goes further by explaining interactions (explicit hours override presets, midnight wrapping) and providing the GMI formula that ties to mean glucose. This adds meaningful context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Compute') and a concrete resource (Time in Range, Time Below Range, Time Above Range) over a definable window with customizable targets. It lists concrete use cases (mealtime, overnight, date-range) that clearly distinguish it from sibling tools like cgm_glucose_window or cgm_meal_response.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: mealtime TIR, overnight TIR, or specific date-range comparisons. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough for an agent to select it for TIR computations.

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