garmin_get_hydrationRetrieve daily water intake, hydration goals, estimated sweat loss, and activity-logged intake in mL for any date range, defaulting to the last 7 days.
Daily water intake, goal, estimated sweat loss, and intake logged during activities, all in mL.
start, end: YYYY-MM-DD inclusive (default: the 7 days ending today). Any length works; long ranges are fetched 31 days at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds real value with units (mL), inclusive date semantics, and disclosure that long ranges are fetched 31 days at a time. It stops short of noting rate limits, auth requirements, or timezone handling for day boundaries.
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 short blocks: the payload first, then parameter semantics. No filler, no repetition of the tool name, and the default range is stated up front where an agent will see it.
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 zero-required-parameter read tool with no output schema, the description supplies the return fields, units, default window, and fetch-chunking behavior. Only timezone/day-boundary semantics are missing, a minor gap for an end-of-range query.
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 0%, so the description carries the full burden and mostly does: it gives the YYYY-MM-DD format, states the range is inclusive, and defines the default (7 days ending today) for both start and end. It does not address how a partially supplied range or null values behave, which keeps it from a 5.
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 enumerates exactly which hydration metrics are returned (daily water intake, goal, estimated sweat loss, activity intake) and their unit (mL), which distinguishes it from siblings like garmin_get_food_log or garmin_get_weight. It lacks an explicit verb, but the resource is 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?
It gives concrete context (default range of the last 7 days) but never says when to pick this over adjacent tools such as garmin_get_daily_summary, nor any exclusions or prerequisites. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.