Skip to main content
Glama

Narrareach

by com.narrareach
OverviewDiscussionsAdmin

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). 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesYes
writerNoAuthorized team writer name, handle, or id for every note. Required when a team workspace has multiple writers.
workspaceNoAuthorized team workspace name or id for every note. Absence selects the authenticated user’s personal account.
publicationNoSubstack publication name, handle, or URL for every note that includes SUBSTACK. Optional when schedule_note would not ask for one.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYes
summaryYes
connectedAccountNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • 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"
+]
  2. Changed1 schema field changed
    • 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"
+}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly=false, idempotent=false, destructive=false, openWorld=true. The description adds substantial behavior beyond that: per-note outcomes (scheduled/duplicate/failed), partial-failure semantics ("one bad note does not stop the others"), duplicate detection keyed on text+platform+time, and the clientRequestId idempotency mechanism. This is rich disclosure, not a restatement.

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 core purpose and the sibling alternative are front-loaded, and nearly every clause carries information. It is dense, single-paragraph prose with no visual structure, which slightly hurts scanability for a tool this complex.

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?

With an output schema present, return values need not be described, yet the description still summarizes the result shape (scheduleIds, existingScheduleIds, reason). Combined with the alternatives and retry guidance, an agent has everything needed to call it correctly.

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% (baseline 3), but the description adds real meaning: it explains that workspace, writer and publication apply to every note, that quoteUrl behaves as in schedule_note, and how clientRequestId drives safe retries. These clarify batch-level scoping the schema doesn't fully spell out.

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 with explicit scope ("Schedule up to 50 notes in one call") and frames itself as the batch counterpart to schedule_note. An agent can distinguish it from the single-note sibling 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 routes the agent: "For media, platformVersions, first replies or account choices, use schedule_note for that note." It also gives the retry protocol (reuse the same clientRequestIds) and the duplicate-handling condition, leaving little to inference.

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

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