intervals-icu-mcp

Overview Schema Source Related Servers Discussions Admin

Icu Create Custom Item

icu_create_custom_item

Create custom fields, zone sets, charts, panels, or streams in Intervals.icu to extend athlete wellness, activity, and interval tracking.

Instructions

Create a custom addition to the user's Intervals.icu account.

Use when the user says things like: "add a custom field for RPE", "create a custom power zone set", "add a chart for monthly distance". Match the user's intent to the right item_type (see that param's description). For the content schema per item_type, read intervals-icu://custom-item-schemas.

Input Schema

Name	Required	Description
`name`	Yes	Display name (e.g., 'RPE', 'Bike Weight', 'Custom Power Zones')
`content`	No	Configuration object whose schema depends on item_type. Read intervals-icu://custom-item-schemas BEFORE constructing — it documents the {code, type, aggregate} shape required for INPUT_FIELD / ACTIVITY_FIELD / INTERVAL_FIELD (with constraints and worked examples) and explains that chart/panel/zones/stream types should omit `content`.
`item_type`	Yes	What the user wants to add. Pick by intent: INPUT_FIELD (extra input on the wellness page, e.g. RPE, mood), ACTIVITY_FIELD (extra field on each activity, e.g. bike weight), INTERVAL_FIELD (extra field on each interval), ZONES (custom power/HR/pace zone set), FITNESS_CHART / TRACE_CHART / FITNESS_TABLE (custom dashboard chart/table), ACTIVITY_CHART / ACTIVITY_HISTOGRAM / ACTIVITY_HEATMAP / ACTIVITY_MAP / ACTIVITY_PANEL (custom visual on the activity page), ACTIVITY_STREAM (computed time-series). Use the literal API value.
`athlete_id`	No	Athlete ID (only for coaches; uses configured default otherwise)
`visibility`	No	Who can see it: PRIVATE (default, only you), FOLLOWERS, or PUBLIC.
`description`	No	Optional description shown to the user

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.0.0May 20, 2026

changedInput schema / properties / content / description

Previous value: -"Configuration object whose schema depends on item_type. REQUIRED for INPUT_FIELD, ACTIVITY_FIELD, INTERVAL_FIELD; for these the schema is: `code` (machine identifier — must match regex [A-Z][A-Za-z0-9]+, i.e. start with uppercase and contain only alphanumerics, no spaces/underscores), `type` ('numeric', 'text', or 'select' — NOT 'number'), `aggregate` ('MIN', 'SUM', 'MAX', or 'AVERAGE' — NOT 'AVG'). Example: {'code': 'Rpe', 'type': 'numeric', 'aggregate': 'AVERAGE'}. Optional for chart/panel/zones/stream types where the API uses defaults — you can omit and configure in the Intervals.icu UI later."New value: +"Configuration object whose schema depends on item_type. Read intervals-icu://custom-item-schemas BEFORE constructing — it documents the {code, type, aggregate} shape required for INPUT_FIELD / ACTIVITY_FIELD / INTERVAL_FIELD (with constraints and worked examples) and explains that chart/panel/zones/stream types should omit `content`."

First observedv0.1.0May 19, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare the mutation and open-world profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds genuinely useful behavior: content shape is item_type-dependent and must be read from a resource BEFORE constructing, and chart/panel/zones/stream types should omit content entirely.

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

Conciseness5/5

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

Three tight sentences, front-loaded with purpose then usage then the prerequisite for content. Nothing is padded and the resource hint arrives before the agent would start constructing arguments.

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

Completeness4/5

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

Output schema exists so return values need no explanation, and the content-shape dependency is redirected to a resource. The only gap is that coach-only athlete_id behavior and the non-idempotent nature of creation are left to the schema/annotations.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents every parameter in depth. The description largely defers ('see that param's description') rather than adding new semantics, and the resource pointer for content is already present in the schema. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Create a custom addition to the user's Intervals.icu account') and immediately grounds it in concrete user intents ('add a custom field for RPE', 'create a custom power zone set'). The create verb naturally separates it from the get/update custom-item siblings.

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?

Gives explicit trigger phrases that show exactly when to reach for this tool, and directs the agent to match intent against item_type. It does not name when to use a sibling instead (e.g., icu_update_custom_item for existing items), so it falls short of full when/when-not coverage.

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

Deploy Server