Skip to main content
Glama
sla1k
by sla1k

smartgym_remove_exercise

Destructive

Remove an exercise from a SmartGym routine while preserving logged history; use dry run to preview without changes.

Instructions

Remove an exercise from its routine (logged history is kept).

exercise_id comes from smartgym_get_routine. dry_run=true (default) sends NOTHING.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNo
exercise_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noticeYes
changesYes
dry_runYes
routineYes
requestsYes
snapshotYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructive=true, idempotent=false, openWorld=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: logged history is retained (partial rather than full destruction) and dry_run defaults to true so nothing is sent unless explicitly overridden. It stops short of describing reversibility or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short clauses, front-loaded with the core action and the non-destructive caveat, then the parameter sourcing and the dry-run warning. No filler.

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

Completeness4/5

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description supplies the key operational facts (history retention, dry-run default, ID provenance), leaving only minor gaps like error/permission behavior.

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 description coverage is 0%, so the description must carry the load, and it does: it names smartgym_get_routine as the source of exercise_id and explains that dry_run=true (the default) sends nothing. Both parameters get meaningful semantics beyond their bare types.

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 (Remove) and resource (exercise from its routine) with a scoping detail that logged history is preserved. It does not explicitly name a sibling alternative (e.g., archive_routines, move_exercise), so differentiation is implicit rather than 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 removal use case is clear from the verb, and the dry_run note tells the agent it must set dry_run=false to actually act. However, there is no explicit when-to-use/when-not guidance or reference to an alternative tool for related operations.

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