Narrareach

Cancel scheduled item

cancel_scheduled_item

Destructive

Cancel a scheduled note or article, with optional kind or automatic detection by id. Use it when the writer no longer wants the item to publish. Do not cancel and schedule again just to change the time: use amend_scheduled_item or reschedule_scheduled_item, one step instead of two. An article's content, title, paywall, audience and email delivery cannot be changed in place; when one must change, confirm with the writer, then cancel once and schedule one replacement that carries every change. Cancelling a Substack article deletes its scheduled Substack draft, and any new or changed Substack schedule can ask the writer for a verification code.

Input Schema

Name	Required	Description	Default
`id`	Yes
`kind`	No

Output Schema

Name	Required	Description	Default
`id`	Yes
`kind`	Yes
`status`	Yes
`message`	No
`remoteEditUrl`	No
`alreadyCancelled`	No
`connectedAccount`	No
`distributionKind`	No
`cancellationQueued`	No
`remoteDraftRetained`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 14, 2026

addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / remoteDraftRetained
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / remoteEditUrl

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedOct 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructive=true and non-idempotent, but the description adds side effects not present in structured data: cancelling a Substack article deletes its scheduled Substack draft, and a Substack schedule may trigger a writer verification-code prompt. It also warns that article content/title/paywall/audience/email cannot be changed in place, which shapes correct usage.

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 core action and the when-not/alternative guidance in the same breath. The final two sentences on immutable article fields and Substack deletion are dense but each carries actionable workflow information; only mild trimming would help.

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?

A destructive mutation tool whose annotations cover safety, with an output schema covering returns, and the description still fills the gaps that matter: alternatives, destruction side effects, verification flow, and the immutability constraint. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 burden. It does explain that kind is optional and can be auto-detected from the id, but it never clarifies what kind of identifier id is (scheduled-item id vs. draft id) or its format.

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?

States a specific verb and resource ('Cancel a scheduled note or article') and clarifies that kind is optional because the id can auto-detect it. This distinguishes it cleanly from amend_scheduled_item and reschedule_scheduled_item, so an agent can select it 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 names the situation to use it ('writer no longer wants the item to publish') and an explicit anti-pattern with alternatives ('Do not cancel and schedule again just to change the time: use amend_scheduled_item or reschedule_scheduled_item'). It even gives the intended two-step-free workflow for immutable article fields.

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

All Narrareach 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?