Intervals.icu MCP Server

get_wellness_data

Retrieve wellness data for a signed-in Intervals.icu athlete, including training metrics, vitals, sleep, and subjective scores over a date range; optionally include custom fields.

Instructions

Get wellness data for the signed-in athlete from Intervals.icu.

By default returns standard wellness fields (training metrics, vitals, sleep,
subjective scores, etc.). Set include_all_fields=True to also include any
additional or custom fields configured by the user in Intervals.icu.

Args:
    start_date: Start date in YYYY-MM-DD format (optional, defaults to 30 days ago)
    end_date: End date in YYYY-MM-DD format (optional, defaults to today)
    include_all_fields: If True, include additional and custom fields beyond the standard set (optional, defaults to False)

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_wellness_data"
  }
}

Input Schema

Name	Required	Description	Default
`end_date`	No
`start_date`	No
`include_all_fields`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

It goes beyond the schema by stating key behavioral details like default date ranges (30 days ago to today) and explaining exactly how the `include_all_fields` flag changes the return data.

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?

The description is highly detailed but logically structured, front-loading the core function and then defining the critical behavioral parameters and optional arguments.

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?

For a tool without an output schema or annotations, the description provides all necessary context: parameter formats, defaults, and the scope of the returned data, making it fully actionable for an AI agent.

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

Parameters5/5

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

Given that the schema coverage is 0%, the description is crucial. It provides full semantics for all three parameters, including expected formats (YYYY-MM-DD) and default behavior, which is maximally helpful.

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

Purpose5/5

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

The description clearly and specifically states the tool retrieves 'wellness data' for the signed-in athlete from Intervals.icu, which differentiates it from activity or event management tools in the sibling list.

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

Usage Guidelines4/5

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

While it does not explicitly list alternatives, it defines the scope of the data returned (vitals, sleep, etc.), implicitly guiding the agent toward using this tool for health metrics rather than workout data.

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