Analyze cycling power data to estimate FTP, best efforts from 5 seconds to 60 minutes, W/kg, Coggan power zones, and 5-/60-minute FTP ratios for training insights.
Cycling power: FTP (set with set_athlete, otherwise estimated as 95% of best 20-min
power), best powers 5 s-60 min over days and the last 28 days, W/kg if weight is set,
Coggan power zones in watts, and 5-min / 60-min to FTP ratios.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: how FTP is derived when unset (95% of best 20-min power), that W/kg appears only when weight is set, and that a fixed last-28-day window is reported alongside the `days` window. It does not discuss cost, empty-data behavior, or units of return aside from watts.
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?
A single front-loaded sentence led by 'Cycling power' with everything else in service of describing the output. Dense with nested parentheticals, but every clause adds information and nothing is redundant.
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?
A read-only one-parameter report tool with no output schema; the description effectively serves as the output contract by enumerating the metrics returned. Only missing elements are the `days` default and behavior on missing weight/FTP data beyond the estimation rule.
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?
With one parameter at 0% schema coverage, the description must carry the burden, and it does: `days` is identified as the lookback window for the best-power curve, distinguished from the fixed 28-day window. It does not state the default of 90 or acceptable ranges, but the core semantics are conveyed.
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 enumerates the resource precisely (FTP, best powers, W/kg, Coggan zones, ratios), so an agent can tell this is a cycling power report. But it is a noun phrase with no verb (compute/return) and gives almost no differentiation from siblings like fitness_profile or load_focus. The only routing aid is the set_athlete reference for FTP.
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 statement of when to use this tool versus fitness_profile or load_focus, and no exclusions. The only guidance-adjacent content is that FTP comes from set_athlete or a 95%-of-20-min estimate, which hints at a prerequisite but does not tell the agent when to pick this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.