A Substack MCP Should Show You More Than Just Drafts
Part 5 of 9
I didn’t want this to be a write-only Substack MCP.
If I’m using a tool to publish, I also want it to help me understand what’s happening inside the publication.
So I added:
get_post_analytics
get_sections
get_subscriber_count
That made...
abanoubashraf.hashnode.dev1 min read
The read/write asymmetry in MCP servers is a real pattern. Most integrations start as write-only because thats minimum viable. But read capabilities are what make agents genuinely useful.
Three observations:
State surface area: Write operations have clear boundaries. Read operations need to expose platform state at the right granularity. Substack has sections, subscriber counts, analytics - all state that informs writing decisions.
Caching semantics: Read operations enable caching strategies. Write-only MCPs require optimistic actions. Read-capable MCPs let agents cache state and make informed decisions.
Permission boundaries: Write operations are high-stakes. Read operations expose platform internals. The choice: expose everything for flexibility, or curate for safety.
The shift from what can I create to what do I know about the system is the difference between an automation tool and a genuine agent assistant.