Skip to main content
Glama
Sign In
thenavidm

substack-mcp

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Schedule a Note

schedule_note

Queue a Substack Note to publish at a chosen time from an AI tool or command line, with batch scheduling, a checkable list, and cancellation. The queue sends due Notes while the server runs.

Instructions

Queue a Note to publish later, from here. Substack's own composer can also schedule a Note; this queue adds scheduling from an AI tool or the command line, in batches, with a list to check and cancel.

It only fires while a server is running. A Note scheduled for 9am publishes at 9am if your machine is awake with your MCP client open, and otherwise on the next start after that time, marked as published late. For scheduling that does not depend on your laptop, run this server continuously over HTTP or in Docker, or schedule the Note in Substack's composer.

Every AI tool you open runs its own server, and they share one queue: each Note is claimed before it is sent, so it goes out once. A send that cannot reach Substack is tried again after 1, 5 and 15 minutes; one with no answer is marked for you to check, never sent twice.

Scheduling is not publishing, so this does not require a confirmation. The Note goes out publicly when it fires.

Input Schema

NameRequiredDescriptionDefault
textYesThe Note's text.
publish_atYesWhen to publish, as an ISO 8601 datetime, for example 2026-09-15T09:00:00Z.
publicationNoWhich connected publication to act on, matched loosely against its hostname (for example 'example.substack.com' or just 'example'). Defaults to the first connected publication.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.0.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv2.1.1

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: the note only fires while the server is running, otherwise publishes late on next start; multiple MCP servers share one queue with claim-before-send guaranteeing single delivery; retries at 1/5/15 minutes for unreachable sends; no confirmation required. None of this is derivable from readOnlyHint=false or openWorldHint=true.

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?

Purpose is front-loaded in the first clause, and each subsequent paragraph carries a distinct, decision-relevant caveat (runtime dependency, queue semantics, retry policy, no-confirmation rule). It is on the long side for a tool description, but no sentence is filler.

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?

There is no output schema, so the description should ideally say what a successful schedule returns (an id, a queued confirmation), and it does not. However, it fully covers the behavioral caveats an agent needs to decide whether calling it is safe and reliable.

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 100%, so all three parameters are already documented in the schema. The description adds only indirect hints (batch scheduling, the queue having a list to check and cancel) and no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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+resource+scope: "Queue a Note to publish later, from here." It also explicitly contrasts itself with Substack's own composer and with immediate publishing ("Scheduling is not publishing"), so an agent can distinguish it from publish_note, publish_note_with_link, and schedule_draft without opening schemas.

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?

Gives explicit when-to-use context (scheduling from an AI tool or CLI, in batches) and names the alternative (Substack's composer) plus the condition that selects it (scheduling that must not depend on your laptop). It also points at the companion pair of list/cancel tools.

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

Deploy Server

Other Tools