Get training readiness

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds real behavioral context: Garmin recomputes readiness through the day, only the AFTER_WAKEUP_RESET entry is the morning score, it costs one Garmin request, and it returns null/empty when nothing was recorded. Some of the response-shape detail overlaps the output schema, keeping this just short of a 5.

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?

Front-loads what is returned, then the use case, then the differentiators vs siblings, closing with cost and return behavior. Dense but every sentence carries distinct information; no 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?

For a single-parameter read with an output schema and full annotations, the description supplies everything an agent needs: scope, alternatives, recompute semantics, request cost, and empty-result behavior. Nothing actionable 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 coverage is 100% (the single 'day' parameter is fully documented with format YYYY-MM-DD), so the schema carries parameter semantics. The description adds no syntax or formatting meaning beyond it; 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?

States a specific verb and resource: returning every training readiness entry Garmin recorded for one day, and names the exact fields returned (score, level, factors). It also tells the agent what the tool is NOT for by citing get_day_summary and get_trend, so it is distinguishable from siblings without opening 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?

Explicitly routes usage: 'Use it for why the score is what it is,' and then draws boundaries against get_day_summary (which already gives the morning score) and get_trend with metric readiness (which follows weeks/months). This is explicit when-to-use and when-to-prefer-alternatives guidance.

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