What I love about this is that you built a stable layer between your tools and Substack. Now, when Substack changes something, you only fix one place instead of chasing breakage across five repos.
Using Pythong for this instead of TS is the right call. I don’t have a Substack MCP but rather a backup of all my posts and csv with analytics that Claude Code reads whenever we’re planning work
very cool, thanks for the share!
Thanks! The gateway has been surprisingly useful beyond just Claude — ends up being a clean read model for the whole publication.
What I love about this is that you built a stable layer between your tools and Substack. Now, when Substack changes something, you only fix one place instead of chasing breakage across five repos.
That's the core of it. One contract, one place to fix. The rest of the system doesn't care what Substack changes internally.
Using Pythong for this instead of TS is the right call. I don’t have a Substack MCP but rather a backup of all my posts and csv with analytics that Claude Code reads whenever we’re planning work
Python was a no-brainer here — FastMCP, Pydantic, done. Your approach reminds me that sometimes the simplest read model is just a flat file.
The boring middle layer is always the work nobody talks about and everybody eventually needs.
Boring to build, invisible when working, painful when missing. The holy trinity of infrastructure.
I will be interested to see how your workflow develops if Substack is releasing their own MCP. Chris Best hinted at it in interviews
Honestly, official MCP would be great — I'd happily throw away half my code if it meant a maintained, typed contract. Until then, the gateway stays.
Excellent points throughout. A reliable hosting environment helps businesses focus on growth rather than technical issues.