Skip to main content
Glama
Sign In
thenavidm

substack-mcp

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List scheduled Notes

list_scheduled_notes
Read-onlyIdempotent

Review scheduled Substack Notes in soonest-first order to see which are waiting, published or late, failed, canceled, or need checking after unclear sends.

Instructions

List Notes queued by schedule_note, soonest first: which are waiting, which published (and whether late), which failed and why, and which to check because a send got no answer, so they may or may not have gone out.

Input Schema

NameRequiredDescriptionDefault
statusNoFilter by status. Omit to see all of them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.1.0
    • changedInput schema / properties / status / enum
      Previous value: -[
-  "scheduled",
-  "published",
-  "failed",
-  "canceled"
-]New value: +[
+  "scheduled",
+  "publishing",
+  "published",
+  "failed",
+  "check",
+  "canceled"
+]
  2. Changed2 schema fields changedv3.0.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observedv2.1.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the read-only, idempotent, non-destructive nature of the tool. The description adds substantial behavioral context: it explains ordering, the meaning of each status category, including late publication, failure reasons, and ambiguous 'check' states where a send received no answer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately states the action, origin, and ordering before enumerating status categories. Every clause contributes useful information about the return set, and there is no 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 read-only list tool with one optional filter, no output schema, and rich annotations, the description is complete enough for correct invocation. It explains the ordering and what each status means, covering the relevant return-value context without needing to document pagination or safety behavior already covered elsewhere.

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 coverage is 100%, and the single optional status parameter is fully documented in the schema with an enum and an explanation to omit it for all statuses. The description adds no additional syntax or filtering semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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?

The description states a specific verb and resource (list Notes queued by schedule_note) and distinguishes this from general Note listing by scoping it to scheduled items. It also specifies ordering (soonest first), making the tool's purpose unambiguous against siblings like list_notes or list_scheduled_posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by the description: this tool is for inspecting Notes that were queued by schedule_note. However, it does not explicitly say when to choose this tool over alternatives such as list_notes or cancel_scheduled_note, nor does it provide exclusions or prerequisite guidance.

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