Reps

save_plan

Destructive

Use this when the user wants a whole training plan (several routines on a schedule, such as a push/pull/legs split) saved to their Reps account, including a plan they bring as a photo, PDF, spreadsheet or pasted text. This writes straight away: first describe the plan to the user (its routines, their exercises and the schedule) and wait for an explicit yes in this conversation. schedule_type is "rotation" (routines run in order, no weekdays) or "fixed_days" (every routine needs a distinct day_of_week, 1 = Monday … 7 = Sunday). To reuse a routine the user already has, pass its routine_id from get_routines: it is LINKED, not copied, and keeps its own name. Otherwise give its name and exercises, with slugs or ids from get_exercise_library (a timed hold or cardio takes target_duration_seconds instead of target_reps). For a plan the user brought, read it yourself, look every exercise up, and add what the library lacks with add_custom_exercise before saving; an unknown exercise is refused with candidates. The plan becomes the active one unless you pass activate: false; that stops the previously active plan, which the result names in replaced_plan, so tell the user. It shows up in the Reps app after its next sync (up to 5 minutes) or when the app is reopened; say so.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`activate`	No
`routines`	Yes
`schedule_type`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`name`	Yes
`plan_id`	Yes
`routines`	Yes
`is_active`	Yes
`routine_ids`	Yes
`replaced_plan`	Yes
`schedule_type`	Yes
`visible_in_app`	Yes
`linked_routine_ids`	Yes
`created_routine_ids`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 29, 2026

addedInput schema / properties / routines / items / properties / exercises / items / properties / target_duration_seconds
```
Added value: +{
+  "type": "number"
+}
```
removedInput schema / properties / routines / items / required
```
Removed value: -[
-  "name"
-]
```

changedOutput schema / properties / routines / items / properties / exercises / anyOf

Previous value: -[
-  {
-    "items": {
-      "properties": {
-        "name": {
-          "type": "string"
-        },
-        "sets": {
-          "type": "number"
-        },
-        "slug": {
-          "type": "string"
-        },
-        "target_reps": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        },
-        "target_weight_kg": {
-          "anyOf": [
-            {
-              "type": "number"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        }
-      },
-      "required": [
-        "name",
-        "slug",
-        "sets",
-        "target_reps",
-        "target_weight_kg"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "properties": {
+        "name": {
+          "type": "string"
+        },
+        "sets": {
+          "type": "number"
+        },
+        "slug": {
+          "type": "string"
+        },
+        "target_duration_seconds": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "target_reps": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "target_weight_kg": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "required": [
+        "name",
+        "slug",
+        "sets",
+        "target_reps",
+        "target_weight_kg",
+        "target_duration_seconds"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

First observedSep 23, 2026

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 idempotentHint=false, and the description supplies the context that makes those hints actionable: it 'writes straight away', it deactivates the previously active plan unless activate:false, the replaced plan is named in replaced_plan, and the result only appears after an app sync of up to 5 minutes. That is exactly the extra behavioral detail annotations cannot convey.

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?

It is long, but nearly every sentence adds distinct operational value and it is front-loaded with the confirmation requirement before the field-level detail. A slight trim of the sync/app-reopen clause would tighten it without losing meaning.

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?

Given a write tool with no schema descriptions, a 4-parameter nested schema and a sibling save_routine, the description covers prerequisites, side effects, error behavior (unknown exercise refused with candidates), and the activation outcome. The output schema covers return shape, so no return-value explanation is needed.

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 must carry the load and does: it explains schedule_type's two enum values and the day_of_week constraint under fixed_days (distinct day per routine, 1 = Monday), the link-vs-copy semantics of routine_id, the slug/id requirement for exercises, and the target_duration_seconds alternative to target_reps.

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+resource ('save a whole training plan ... to their Reps account') and immediately distinguishes it from the sibling save_routine by stressing 'several routines on a schedule, such as a push/pull/legs split'. It also enumerates the input modalities (photo, PDF, spreadsheet, pasted text), so an agent can tell exactly which tool handles whole-plan ingestion.

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 gives explicit when-to-use and when-not guidance: confirm with the user and 'wait for an explicit yes in this conversation' before writing, and route to get_routines for existing routine ids, get_exercise_library for slugs/ids, and add_custom_exercise for anything the library lacks. The condition for passing routine_id vs name+exercises is spelled out.

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

All Reps tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?