Daash

Overview Schema Source Related Servers Discussions Admin

update_workout

Destructive

Change an existing workout's name or steps in place, keeping its ID and scheduled dates so the watch syncs the new version. Use it to retune paces without deleting and recreating sessions.

Instructions

Change an existing workout in place: its name, its steps, or both.

The workout keeps its id, so any dates it is already scheduled on stay scheduled and the watch picks up the new version at the next sync. This is how a plan adapts: retune the paces on next week's sessions rather than deleting and recreating them. Give steps in the same shape create_workout takes; leave it out to change only the name or description.

New steps replace the old list entirely, so to change part of a workout (one pace, the recoveries, the cool-down) read it with get_workout first and send back every step, changing only what the user asked for. The answer carries the steps it replaced, so say exactly what changed.

Args: workout_id: The workoutId from get_plan, list_workouts or create_workout. name: New name. Omit to keep the current one. steps: New step list, replacing the old one entirely. Omit to keep it. sport: Only needed with steps, and only to change the sport. description: New note. Omit to keep the current one. pool_length_meters: For a swim, a new pool length. Omit to keep it.

Input Schema

Name	Required	Description	Default
`name`	No
`sport`	No
`steps`	No
`workout_id`	Yes
`description`	No
`pool_length_meters`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Oct 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true; the description supplies the crucial nuance the annotation cannot — the workout keeps its id, scheduled dates survive, the watch picks up changes at next sync, and the steps list is replaced wholesale rather than merged. It even notes the response echoes the replaced steps, which is behavior an agent cannot infer from the schema.

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?

Front-loaded with purpose, then behavior, then the replacement caveat, then a clean Args block — the ordering is exactly what an agent needs. It is on the long side and the mid-sentence line breaks add noise, but no sentence is redundant given the empty schema descriptions.

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?

A destructive mutation tool with six undocumented parameters and no schema descriptions would normally be under-specified, but this description covers id/scheduling side effects, replacement semantics, field-by-field argument meaning, and the prerequisite read step. Return values are left to the output schema, which is appropriate.

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 0%, so the description carries the full burden and does: every one of the six parameters is explained, including the 'omit to keep current value' convention that the schema's nullable defaults do not convey, plus the conditional rule that sport is only meaningful alongside steps. It also points steps at the create_workout shape, filling a real gap for a free-form object array.

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?

Opens with a specific verb+resource ('Change an existing workout in place') and immediately scopes what can be changed (name, steps, or both). It is clearly distinguishable from create_workout, delete_workout, and get_workout, all of which appear 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 Guidelines5/5

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

Explicitly says to retune existing workouts rather than delete-and-recreate, and prescribes the read-with-get_workout-then-resend-all-steps procedure for partial edits. It also states when to omit optional fields, so the agent never has to guess between update and delete/create.

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