Skip to main content
Glama

remove_plan

Destructive

Remove remaining sessions of a training plan from the Garmin calendar and workout library while keeping past workouts; confirm the plan code to delete future sessions.

Instructions

Take the rest of a plan off the calendar and out of the workout library.

For starting again or abandoning a block. Only sessions from today onward are removed; past ones stay, so the record of what was planned against what was run is kept. The first call only reports what would go. Removing it needs a second call with confirm set to the plan code, after the user has agreed.

Args: label: The plan code, e.g. "HM". confirm: The plan code again, to go ahead.

Input Schema

NameRequiredDescriptionDefault
labelYes
confirmNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

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, but the description adds the crucial scope detail: only sessions from today onward are removed and past ones are kept, so the audit trail survives. It also discloses the two-phase dry-run/confirm safety flow, which no annotation covers.

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 the outcome, then scope, then the confirmation protocol, then args. Dense and largely waste-free, though the args section restates param names already covered in prose ('The plan code again'), a mild duplication.

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?

An output schema and annotations exist, so the description need not explain return values, and it doesn't. What it must cover for a destructive two-step tool — scope limits, reversibility of past data, and the confirm handshake — is fully addressed.

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 description coverage is 0%, so the description carries the full burden and does so: label is defined as the plan code with an example ('HM'), and confirm as the same code repeated to proceed. It also explains that omitting confirm produces a dry run, which the schema's empty-string default does not convey.

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?

Uses a specific verb and resource ('take the rest of a plan off the calendar and out of the workout library'), and the phrase 'rest of a plan' plus 'workout library' implicitly separates it from session-level siblings like delete_workout or unschedule_workout. An agent can identify the scope of the operation without opening the schema.

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 states the intent ('for starting again or abandoning a block') and, more importantly, prescribes the exact call sequence: a first report-only call, then a second call with confirm after the user agrees. That routing guidance is what an agent needs to decide when and how to invoke it.

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