Skip to main content
Glama
Sign In

Blocks

by zone.blocks
OverviewDiscussionsAdmin

remove_from_plan

Destructive

Remove planned work from the calendar: one scheduled workout on date (by iid from get_plan), or every planned workout on that day when iid is omitted. Touches planned entries only — completed activities and the day's notes stay. There is no undo: putting a session back is plan_workouts or copy_workouts. Returns how many entries were removed, or says nothing was planned that day.

Input Schema

NameRequiredDescriptionDefault
iidNoone workout's iid; omit to clear every planned workout that day
whyNoONE line, in the athlete's language: WHY this change — the reason from the conversation ("travel Thu-Fri, long ride moved to Sat", "deload after 3 build weeks"). The athlete's other assistant surface reads it later; without it, it sees only that the plan changed. No health details beyond what the plan needs.
dateYesthe day to remove from
noteEditsNoYOUR OWN day notes (by:"ai") this change makes wrong, changed in the same card: replaces = the start of that note; note "" removes it, new text rewrites it, to moves it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / noteEdits
      Added value: +{
+  "description": "YOUR OWN day notes (by:\"ai\") this change makes wrong, changed in the same card: replaces = the start of that note; note \"\" removes it, new text rewrites it, to moves it",
+  "items": {
+    "properties": {
+      "date": {
+        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+        "type": "string"
+      },
+      "note": {
+        "maxLength": 1000,
+        "type": "string"
+      },
+      "replaces": {
+        "maxLength": 200,
+        "minLength": 4,
+        "type": "string"
+      },
+      "to": {
+        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+        "type": "string"
+      }
+    },
+    "required": [
+      "date",
+      "replaces"
+    ],
+    "type": "object"
+  },
+  "maxItems": 10,
+  "type": "array"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / date / description
      Added value: +"the day to remove from"
    • addedInput schema / properties / iid / description
      Added value: +"one workout's iid; omit to clear every planned workout that day"
  3. Changed1 schema field changed
    • addedInput schema / properties / why
      Added value: +{
+  "description": "ONE line, in the athlete's language: WHY this change — the reason from the conversation (\"travel Thu-Fri, long ride moved to Sat\", \"deload after 3 build weeks\"). The athlete's other assistant surface reads it later; without it, it sees only that the plan changed. No health details beyond what the plan needs.",
+  "maxLength": 200,
+  "type": "string"
+}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: it discloses that there is no undo, precisely what survives the operation (completed activities, day notes), and what the call reports back ('how many entries were removed, or says nothing was planned that day'). That is exactly the destructive-scope and outcome context an agent needs.

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 tight sentences with the scope decision front-loaded, then the preservation boundary, then the irreversibility and return behavior. No filler and no repetition of the name or title.

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 no output schema, the description correctly supplies the return semantics and the no-undo warning. It is complete for calling the tool, though it says nothing about permission or authorization requirements for a destructive operation, which would be the last missing piece.

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 coverage is 100%, so the schema baseline is 3, but the description adds real meaning by stating that `iid` comes from get_plan and that omitting it is a bulk clear for the day. It adds nothing about `why` or `noteEdits`, which rely entirely on their schema text.

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 precise verb+resource (remove planned work from the calendar) and disambiguates the two modes in one breath: a single entry by `iid`, or the whole day when `iid` is omitted. It distinguishes itself cleanly from siblings like delete_event, plan_workouts and copy_workouts by scoping itself to *planned* entries only.

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?

Explicit when-to-use: pass `iid` to drop one scheduled workout, omit it to clear the day. It also names the recovery path ('putting a session back is plan_workouts or copy_workouts') and states the exclusion boundary ('completed activities and the day's notes stay'), so the agent knows when NOT to reach for this tool.

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

All Blocks toolsInspect
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