Blood oxygen

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds that it provides average and lowest overnight SpO2, which is useful context. However, it doesn't disclose details like whether the date is required, what happens if no data exists for the date, or the format of the response. With annotations covering the safety profile, 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 with no waste. It front-loads the core purpose ('Pulse oximetry for a day') and then specifies the key outputs ('average and lowest overnight SpO2'). 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?

The tool has a single optional parameter, an output schema, and annotations covering safety. The description is adequate for a simple read-only tool, but it doesn't clarify the meaning of the null default or the date format. Given the simplicity, this is a minor gap, but the description could be more complete by stating what null means.

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. The description mentions 'for a day' which implies the date parameter, but it doesn't explain the date format, what null means, or how the date affects the returned data. The parameter is optional with a default of null, but the description doesn't clarify whether null means today or all data. This is a gap, but the single parameter is relatively self-explanatory.

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: 'Pulse oximetry for a day' with 'average and lowest overnight SpO2.' This clearly identifies what the tool does and distinguishes it from sibling tools like garmin_heart_rate or garmin_respiration, though it doesn't explicitly name a sibling.

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 a single day's SpO2 data, and the date parameter is optional with a default of null, suggesting it may default to today. However, it doesn't explicitly state when to use this tool versus alternatives like garmin_daily_summary or garmin_heart_rate, nor does it mention any exclusions or prerequisites.

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