Skip to main content
Glama
thenavidm

substack-mcp

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Schedule a Note

schedule_note

Queue a Substack Note to publish at a future time. Since Substack lacks native Note scheduling, the server stores it locally and publishes when due while running.

Instructions

Queue a Note to publish later. Substack has no native Note scheduling, so the queue is kept locally and this server publishes the Note when it comes due.

That means it only fires while this 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. Nothing is dropped. For scheduling that does not depend on your laptop, run this server continuously over HTTP or in Docker.

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

Input Schema

TableJSON 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.3/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true) by disclosing the local-queue architecture, the awake-machine precondition, late-publish marking, the 'nothing is dropped' guarantee, the absence of a confirmation prompt, and that the Note goes out publicly. This is exactly the behavioral context an agent needs and cannot get from structured fields.

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 sentence, and the paragraphing separates purpose, caveat, and usage advice. Slightly verbose: 'Nothing is dropped' restates the preceding late-publish explanation, and the Docker/HTTP advice is a touch tangential for a tool definition.

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?

For a mutation tool with annotations and no output schema, the timing and delivery semantics are thoroughly covered. The one gap is return behavior: with cancel_scheduled_note and list_scheduled_notes as siblings, the agent would benefit from knowing whether this returns a schedulable identifier. Not fatal, but a real omission.

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% and all three parameters are documented there, so the schema carries the load. The description discusses timing semantics conceptually (9am example) but adds no format or matching detail beyond what the schema already states for publish_at or publication. Baseline 3 applies.

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: 'Queue a Note to publish later,' and immediately clarifies that this is distinct from native Substack behavior ('Substack has no native Note scheduling, so the queue is kept locally'). An agent can separate this from publish_note (immediate) and schedule_draft (drafts) 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: it only fires while the server is running, and names the alternative deployment ('run this server continuously over HTTP or in Docker') when laptop-dependence is unacceptable. It also distinguishes scheduling from publishing ('this does not require a confirmation'), but never explicitly contrasts with publish_note or schedule_draft as tool-selection alternatives.

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