Narrareach

Schedule notes

schedule_notes

Schedule up to 50 notes in one call, each exactly as schedule_note would (same platforms, limits, account defaults and Substack profile rules). Every note is checked first, and each gets its own result: scheduled (scheduleIds), duplicate (already scheduled with the same text, platform and time, so existingScheduleIds are returned and nothing is copied), or failed (reason says what to fix). When items have code SUBSTACK_NOTE_DRAFT_REVIEW, tell the writer how many were saved. Share their common connectionUrl to connect and review those same drafts together; connecting alone does not schedule them. One bad note does not stop the others. A note can quote a Substack Note or post with quoteUrl, as in schedule_note. Give every note its own clientRequestId and reuse the same ids when retrying the batch, so notes that already went through are returned rather than scheduled again. workspace, writer and publication apply to every note. For media, platformVersions, first replies or account choices, use schedule_note for that note.

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": {
      "notes": "<notes>"
    },
    "name": "schedule_notes"
  }
}

Input Schema

Name	Required	Description
`notes`	Yes
`writer`	No	Authorized team writer name, handle, or id for every note. Required when a team workspace has multiple writers.
`workspace`	No	Authorized team workspace name or id for every note. Absence selects the authenticated user’s personal account.
`publication`	No	Substack publication name, handle, or URL for every note that includes SUBSTACK. Optional when schedule_note would not ask for one.

Output Schema

Name	Required	Description	Default
`results`	Yes
`summary`	Yes
`connectedAccount`	No
`connectionWarnings`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 13, 2026
- addedOutput schema / properties / results / items / properties / connectionUrl
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / results / items / properties / draftUrl
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / notes / items / properties / timezone / description

Previous value: -"IANA timezone for scheduledFor (e.g. \"Europe/London\"). Default UTC."New value: +"IANA timezone for scheduledFor (e.g. \"Europe/London\"). Defaults to the writer's saved timezone, else UTC."

Changed2 schema fields changedOct 31, 2026

addedOutput schema / properties / connectionWarnings

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {},
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "summary",
-  "results"
-]New value: +[
+  "summary",
+  "results",
+  "connectionWarnings"
+]

Changed3 schema fields changedOct 19, 2026

addedInput schema / properties / notes / items / properties / shortVersion

Added value: +{
+  "additionalProperties": false,
+  "description": "One short text for several platforms, e.g. { \"text\": \"...\", \"platforms\": [\"X\", \"BLUESKY\", \"THREADS\"] }, while the other platforms post content as written. Saved as one shared short version the writer edits once in the app. It must fit the tightest platform it goes to (X 280 as one post, Bluesky 300, Threads 500, LinkedIn 3000) or nothing is scheduled. A platform in it cannot also be in platformVersions.",
+  "properties": {
+    "platforms": {
+      "items": {
+        "enum": [
+          "X",
+          "BLUESKY",
+          "THREADS",
+          "LINKEDIN"
+        ],
+        "type": "string"
+      },
+      "minItems": 1,
+      "type": "array"
+    },
+    "text": {
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "text",
+    "platforms"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / results / items / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / results / items / required

Previous value: -[
-  "index",
-  "status",
-  "clientRequestId",
-  "platforms",
-  "scheduledFor",
-  "scheduleIds",
-  "existingScheduleIds",
-  "supersededIds",
-  "code",
-  "reason"
-]New value: +[
+  "index",
+  "status",
+  "clientRequestId",
+  "platforms",
+  "scheduledFor",
+  "scheduleIds",
+  "existingScheduleIds",
+  "supersededIds",
+  "warnings",
+  "code",
+  "reason"
+]

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / notes / items / properties / quoteUrl

Added value: +{
+  "description": "Optional public Substack Note link (https://substack.com/@writer/note/c-123) or Substack post/article link (https://publication.substack.com/p/slug, or the publication's custom domain) to quote. Substack shows it as a quoted card under the note, like \"Restack with a note\". Do not also put the link in content; if it is there it is taken out. Requires SUBSTACK in platforms; every other platform gets the link at the end of its text instead. Cannot be combined with draftId. Nothing is scheduled when the Note or post cannot be found or is not public. Use preview_note_quote to check a link first.",
+  "maxLength": 2048,
+  "minLength": 1,
+  "type": "string"
+}

AddedOct 18, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the description's main job is to add per-item outcome semantics, which it does well: scheduled/duplicate/failed outcomes, partial-failure isolation ('One bad note does not stop the others'), and the SUBSTACK_NOTE_DRAFT_REVIEW reporting rule. However, the duplicate-detection and clientRequestId replay behavior reads as effectively idempotent for repeat submissions, which sits uneasily beside idempotentHint=false; the description does not reconcile the two, leaving an agent unsure whether a plain retry without reused ids would double-schedule.

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?

Long but dense and front-loaded: the batch scope and outcome model come first, retry guidance and the sibling escape hatch come last. A few clauses restate schema text (clientRequestId reuse, the quoteUrl pointer to schedule_note), but nothing is filler.

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?

For a 50-item batch mutation with an output schema, the description covers what an agent must know before calling: per-item result shapes, duplicate handling, partial failure, draft-review codes, and when to fall back to the single-note tool. Remaining gaps are covered by the schema and output schema.

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 75%, and the description adds real meaning beyond it: clientRequestId must be unique per note and reused on retry, workspace/writer/publication are batch-wide, and unsupported per-note fields must be routed to schedule_note. It does not add anything about timezone, scheduledFor or quoteUrl that the schema does not already say in detail.

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?

Opens with a specific verb, resource and scope: 'Schedule up to 50 notes in one call', and immediately anchors semantics to its sibling ('each exactly as schedule_note would'). An agent can distinguish this batch tool from schedule_note without inspecting either 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 routes the agent away from this tool for cases it cannot handle: 'For media, platformVersions, first replies or account choices, use schedule_note for that note.' It also prescribes retry procedure (reuse the same clientRequestId values) and clarifies that sharing a connectionUrl to review drafts does not schedule them.

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?