openGym MCP Bridge

preview_plan_change

Preview openGym plan edits by validating proposed actions and returning an exact change list plus a short-lived proposal_id—without writing anything.

Instructions

Dry-run ONLY. Validate proposed edits to the openGym plan and return an exact change list plus a short-lived proposal_id. This does not write anything. Edit existing routines with rename_routine, add/remove/replace/move_routine_exercise and set_exercise_target; also create_routine, assign_weekday and override_date. Sequential indices refer to earlier edits in this proposal. Before create_routine, use search_exercises to get valid exercise IDs. A new routine may include weekdays (0=Sunday through 6=Saturday) to assign it in the same proposal.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "actions": "<actions>"
    },
    "name": "preview_plan_change"
  }
}

Input Schema

Name	Required	Description	Default
`actions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Oct 27, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does reasonably well: it explicitly states "This does not write anything" (safety profile) and discloses that the proposal_id is short-lived (a TTL constraint the schema cannot express). It also explains the sequential-index reference rule, which is genuinely non-obvious. It does not cover authorization requirements, what happens when a proposal expires, or rate limits.

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 single most important constraint, "Dry-run ONLY", leads the description, and the sentences are dense with actionable rules rather than filler. It is somewhat crammed—action names and prerequisites are packed into one long sentence—but no sentence is redundant with the structured fields.

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?

For a tool with a nested action-array schema, no annotations, and no output schema, the description supplies the operation catalog, the sequencing prerequisite, the index-resolution rule, and a summary of the return value. It stops short of explaining the change-list response shape or which fields each action type requires, which leaves some inference to the caller.

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 reported as 0%, so the description must compensate, and it does for the highest-risk semantics: the meaning of sequential indices ("refer to earlier edits in this proposal") and the weekday encoding (0=Sunday through 6=Saturday) are spelled out even though the schema also encodes them. Field-level requirements for individual action types (index vs exercise_index vs to_index, routine_id null semantics) are left to the schema's partial descriptions rather than being fully resolved in prose.

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 states a specific verb and resource ("Validate proposed edits to the openGym plan") and immediately front-loads the crucial qualifier "Dry-run ONLY". Combined with the stated return value ("an exact change list plus a short-lived proposal_id"), an agent can distinguish it from sibling preview tools like preview_workout_edit and preview_finish_workout_draft without opening any 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?

It gives explicit sequencing guidance ("Before create_routine, use search_exercises to get valid exercise IDs") and enumerates exactly which edit operations belong in this proposal versus which are out of scope. What is missing is guidance on what to do after receiving the proposal_id, and no named alternative is offered for agents that wanted a committed write.

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