Skip to main content
Glama
futureweb

Futureweb Intervals MCP

add_or_update_note

Destructive

Add or edit a plain text note (category NOTE) on the Intervals.icu calendar. Update only note events with partial changes, duplicate checks, and dry-run previews.

Instructions

Use only when the athlete asks to add or edit a plain text note (category NOTE) on the Intervals.icu calendar. Writes to Intervals.icu.

Updates are partial: only the passed fields change (renaming keeps text, colour and date); an empty description never wipes the text, clear_description=true does. Only notes can be updated: anything else (a workout, a race) is refused, never turned into a note. A duplicate of that day is refused (allow_duplicate); dry_run shows the request; the answer reads back what was stored.

Input Schema

NameRequiredDescriptionDefault
nameNoNote title; required when creating
colorNoColour name, e.g. green, orange, red, blue; default green when creating
dry_runNotrue = check and return the exact request, write nothing
event_idNoNOTE event to update; omit to create
athlete_idNoDefault: the configured athlete
start_dateNoDay YYYY-MM-DD; default today when creating, unchanged when updating
descriptionNoPlain text of the note; replaces the text on update (empty is ignored)
allow_duplicateNoCreate even if that day has the same event (name or workout)
clear_descriptionNoEmpty the note's text on update

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare write/destructive/open-world flags; the description goes much further by disclosing partial-update semantics, the empty-string-is-ignored rule, the duplicate-refusal rule, dry-run mode, and that the response reads back what was stored. That is exactly the behavioral context annotations cannot carry.

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?

Dense but front-loaded: the gating condition and the note-only constraint come first, then update mechanics. Every clause carries information. Minor cost is the slightly clipped 'Writes to Intervals.icu.' and telegraphic phrasing that takes a second read.

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?

With 9 parameters, no required fields, and no output schema, the description covers the create-vs-update switch, defaults behavior on update, the dry-run path, and the shape of the answer. Nothing an agent needs to call this tool correctly is missing.

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 100%, so baseline is 3, but the description adds real semantics beyond it: an empty description never wipes text while clear_description=true does, duplicates are refused unless allow_duplicate, and dry_run returns the exact request without writing. This behavior-oriented framing is more useful than the per-field schema text.

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 pair (add or update) and resource (plain text note, category NOTE) on the Intervals.icu calendar, and explicitly contrasts with other event types (a workout, a race). An agent can distinguish it from add_or_update_event without inspecting either schema.

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?

"Use only when the athlete asks to add or edit a plain text note" gives a clear trigger, and the refusal clause ("anything else ... is refused, never turned into a note") defines the boundary case. It does not explicitly name the sibling to use for workouts/races, so the routing for non-note events is left to inference.

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