Quick Viral Notes

My Substack

my_substack

Read-only

Your own Substack activity, subscribers and stats. Read only: it never likes, replies, posts or sends. Actions: replies_made, likes_given, notes_and_restacks, dms, day_summary (what you did in a time window, merged by person), dm_thread (one DM conversation with its text); subscribers_list, subscriber_details, subscriber_events (your publication's subscribers, owner only); note_stats (engagement and conversion for your published Notes, paged by cursor), post_stats (per-post conversions, ranked by new subscribers). Every activity response has coverage: only "pulled" means a zero is a real zero. Subscribers, dms, dm_thread and the stats need the QVN Chrome extension signed in. handle is the other person in a DM; substack_handle is you, for note_stats. 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": "my_substack"
  }
}

Input Schema

Name	Required	Description
`days`	No	Activity window in days ending now, 1-30. Default 1. Ignored when since is set.
`email`	No	Subscriber email address. Required for subscriber_details and subscriber_events.
`kinds`	No	day_summary only: which kinds to include. Defaults to all four.
`limit`	No	Results per call, checked per action server side. dm_thread: newest messages, max 200, default 50. subscribers_list: per page, max 200, default 50. subscriber_events: max 200, default 100. note_stats: max 20, default 20. post_stats: max 50, default 20.
`since`	No	Activity window start, ISO date or datetime with offset. Overrides days.
`until`	No	Activity window end, ISO date or datetime with offset. Defaults to now.
`action`	Yes	The operation to perform. Current actions: replies_made, likes_given, notes_and_restacks, dms, day_summary, dm_thread, subscribers_list, subscriber_details, subscriber_events, note_stats, post_stats. Pass "help" for the live list with parameters; actions added after you connected appear there and work without reconnecting.
`cursor`	No	note_stats only: pass next_cursor from a previous response to fetch the next older page. Omit to start from the newest note.
`filter`	No	subscribers_list only: "paid" or "free". Omit for all subscribers.
`handle`	No	dm_thread only: the OTHER person's Substack handle, with or without @.
`offset`	No	subscribers_list: pagination offset. Default 0.
`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.
`thread_id`	No	dm_thread only: thread_id from a dms row.
`paid_since`	No	subscribers_list + filter:"paid" only: ISO date (e.g. "2026-06-01") to return only subscribers who paid after it.
`substack_handle`	No	note_stats only: YOUR Substack handle, for first-time user ID resolution (e.g. "jennyouyang").

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses real behavioral traits: partial-data 'coverage' semantics where 'only "pulled" means a zero is a real zero,' an authentication dependency on the Chrome extension, and an owner-only restriction on subscriber data. It does not cover rate limits or how much history is reachable, keeping it short of 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.

Conciseness4/5

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

The scope and read-only guarantee are front-loaded, and each subsequent sentence earns its place with action-family groupings rather than prose padding. It is a dense semicolon-separated block, which packs well but is harder to scan than a short bulleted structure.

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 15-parameter, 11-action router with no output schema, the description supplies the missing return-shape information an agent needs: the `coverage` field on activity responses and `next_cursor` for paging. It leaves per-action parameter specifics to the 'help' action and the schema, which is a reasonable trade-off but means one extra call for full detail.

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 baseline is 3; every parameter already carries semantics in the schema. The description adds the useful relationship that unlisted per-action parameters go in `options` while listed ones must be top-level, but the handle vs. substack_handle distinction it makes is already spelled out in the schema fields.

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?

The description states a concrete resource and scope: 'Your own Substack activity, subscribers and stats,' and then enumerates the eleven actions so an agent knows the functional surface. The phrase 'Your own' implicitly separates it from a generic read tool like substack_read, but no sibling is named outright, so sibling differentiation must be inferred.

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?

It gives clear when-to-use context per action family (day_summary = 'what you did in a time window, merged by person'; dm_thread = 'one DM conversation with its text'; post_stats = 'per-post conversions, ranked by new subscribers'). It also states prerequisites (QVN Chrome extension signed in) and points to action 'help' for unlisted parameters, but it never says when NOT to use this tool versus substack_read or notes_studio.

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?