Intervals.icu MCP Server

get_training_readiness

Assess training readiness by synthesizing recent wellness data—HRV, resting heart rate, sleep, and subjective inputs—and withhold a verdict when data is insufficient.

Instructions

Assess training readiness from recent wellness data.

Synthesizes the athlete's recent wellness history into a readiness read:
HRV-guided (7-day rolling lnRMSSD vs baseline +/- smallest worthwhile change),
resting-HR and sleep trends, and subjective inputs (soreness/fatigue/stress/
mood/motivation). When there is too little data — notably fewer than ~2 weeks
of HRV — the verdict is withheld rather than guessed, and the report lists which
signals it could and could not use.

Args:
    days: How many days of history to analyze (default 45; minimum 14 is enforced).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_training_readiness"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 2, 2026

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does meaningful work: it discloses the failure mode (verdict withheld rather than guessed) and that the report enumerates which signals were and weren't usable. It omits cost/latency and any auth expectations, but the core behavioral contract is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose sentence, then methodology, then failure behavior, then args — a sensible ordering with no filler. The dense parenthetical on HRV methodology is the one place where detail briefly outweighs what an agent needs to select the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value documentation is not required, and the remaining essentials — what is analyzed, the data-sufficiency gate, and the single parameter's default and floor — are all covered. An agent can decide to call this and construct the call from the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates well: it gives the default (45), the enforcement floor (minimum 14), and the meaning ('how many days of history to analyze'). Only the behavior when a value is passed under 14 (clamp vs error) is left ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence pairs a specific verb with a specific resource ('Assess training readiness'), and the second sentence scopes it to wellness-history synthesis, which implicitly separates it from the raw-data sibling get_wellness_data. It does not name that sibling explicitly, so an agent must infer the split rather than being told.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is present but indirect: it states the tool withholds a verdict when there is too little data (~2 weeks of HRV), which tells the agent when NOT to expect a result. There is no explicit 'use get_wellness_data instead for raw values' routing despite that sibling existing.

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