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

With no annotations, the description carries the full burden and does an excellent job: it explains the meaning of each state, that output is collapsed intervals rather than raw points, that times are device-local wall clock (not UTC), and that results are capped. It even details the conditional intervals array and the summary metrics returned.

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 fairly long but every clause earns its place: state definitions, use cases, the critical units distinction, time semantics, cap rationale, and return shape. The most important semantic warning — states not insulin amounts — is front-loaded.

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?

There is no output schema, but the description compensates by stating exactly what the agent will receive: per-state minute/percentage summaries and an optional intervals array with start, end, and minutes. Combined with thorough parameter schema text and timezone clarification, an agent has enough to select and invoke the tool 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%, so the baseline is 3; the description adds a little extra by reiterating the wall-clock caveat and explaining why the time span is capped ('returns collapsed intervals, not raw points'). Most parameter-level detail already lives in the schema, so the added marginal value is moderate, not maximal.

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 exactly what the tool returns: a timeline of basal algorithm states (normal/suspend/max/limited), not insulin amounts. It explicitly differentiates from get_daily_insulin, making it easy for an agent to distinguish this from sibling 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 gives concrete scenarios for using the tool — investigating lows, rebound patterns, system workload, and limited mode coinciding with excursions. It also tells agents when NOT to use it: when they need basal units, use get_daily_insulin 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?

With no annotations, the description carries the full burden, and it goes far beyond a basic summary: it discloses that the tool opens the browser itself, what openAttempted true/false means, that `html` is only a fallback, that wall-clock time is used rather than UTC, that downsampling preserves true min/max, and that the chart's day-details panel uses the same aggregator as get_diabetes_summary. This is exemplary behavioral disclosure.

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 the length is largely earned: it is organized into labelled sections (DATA RESOLUTION, CRITICAL, Returns) and front-loads the most operationally important rule ('do not rebuild the chart yourself'). There is minor redundancy around the 'do not reproduce the HTML' instruction, so it is not perfectly tight, but every major paragraph serves a real decision an agent must make.

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?

Given 9 parameters, no annotations, and no output schema, this description is remarkably complete. It covers return fields, success/failure fallback behavior, time-zone semantics, downsampling policy, response etiquette, and how to compare against sibling tools. An agent has everything it needs to call the tool and behave correctly afterward.

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 substantial value by explaining the `ranges` alternative in depth (non-contiguous windows, equal day width, ordering), the `resolution` divisor semantics, the interaction between `resolution` and `maxPoints`, and the cost of `embedHtml`. Parameters like lower/upper rely on the schema, but overall the description clearly exceeds the baseline.

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: it 'Generates a clinical-report-style glucose chart', saves it to a file, and opens it in the browser. It also explicitly distinguishes itself from the sibling get_chart_series ('USE THIS instead of get_chart_series whenever the patient wants to SEE a chart'), so an agent can select it correctly without inspecting 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 is explicit about when to use this tool over get_chart_series, when to use `ranges` instead of start/end, when to offer `resolution`, and when `embedHtml` should be set. It even gives a patient-facing script for the downsampling tradeoff. This is the strongest possible usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool returns data, not a rendered picture; explains the downsampling and min/max banding; warns that points are not evenly spaced in time; explains the xAxis object is ready to use; and documents wall-clock vs UTC behavior. This is unusually thorough.

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 it is well-structured with bolded section headers, bullet lists, and clear warnings. It front-loads the core purpose and then organizes rendering and x-axis guidance so an agent can act on it. Some points are restated for emphasis, but the extra length is largely justified by the tool's easy-to-misuse output.

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?

There is no output schema, so the description must explain the return shape, and it does: unit, points array with t/avg/min/max/n, events array for bolus markers, and xAxis with spanHours, ticks, and days. It also covers rendering requirements, timezone conventions, gap behavior, and multi-day chart layout. This is complete enough for an agent to call and use the result 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 schema already covers all three parameters with high coverage, so the baseline is 3. The description adds useful extra context beyond the schema, such as the target-point guidance that 200-400 is plenty for a smooth chart and that a chart cannot show more points than its pixel width, which helps an agent choose maxPoints sensibly.

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 statement of what the tool does: it returns glucose downsampled for chart drawing, with min/max bands per point and bolus overlay events. It further distinguishes itself by explicitly saying it returns data and not a picture, and by naming get_glucose as the alternative for numeric close-up inspection.

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 says to use this tool whenever a graph or chart of glucose over a window is needed, and tells the agent to render the returned data as a visual line/area chart. It also gives a when-not-to-use direction by reserving get_glucose for close-up numeric inspection rather than wide charts.

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 available, the description carries the full burden. It discloses the data source (Glooko verbatim), the provisional flag on the current day before finalisation, and the wall-clock date semantics. It does not explicitly address read-only/no side-effect status or potential auth/rate-limit constraints, but its behavioral claims are clear and consistent.

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 front-loaded with the core purpose, then usage guidance, then important caveats, then a necessary return-shape listing because there is no output schema. Every sentence earns its place; no filler or repetition.

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?

Given two clearly documented parameters, no output schema, and no annotations, the description supplies all essential context: return fields, date interpretation, provisional-day caveat, and sibling-tool routing. Nothing an agent needs to correctly call this tool is 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?

Schema description coverage is 100%, so the schema already documents start and end meaningfully, including wall-clock caveats. The description reinforces the wall-clock convention but adds no parameter-specific semantics beyond the schema, which matches the baseline for full schema 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 first sentence states exactly what the tool returns — Glooko's verbatim per-day totals with basal units, bolus units, combined total, and a window aggregate — using a specific verb and resource. It also distinguishes itself from get_diabetes_summary and get_trend by positioning this as the device-reported daily method versus the event-aggregated method.

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 explicit when-to-use context ('Use this when you specifically want the device-reported daily totals') and explicit alternatives with the condition for choosing them ('For bolus aggregated from individual events... use get_diabetes_summary or get_trend'). This leaves no ambiguity about tool selection.

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 provided, the description shoulders the transparency burden and does well: it discloses that events are point-in-time markers, that times are 'plain wall clock time (device-local), not UTC,' and that the result contains podChanges/sensorChanges arrays plus a count. It also explains the intended interpretation to prevent misuse. It does not mention pagination or ordering, but for a simple read-only list tool that is not a major gap.

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 organized into short paragraphs: what is returned, when to use it, timezone caveat, and return shape. It is front-loaded and avoids fluff, though the middle paragraph on clinical context is somewhat extended. Overall it is efficient and readable.

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?

Given no output schema and no annotations, the description compensates by specifying the return structure (two arrays and counts), the timestamp semantics, and the practical use case. It also warns against over-interpretation. The tool is simple enough (two required params, no nested objects) that nothing critical is 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 input schema already documents start and end in detail, including ISO 8601 format, inclusive bounds, ordering, and the wall-clock caveat. The description reaffirms the wall-clock caveat but adds no new parameter-specific semantics beyond the schema's 100% coverage, so a baseline 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 states exactly what the tool provides: 'Pod changes ... and CGM sensor changes, as timestamped events, kept as two separate lists.' It also clarifies these are point-in-time markers, not amounts, and names the returned fields (podChanges and sensorChanges), so the agent understands the resource without ambiguity. This clearly distinguishes it from sibling glucose/insulin tools by subject matter.

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 concrete use case: use the events as 'CONTEXT for nearby glucose disruption' to check whether an unexplained high or odd readings 'lines up with a recent change.' It also tells the agent how to interpret results ('possible contributing factor, never assert it as the cause'). It does not name explicit exclusions or sibling alternatives, but among the visible siblings none overlap directly with device-change events, so the omission is minor.

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 full behavioral burden and does so exceptionally well. It discloses fixed-size output, cheap long-window calls, uncapped orientation behavior, insulin aggregation rules, tie-breaking logic for ranking, and the plain-wall-clock timezone convention. This gives an agent a reliable model of how the tool behaves.

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 its length is largely earned: it front-loads purpose, adds a practical discovery tip, then explains computational caveats and the return contract, which is necessary because there is no output schema. A few parenthetical asides are slightly expendable, but overall it is well-ordered and information-dense.

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 complex aggregation tool with no annotations and no output schema, this description is remarkably complete. It explains the full set of returned fields, how aggregates are computed, how rankings are resolved, and the timezone convention. An agent has everything it needs to invoke the tool correctly and interpret the result.

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 baseline is 3. The description reinforces the wall-clock timestamp caveat and refers to the parameter notes, but the schema already documents defaults, overrides, and formats for all five parameters. No additional parameter meaning is needed.

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 first sentence names the tool as 'the single best starting point for any overview question' and specifies that it returns fixed-size aggregates over a window. It clearly positions itself as distinct from the sibling period-specific tools by framing itself as an orientation call before drilling into a specific period.

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 recommends using this tool for overview questions and as an orientation call to discover how much data the system holds before drilling into a specific period. It does not explicitly name alternatives or give when-not-to-use conditions, but the usage context is strongly established.

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?

No annotations are provided, so the description carries the full burden, and it is unusually thorough: it discloses the 92-day cap, wall-clock versus UTC handling, the configured glucose unit, the interrupted flag semantics, override values, and the complete return record shape. It also explains the 'Z' caveat in the schema, going beyond what structured data conveys.

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 tightly organized into purpose, field explanation, use cases, constraints, and return contract. The final return-list paragraph is somewhat redundant with the field names already mentioned, but given the record complexity it is justified and every other sentence 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?

With no output schema, the description fully defines the return contract by listing every field in the boluses array and the top-level count and filter echo. It covers time handling, unit handling, result caps, and filtering behavior, making it complete enough to call 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?

Although schema coverage is 100%, the description adds substantial meaning: it clarifies that start/end times are plain wall-clock device-local times despite the trailing 'Z', that end is inclusive and must be after start, and it expands each 'classes' enum value with practical meaning and combination examples. This materially improves correct invocation 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 and resource: it retrieves every bolus in the window and explains exactly what 'enriched' means (interpolated CGM, ISF, carb ratio, target, DIA). This clearly differentiates it from the sibling tools, which address trends, glucose, basals, settings, or chart data.

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 says 'Use it to investigate insulin stacking, bolus-calculator accuracy, interrupted deliveries and user overrides,' giving clear use cases. It also advises using the 'classes' filter to keep responses small. It doesn't explicitly contrast with sibling tools or state when not to use it, but the context is strong enough for selection.

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

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden, and it delivers: it explains the pooling semantics, the critical wall-clock vs UTC nuance, that hours are presented as-is without conversion, and the exact return fields. This is unusually transparent about a subtle timezone behavior that could easily cause misuse.

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 compact and well-structured: core behavior first, then use cases, then the timezone warning, then return format. Every sentence earns its place and no information is redundant with the schema.

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?

Given no output schema and no annotations, the description is remarkably complete. It covers what the tool computes, when to use it, the timezone interpretation, the unit convention, and the structure of the byHour result. An agent has enough to invoke it correctly without resorting to guesses.

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 baseline is 3. The input schema fully documents start, end, lower, upper, and units. The description reinforces the window concept and timezone caveat already present in the schema but does not add new parameter-level information.

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 definition: 'Time In Range and average glucose pooled by clock-hour across the whole window', naming both the resource and the aggregation behavior. It clearly distinguishes itself from ordinary time-series tools by emphasizing that all readings from the same wall-clock hour across days are combined into a single row.

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 lists concrete use cases: 'why am I always high/low at a certain time' questions, recurring circadian patterns, dawn phenomenon, and evening highs. It does not name sibling tools or say when not to use this tool, but the context is clear enough for an agent to select it appropriately.

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 behavioral burden and mostly succeeds. It discloses the exact time window, states that times are wall-clock device-local and not UTC, and clarifies that glucose values follow the configured/overridden unit. It also outlines the returned fields. Minor caveat: the phrase 'configured unit' does not explicitly restate the effect of the units override, but the schema compensates.

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 tight and front-loaded: first the exact window, then the use case, then time/unit caveats, then the return shape. Every sentence earns its place without fluff or repetition.

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, but the description compensates by enumerating returned fields and their semantics. It also covers the key operational details: wall-clock times, unit conventions, and how to obtain the required timestamp. Nothing essential is missing for a caller to invoke 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 100%, so the schema already explains both parameters thoroughly. The description adds context about the event source and the analysis window, but it does not materially enhance the meaning of eventTimestamp or units beyond what the input schema already 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?

The description clearly identifies the tool as a focused single-event analysis: 'exactly 30 minutes before and 3 hours after the timestamp you pass.' It distinguishes itself from broader sibling tools by saying 'without pulling whole days' and even points to a specific sibling for the prerequisite event time.

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: 'Use it to judge a post-meal excursion and how well a dose worked.' It also gives a concrete workflow by directing the user to find the event time from get_enriched_bolus_log first. It does not enumerate every alternative or exclusion, but the guidance 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?

With no annotations, the description carries the full burden of behavioral disclosure and does substantial work. It flags the wall-clock-not-UTC convention, warns that the trailing 'Z' is a format artifact, clarifies per-segment times as pump-schedule clock-hours, and states glucose units. It omits auth or rate-limit details, but covers the behaviors most likely to cause misinterpretation.

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 compact and front-loaded: the first sentence states exactly what is returned, the second gives usage context, and the remaining sentences add only high-value details about time handling and output shape. Every sentence earns its place without 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?

There is no output schema, but the description compensates by explicitly describing the returned settings array, its per-entry fields, and the time-segment shape ({from, value}). Combined with the 100%-covered input schema, an agent has enough information to invoke the tool and interpret its results 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 100%, so the baseline applies. The schema already documents start and end as required ISO 8601 wall-clock timestamps, inclusive behavior, and the timezone caveat. The description reinforces the window concept but adds little parameter-specific 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.

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: it retrieves every Omnipod 5 setting change in effect during a window, in chronological order, and enumerates exactly what is included (DIA, max basal rate, target/ISF/carb-ratio profiles). This scope is distinct from the sibling tools, which focus on glucose, trends, boluses, and device events.

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 concrete use cases: establishing which settings were active before judging a bolus or excursion, and reviewing how settings changed over a long span. It does not explicitly name sibling alternatives or state when not to use this tool, but the usage context is clear enough for an agent to select it appropriately.

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 provided, the description carries the full burden, and it delivers: it explains that buckets are computed independently rather than by averaging averages, details insulin aggregation rules for bolus versus basal, and discloses observedDays/coverage percentages so the agent can judge trustworthiness. It also describes the exact return shape, which is critical given no output schema.

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 every section earns its place: use-case framing, computation semantics, insulin rules, trust metrics, and a complete return-field listing. It is front-loaded with the primary purpose and avoids filler or repetition.

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?

Given the tool's complexity, 8 parameters, and no output schema, the description is unusually complete. It documents the full return structure, covers edge semantics like independence of buckets and observedDays trust metrics, and complements the schema's timezone caveats and parameter documentation. Nothing essential for correct invocation appears 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?

Schema coverage is 100%, with all parameters, defaults, enums, and units already documented in the input schema. The description adds useful context about bucket independence and returned fields, but it does not materially expand parameter-level meaning beyond what the schema already provides, so 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 a specific verb and resource: it returns glucose, insulin, and carb aggregates split into time buckets across a span. It clearly distinguishes this from other tools by framing it as a multi-period trend comparison, and the title reinforces the bucketed trend concept.

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 says to prefer this tool over making many separate summary calls for multi-period comparison. It explains the benefit — 12 correct rows in a single call without pulling raw data — which gives an agent a concrete decision rule for 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.