Check your daily Garmin training readiness score and key contributing factors to decide whether to push hard or recover.
Training readiness score for a day, with the factors that drove it.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered by structured data. The description adds a genuine behavioral detail – that the response includes the contributing factors, not just the number – but it does not disclose return format, score range, or derivation. Given annotation coverage, 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 13-word sentence with no filler, and the core resource is front-loaded. However, brevity comes at the cost of omitting parameter guidance, so it is efficient rather than fully developed.
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 and a 0%-coverage parameter schema, the description bears the full burden of explaining the date parameter and the return shape; it explains neither format nor defaults. 'With the factors that drove it' hints at the response contents, but an agent is left without enough to call the tool correctly for a non-default date.
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% – the date parameter has no schema-level documentation – and the description does not compensate. It only implies that date selects the day in question; it never states the expected format (e.g., YYYY-MM-DD), the meaning of null (presumably today), or timezone handling, so an agent cannot reliably construct a correct call.
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 a specific, well-defined Garmin metric ('Training readiness score') and scopes it to 'a day, with the factors that drove it,' telling an agent what is returned and at what granularity. It does not explicitly distinguish itself from related siblings like garmin_training_status or garmin_daily_summary, so it stops short of a 5.
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?
No guidance is given about when to choose this tool over garmin_training_status, garmin_hrv, garmin_stress, or garmin_daily_summary, and no conditions, prerequisites, or exclusions are mentioned. The single declarative sentence leaves all selection decisions to the agent's prior knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.