I'm a developer who learns by writing. The problem is I almost never finished writing.
The graveyard of half-finished articles on my hard drive tells the real story: 12 drafts I genuinely intended to publish. Topics I found interesting, problems I'd solved, things I thought were worth sharing. Each one abandoned somewhere between "rough idea" and "good enough to post."
It wasn't writer's block. It was friction. The research to figure out what's already been covered. The back-and-forth between editor, Dev.to, and my notes. The formatting, the tags, the series selection. None of it is hard — but all of it adds up to enough resistance that your brain finds something more immediately rewarding to do instead. Like fixing one more bug. Or reading one more article someone else already finished.
I work with AI tools every day. Claude Code handles the heavy engineering work. I gave it my codebase and it refactored, debugged, and planned alongside me. But when it came to writing — the thing I kept saying I wanted to do more of — I was still doing everything by hand.
So I built a bridge. An MCP server that connects Claude directly to Dev.to, turning the whole publish workflow into a conversation.
It didn't just help me publish faster. It changed the psychology of publishing entirely.
What Changes When the Friction Disappears
The biggest thing I noticed wasn't speed. It was that I stopped talking myself out of it.
Before: I'd have an idea, open a blank doc, start typing, realise I didn't know if someone had already written this exact thing, open Dev.to in another tab, spend 20 minutes searching, lose the thread, close the tab, tell myself I'd come back to it. I usually didn't.
After: I'd have an idea, open Claude Code, and say "search Dev.to for articles about X — what's already been covered and what's missing?" Thirty seconds later I have a map of the topic. I know exactly where my angle fits. The blank page problem evaporates because I'm not starting from nothing — I'm starting from a conversation.
That research step alone was the thing that killed most of my articles before they started. Removing it changed everything.
The drafting is also different. I'm not writing into a void and hoping it lands. I describe what I want to say, Claude drafts it, I reshape it into my voice, and the structure is already there. I'm editing, not starting. Editing is easy. Starting is hard. This shifts the work from the hard thing to the easy thing.
And once it's drafted — publishing is literally one message. "Looks good, publish it." Done.
The Workflow in Practice
Here's what an actual session looks like, from idea to published:
Me: "I want to write about setting up a local MCP server for Outlook.
Search Dev.to — what's already covered on this topic?"
Claude: [searches Dev.to]
"There are a few articles on MCP setup generally, but nothing
specifically about Outlook or email automation workflows.
Strong gap to write into."
Me: "Good. Check my existing series — does this fit anywhere?"
Claude: [checks my articles and series]
"You have an 'AI-Powered Developer Workflows' series.
This fits perfectly as the next entry."
Me: "Write it. Focus on the local server setup and the automation
angle. Keep it practical, not theoretical. Draft it on Dev.to."
Claude: [writes article, creates draft]
"Draft created. ID: 3341092. Ready for your review."
Me: "The setup section needs more detail — add the exact
config file path and a sample rule."
Claude: [updates the draft]
Me: "Perfect. Publish it."
Claude: [publishes]
"Live at https://dev.to/themeticulist/..."
Start to published: one conversation. No tab switching. No copy-pasting. No context loss.
The article that came out of that session? It's sitting on my Dev.to profile right now with reactions and comments. It wouldn't exist otherwise — it would have been draft number 13.
How to Set This Up Yourself
The server is open source at yashaswiyogeshwara/devto-mcp. Here's how to get it running.
1. Get your Dev.to API key
Go to Dev.to → Settings → Extensions → DEV Community API Keys → Generate a new key. Keep it — you'll need it in a moment.
2. Clone and build
git clone https://github.com/yashaswiyogeshwara/devto-mcp.git
cd devto-mcp
npm install
npm run build
3. Create your .env file
# devto-mcp/.env
DEVTO_API_KEY=your_key_here
4. Add it to Claude Desktop
Open %APPDATA%\Claude\claude_desktop_config.json and add:
{
"mcpServers": {
"devto": {
"command": "node",
"args": ["C:/path/to/devto-mcp/dist/index.js"],
"env": {
"DEVTO_API_KEY": "your_key_here"
}
}
}
}
Restart Claude Desktop. The Dev.to tools appear automatically in the MCP panel.
5. For Claude Code users
Add the same block to your claude_mcp_config.json (usually at %APPDATA%\Claude\claude_mcp_config.json). Claude Code picks it up on next launch.
What the Server Can Do
Eight tools cover the full cycle:
Research — search_articles finds what's already published on any topic. Filter by tag, author, or popularity. Run this before you write a word.
Planning — list_my_articles and list_series show your existing content so Claude can suggest where a new article fits, and flag if you're about to repeat yourself.
Writing — create_draft saves directly to Dev.to with published: false. You review in your browser before anything goes live. update_article lets you iterate — "make this section more concrete", "cut the intro", "add a code example" — all without leaving the conversation.
Publishing — publish_article is a deliberate, separate step. One message to ship. The separation matters: you always know when something is about to go live.
Tracking — get_article_analytics returns reaction counts and comments for any article.
One Gotcha Worth Knowing
If you're building on top of this or customising it: don't put YAML frontmatter in your article body. The Dev.to API has a quirk where frontmatter in body_markdown silently overrides your JSON parameters — your tags get replaced, your series disappears. The server already guards against this and throws a clear error if it detects frontmatter, but it's worth knowing why.
What Actually Changed for Me
I've published more in the past month than in the previous year. That's not because I suddenly have more ideas or more time — it's because the step between "I should write about this" and "this is published" shrank from a multi-session ordeal to a single conversation.
The tool doesn't write the articles for me. My voice, my examples, my perspective — that still has to come from me. But it handles everything around the writing. The research, the structure, the formatting, the publishing mechanics. It turns writing from a project into a conversation.
If you've got a graveyard of unpublished drafts, that's the thing worth fixing.
This article was drafted using the MCP server it describes.
Top comments (0)