Skip to main content
Glama

edit_activity

Destructive

Correct one completed activity when the recording got it wrong — its MEASURED numbers (jammed GPS, a dropped sensor, a computer left running) or the DAY it was filed on. Four modes, and picking the right one is the whole job: • extend — part of the session DIDN'T RECORD and the athlete says it was like the rest ('первые полчаса не записались, ехал так же'). Pass the new TOTAL movingTime in seconds. Volume scales, intensity is kept, and the personal bests stand. Pass distance too if they know the real total (their usual loop); otherwise it follows the duration. • correct — a recorded number is FALSE ('Страва посчитала 42 км, а я пробежал 10'). Pass the corrected absolute values. Correcting the distance REMOVES this session's distance records — they were computed from the wrong track and the true splits can't be recovered — so tell the athlete that before they apply. • move — the recording's CLOCK was wrong, not its numbers: the device filed the session on the wrong day or hour ('записалась на 22 сентября, а ехал сегодня'). Pass date, and time only if the start time was wrong too. Nothing measured changes and syncs won't move it back; Strava and intervals.icu keep their own date — say so. • revert — undo earlier corrections, a move included, and put the provider's original back ('верни как было'). No values needed. All values are absolute NEW totals (seconds, metres), never deltas. You do NOT compute the consequences: the server recomputes TSS, IF, work and time-in-zone and the confirmation card shows every before→after. Ask for whatever you're missing rather than guessing a number — and get_activity first, so you are correcting the real values. Once corrected, the session is the athlete's: syncs from Strava/intervals stop overwriting its measured fields, and it counts as corrected in the week, the load history and the Records tab.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
askYesWhat the athlete asked for, in THEIR words and language — stored with the edit and shown in the app as the reason this session is marked edited.
dateNo`move`: the real day, YYYY-MM-DD.
modeYes
timeNo`move`: the real start, HH:MM (24h); omit to keep the recorded time.
distanceNoNew total distance in METRES.
elevationNoNew total elevation gain in metres.
movingTimeNoNew TOTAL moving time in seconds (not a delta).
elapsedTimeNoNew total elapsed/wall-clock seconds. Usually omit — it follows movingTime.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / date
      Added value: +{
      +  "description": "`move`: the real day, YYYY-MM-DD.",
      +  "maxLength": 10,
      +  "type": "string"
      +}
    • changedInput schema / properties / mode / enum
      Previous value: -[
      -  "extend",
      -  "correct",
      -  "revert"
      -]New value: +[
      +  "extend",
      +  "correct",
      +  "move",
      +  "revert"
      +]
    • addedInput schema / properties / time
      Added value: +{
      +  "description": "`move`: the real start, HH:MM (24h); omit to keep the recorded time.",
      +  "maxLength": 5,
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description goes well beyond that: correcting distance REMOVES distance records with no recovery, syncs stop overwriting corrected fields, revert restores the provider original, and consequences are recomputed server-side and shown before→after. This is unusually rich behavioral disclosure.

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 structure is excellent — mode list front-loaded, each bullet self-contained — but the text is long and repeats some schema facts (units, 'not a delta'), and the quoted examples add bulk. Every sentence still earns its place, so only a small deduction.

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 9-parameter mutation tool with no output schema, the description covers prerequisites (get_activity first), per-mode parameter requirements, downstream effects (TSS/IF/records recomputation, sync behavior) and the confirmation card. Nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 78%, so the schema already documents most fields, but the description adds real semantics: values are absolute NEW totals, never deltas; extend requires total movingTime with distance optional and duration-derived; move takes date and only conditionally time. It maps each mode to the parameters it needs.

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 names a specific verb and resource — correcting one completed activity — and immediately scopes it to measured numbers or the filing day. It cleanly separates itself from siblings like rename_activity, set_activity_notes and tag_activity by stating what 'correct' means here.

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

Usage Guidelines5/5

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

It enumerates all four modes and gives the exact situation that selects each, with athlete-voice examples ('первые полчаса не записались') and the explicit instruction to call get_activity first. Alternatives and preconditions are stated, not implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources