Weight and body composition

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

Annotations include readOnlyHint=true and openWorldHint=true, and the description does not contradict them. The description adds the default behavior of 'last 7 days' and clarifies that body composition is only included 'where recorded,' which is useful context beyond annotations. However, it doesn't disclose pagination, rate limits, or how date range is interpreted when not specified. With annotations covering safety, 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 sentence, front-loading the core resource ('Weigh-ins') and scope ('date range'), with the default unpacked immediately. It also adds the caveat about body composition. There is zero waste, and every word earns its place, making it highly concise and well-structured.

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 simplicity (2 params, no required, no output schema), the description is largely sufficient, but it lacks details on parameter format, pagination, and error handling. The annotations cover safety (readOnly, openWorld), so the description's job is to clarify usage, which it partially does. It could mention that start and end are optional and how they interact, but the overall picture is adequate for a basic call.

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 compensate for the undocumented parameters. It mentions 'date range' and 'default: last 7 days,' which implies that start and end are date range boundaries, but it doesn't specify format (e.g., ISO 8601), null handling, or inclusive/exclusive bounds. The description adds some meaning but not comprehensive guidance, so baseline 3 is fitting.

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 retrieves weigh-ins over a date range with body composition where recorded, using a specific verb ('Weigh-ins') and resource ('date range'). It is distinct from siblings like garmin_heart_rate or garmin_activity, though it doesn't explicitly differentiate from other health metrics tools, so it's clear but not perfect.

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 when to use it (to get weight data) but provides no explicit guidance on when not to use it or alternatives. It doesn't mention that this is the only weight-specific tool among siblings, but the purpose is clear enough that an agent can infer usage. Lacks explicit exclusions or alternative routing, so it's adequate but not strong.

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