Substack Scraper MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token from console.apify.com/account/integrations. The server lists its tool without a token; a call needs one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scrape_substackA | Read Substack publications and posts, or search Substack by keyword. Give publications as URLs, domains, substack.com profiles, or bare Substack names (for example lenny.substack.com, https://www.notboring.co, lenny). Each publication returns one publication row (name, author, subscriber count as Substack shows it, subscriber tier text, paid plan prices) and its newest posts, one row each with date, free or paid audience, likes, comments, restacks, word count, bylines, and tags. Search queries return matching posts with their publication and subscriber count, or one row per publication when search_output is publications. Input with nothing to run returns one free row whose error_reason starts with input_invalid:. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per post row and per publication row. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With a single tool there is no inter-tool misselection risk, and the description clearly enumerates the three modes (publication read, post read, keyword search). However, the tool internally conflates distinct operations (fetching vs. searching), and the mode is selected via a search_output parameter, which is a mild ambiguity an agent must resolve from prose.
Only one tool exists, and it follows a clean verb_noun convention (scrape_substack) that matches the server name and domain. There is no mixing of conventions to penalize.
A single tool for a domain that spans publication lookup, post retrieval, and keyword search is thin, and the overloaded parameter surface suggests it could reasonably be split into fetch_publication, fetch_posts, and search_posts. It is not egregiously wrong, but the count is borderline for the described scope.
Read-only coverage of publications, posts, and search is reasonable for a scraper, but there are notable gaps: no way to fetch an arbitrary post by URL, no comments retrieval despite comments being reported, and no explicit pagination/limit controls. Agents hitting those needs will dead-end.