Get steps

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: it discloses the returned fields and, importantly, that long ranges are fetched 28 days at a time, which explains latency and any internal chunking behavior the agent might otherwise misread as incomplete results.

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 compact paragraphs with no filler, and the payoff (what you get back) is front-loaded in the first line before parameter mechanics. Every sentence carries information an agent needs.

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 correctly takes on the burden of naming the return fields (steps, distance in meters, goal). The one residual ambiguity is whether results are one aggregate record or a per-day series, since 'daily total steps' can be read either way.

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 0%, so the description must carry the parameters — and it does, specifying YYYY-MM-DD format, inclusive semantics, an explicit default of the last 7 days, and unrestricted range length with 28-day fetching. It stops short of stating whether start/end may be omitted independently, so it doesn't fully close the gap.

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 names the exact resource and fields returned: daily total steps, distance in meters, and step goal. It clearly separates this from heart-rate, sleep, and weight siblings. It does not, however, explicitly distinguish itself from close siblings like garmin_get_daily_summary or garmin_get_day, which likely also surface step 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 gives useful operational context — the default is the 7 days ending today, ranges are inclusive, and any length is accepted — which tells the agent how to call it. What it lacks is when-to-use guidance: it never says to prefer garmin_get_daily_summary for a full multi-metric day view or garmin_get_day for hourly breakdowns.

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