Quick Viral Notes

Substack Write

substack_write

Destructive

Post, schedule and engage on Substack as the signed-in member. Each call acts on the member's real account. Actions: post (now, or schedule with trigger_at), update_published, delete_published (permanent, irreversible), list_scheduled_drafts, sync_stats, sync_status, image_upload_token, video_upload_token; like, unlike, restack, unrestack, reply (Note only), comment (post only), delete_comment (your own). Note content is HTML, not markdown: for formats and the exact call per format, use notes_studio action posting_formats. Engage only on items the member chose, post only replies and comments the member approved, keep a human pace, and never loop over a whole feed. To quote an article in a Note, use post with quote. If post returns outcome "unknown", check list_scheduled_drafts or the profile before any retry. Call action help for parameters.

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": {
      "action": "<action>"
    },
    "name": "substack_write"
  }
}

Input Schema

Name	Required	Description
`text`	No	reply (Notes) and comment (posts): the text to publish, 1-5000 characters.
`force`	No	sync_stats: bypass the 10-min per-user cooldown and re-sync now.
`limit`	No	list_scheduled_drafts: max drafts to return. Default 20, max 100 (checked server side).
`quote`	No	post: quote card. {article_url: the Substack article, text: the exact sentence(s) from ONE paragraph, theme?: one of primary, orange, green, tintedImageVibrant, tintedImageMuted, fadedImage, blurredImage, Vibrant, DarkVibrant, LightVibrant, Muted, DarkMuted, LightMuted (omit for Substack's default), alignment?: "left" \| "center"}. The quote must be visible to the member (paid text only for paid readers).
`action`	Yes	The operation to perform. Current actions: post, update_published, delete_published, list_scheduled_drafts, sync_stats, sync_status, image_upload_token, video_upload_token, like, unlike, restack, unrestack, reply, comment, delete_comment. Pass "help" for the live list with parameters; actions added after you connected appear there and work without reconnecting.
`content`	No	update_published: full new HTML body. HTML only, NO markdown. Tags: <p>, <strong>, <em>, <code>, <pre>, <blockquote>, <ul>, <ol>, <a>. @Label mentions are matched against the mentions list.
`options`	No	Extra parameters for an action whose params are not listed in this schema (see action "help"). Parameters that ARE listed in this schema must be passed at top level; here they are ignored.
`mentions`	No	People to @mention. Omit on update_published to preserve existing mentions.
`max_pages`	No	sync_stats: pages of 20 notes to fetch (default 5 = 100 notes). <=3 runs inline; larger runs in the background.
`target_id`	No	like, unlike, restack, unrestack, reply, comment, delete_comment: id of the Note or post to act on.
`comment_id`	No	delete_comment: id of the member's own reply or comment (returned by reply and comment).
`image_urls`	No	post: HTTPS image file URLs to attach (1–6). Displayed as an image gallery.
`plain_text`	No	post: note text. Newlines become separate paragraphs. Required for post.
`trigger_at`	No	post: ISO 8601 datetime WITH timezone to schedule (e.g. "2026-06-10T15:17:00-04:00"). Omit to post immediately.
`target_type`	No	like, unlike, restack, unrestack, reply, comment, delete_comment: "note" (target_id = the number after "c-" in the Note URL) or "post" (target_id = the numeric post id, e.g. from substack_read get_feed or the "p-" number in a post URL).
`attachment_ids`	No	update_published: attachment IDs to set (integer or UUID string for post/video attachments). Omit to preserve existing. Pass [] to remove all.
`attachment_urls`	No	post, update_published: Substack article or note URLs to attach as link cards.
`image_data_uris`	No	post: base64 data URIs for local image files ("data:<mime>;base64,<b64>"). Counts toward the 6-image cap shared with image_urls.
`substack_handle`	No	sync_stats: YOUR Substack handle for first-time user ID resolution (e.g. "jennyouyang").
`substack_note_id`	No	Substack note ID (the number after "c-" in the URL). Required for update_published, delete_published.
`video_upload_key`	No	post: native Substack video key from the local MP4 upload path (action video_upload_token). One MP4, at most 5 minutes. Add trigger_at to schedule.
`reply_minimum_role`	No	Who can reply: "everyone" (default), "paid", etc. Used by update_published and post.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already flag destructive, open-world and non-idempotent; the description adds real context beyond them: delete_published is permanent and irreversible, every call acts on the member's live account, and ambiguous 'unknown' outcomes require verification before retry. It does not cover rate limits or auth failure behavior (the cooldown detail lives only in the schema), keeping it below a 5.

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?

Front-loads the core purpose, then compresses actions into a compact list and follows with the operational caveats that matter most (HTML not markdown, nothing irreversible without approval, unknown-outcome handling). Every sentence carries actionable information and nothing is repeated from the schema.

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 22-parameter, multi-action, destructive tool with no output schema, the description covers the destructive action, scheduling, content format, quoting, and the ambiguous-result case. The main remaining gap is that return shapes and most per-action parameter mappings are pushed to a `help` call rather than documented inline.

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?

With 100% schema coverage the baseline is 3, and the description largely defers to it with 'Call action `help` for parameters.' It does add useful cross-parameter routing rules — listed params must go top level, unlisted ones go in `options`, and trigger_at schedules while its absence posts now — but leaves per-action parameter mapping to the help action.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb family and resource ('Post, schedule and engage on Substack as the signed-in member') and enumerates every action, so an agent can tell it apart from substack_read and notes_studio. It stops short of explicitly contrasting with the read sibling, so sibling differentiation is implied rather than stated.

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 concrete when-to guidance: use notes_studio `posting_formats` for note HTML formats, use `post` with `quote` to quote an article, and check `list_scheduled_drafts` after an 'unknown' outcome before retrying. It also sets engagement guardrails (only member-chosen items, only approved replies/comments, human pace, no feed-wide loops), but never says when to prefer a sibling tool over this one.

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

All Quick Viral Notes 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?