Intervals.icu MCP Server

add_or_update_note

Add or update plain-text notes on the Intervals.icu calendar to record training context, with optional date, color, athlete, and event ID settings.

Instructions

Add or update a plain text note (category NOTE) on the Intervals.icu calendar.

Args:
    name: Title of the note
    description: Plain text content of the note
    start_date: Date in YYYY-MM-DD format (optional, defaults to today)
    color: Color of the note (e.g. green, orange, red, blue)
    athlete_id: The Intervals.icu athlete ID (optional)
    api_key: The Intervals.icu API key (optional)
    event_id: The Intervals.icu event ID (optional, for updates)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "description": "<description>"
    },
    "name": "add_or_update_note"
  }
}

Input Schema

Name	Required	Default
`name`	Yes
`color`	No	green
`event_id`	No
`start_date`	No
`description`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 2, 2026

TDQS

B3.3/5.0

Behavior2/5

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

With zero annotations, the description carries the full burden for a mutating tool. It does not disclose whether an update overwrites the existing note body entirely, what happens if a supplied event_id does not exist, what permissions/scopes the API key needs, or any rate limits — the output schema covers only the response shape.

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 purpose sentence is front-loaded and the per-argument list is compact and skimmable. The 'Args:' block is slightly redundant with the schema titles, but each entry adds at least format or default information, so little is wasted.

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

Completeness3/5

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

Return values are covered by the output schema and all five real parameters are explained, so calling the tool is possible from this description. However, for an un-annotated write/update operation the description leaves out update-vs-create side effects and the athlete_id/api_key discrepancy, which is a meaningful gap.

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 coverage is 0%, so the description must compensate, and it largely does: start_date gets a YYYY-MM-DD format and a 'defaults to today' note, color gets value examples, and event_id is explained as the update trigger. The flaw is the reverse mismatch — athlete_id and api_key are documented here but absent from the schema — which can mislead an agent into passing them.

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?

States a specific verb pair (add or update) and resource (plain text note, category NOTE) on the Intervals.icu calendar, which is concrete and actionable. It never names the sibling add_or_update_event to explain the note-vs-event distinction, so the differentiation is inferable but not stated.

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?

The only routing signal is 'event_id ... for updates', which implies that supplying an event_id switches from create to update. There is no explicit when-not guidance, no mention of when an agent should prefer add_or_update_event instead, and no prerequisites beyond the optional api_key/athlete_id hints.

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