I Had 12 Unpublished Articles Sitting in Drafts. An MCP Server Fixed That.
Source: Dev.to
I’m a developer who learns by writing… but I never finish
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:
- research to figure out what’s already been covered
- the back‑and‑forth between editor, Dev.to, and my notes
- formatting, tags, series selection
None of it is hard, but all of it adds up to enough resistance that my brain finds something more immediately rewarding—like fixing one more bug or reading someone else’s finished article.
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 | After |
|---|---|
| I have an idea → open a blank doc → start typing → realize I don’t know if someone already wrote this → open Dev.to in another tab → spend ~20 min searching → lose the thread → close the tab → tell myself I’ll come back later (and usually don’t). | I have an idea → open Claude Code and say “search Dev.to for articles about X — what’s already covered and what’s missing?” → 30 s later I have a map of the topic, know exactly where my angle fits, and the blank‑page problem evaporates because I’m starting from a conversation, not from nothing. |
That research step alone killed most of my articles before they even started. Removing it changed everything.
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 → published: one conversation. No tab‑switching. No copy‑pasting. No context loss.
The article that came out of that session is now on my Dev.to profile with reactions and comments. It wouldn’t exist otherwise—it would have been draft #13.
How to Set This Up Yourself
The server is open source at yashaswiyogeshwara/devto-mcp. Follow these steps 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 and keep it handy.
2. Clone and build
git clone https://github.com/yashaswiyogeshwara/devto-mcp.git
cd devto-mcp
npm install
npm run build3. Create your .env file
# devto-mcp/.env
DEVTO_API_KEY=your_key_here4. 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 claude_mcp_config.json (usually at %APPDATA%\Claude\claude_mcp_config.json). Claude Code picks it up on the next launch.
What the Server Can Do
Eight tools cover the full cycle:
| Tool | Purpose |
|---|---|
search_articles | Finds what’s already published on any topic. Filter by tag, author, or popularity. Run this before you write a word. |
list_my_articles | Shows your existing content so Claude can suggest where a new article fits. |
list_series | Lists your series, helping avoid duplicate entries. |
create_draft | Saves directly to Dev.to with published: false. Review in your browser before anything goes live. |
update_article | Iterate on a draft – “make this section more concrete”, “cut the intro”, “add a code example”. |
publish_article | Publishes the draft with a single command. |
delete_draft | Clean up unwanted drafts. |
add_tags | Apply tags to a draft or published article. |
These tools let you research, plan, write, edit, and publish without ever leaving the conversation with Claude.
TL;DR
Friction kills writing. By wiring Claude directly to Dev.to with an MCP server, the research, drafting, and publishing steps become a seamless dialogue. The result? Faster publishing, fewer abandoned drafts, and more confidence that your ideas will see the light of day. Give it a try—your future self will thank you.
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 customizing it: don’t put YAML front‑matter in your article body. The Dev.to API has a quirk where front‑matter 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 front‑matter, 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.