Skip to main content
Glama
Dineshv0311

Dev.to Blog Publisher MCP Server

by Dineshv0311

Dev.to Blog Publisher MCP Server

A custom Model Context Protocol (MCP) server that lets Claude publish markdown blog posts directly to Dev.to — no copy-pasting into the Dev.to editor required.

Built with FastMCP and the Dev.to API.

Overview

This server exposes a single MCP tool, publish_blog_to_devto, which any MCP-compatible client (like Claude Desktop) can call to create an article on your Dev.to account. Pair it with the official filesystem MCP server and you can ask Claude to:

"Read blog.txt from my drafts folder, refine the content, and publish it to Dev.to as a draft with relevant tags."

Claude reads the file, cleans up the writing, and calls this server to publish it — all in one conversation, no manual formatting.

Related MCP server: cnblogs-mcp

Features

  • Publish articles as drafts or live

  • Set title, tags, series, canonical URL, and cover image

  • Uses your personal Dev.to API key — the key never leaves your machine except to call Dev.to's own API

Requirements

  • Python 3.10+

  • uv for package management

  • A Dev.to API key (Settings → Extensions → DEV Community API Keys)

  • Claude Desktop or another MCP-compatible client

Setup

1. Clone and install dependencies

git clone https://github.com/Dineshv0311/devto-mcp-server.git
cd devto-mcp-server
uv sync

2. Configure your API key

Copy the template and fill in your key:

cp .env.template .env

Then edit .env:

DEVTO_API_KEY=your_devto_api_key_here

⚠️ .env is listed in .gitignore — never commit your real API key.

Before wiring it into Claude Desktop, verify the server works using the MCP Inspector:

uv run mcp dev dev-server.py

This opens a local web UI where you can call publish_blog_to_devto directly and inspect the raw request/response — useful for catching issues before debugging through a chat interface.

4. Connect it to Claude Desktop

Open your Claude Desktop config file:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Add this server inside the top-level mcpServers key:

{
  "mcpServers": {
    "devto": {
      "command": "C:\\path\\to\\uv.exe",
      "args": ["--directory", "C:\\path\\to\\devto-mcp-server", "run", "dev-server.py"]
    }
  }
}

💡 On Windows, use the full path to uv.exe (find it with where.exe uv) — Claude Desktop doesn't always inherit your shell's PATH.

Fully quit and reopen Claude Desktop (check it's not lingering in the system tray) and confirm the server shows as running under Settings → Developer → Local MCP servers.

Usage

Once connected, talk to Claude normally:

"I have a file blog.txt in my drafts folder — refine its content and publish it to Dev.to as a draft with tags: mcp, ai, python."

Tool: publish_blog_to_devto

Parameter

Required

Description

title

Article title

body_markdown

Full article content in markdown

tags

List of tags (e.g. ["mcp", "ai", "python"])

published

true for live, false for draft (default: false)

series

Name of the series this article belongs to

canonical_url

Canonical URL if cross-posted

cover_image

URL of a cover image

Tip: publish with published: false first to review the draft on Dev.to before making it live.

Project Structure

devto-mcp-server/
├── dev-server.py         # MCP server + publish_blog_to_devto tool
├── devto-test.py         # Standalone test script for the Dev.to API call
├── example-config.json   # Example Claude Desktop config snippet
├── .env.template         # Template for required environment variables
├── pyproject.toml        # Project dependencies (managed by uv)
└── README.md

Troubleshooting

ModuleNotFoundError: No module named 'mcp.server.fastmcp' There's an unrelated package squatting the mcp name on PyPI. Pin the real SDK explicitly:

uv remove mcp
uv add "mcp[cli]>=1.2.0,<2.0.0"

Server doesn't show up in Claude Desktop Double-check devto is nested inside mcpServers in the config, not a sibling key. Fully restart Claude Desktop.

uv not found after installing Close and reopen your terminal so it picks up the updated PATH.

Dev.to API returns 422 Unprocessable Entity Usually means a duplicate title/slug already exists on your account. Try a slightly different title.

License

MIT — see LICENSE

Available Tools

1 tool
publish_blog_to_devtoA
Publishes a blog post to dev.to.

Args:
    title (str): The title of the blog post.
    body_markdown (str): The content of the blog post in Markdown format.
    tags (Optional[List[str]]): A list of tags for the blog post (e.g., ["python", "webdev"]).
    published (bool): Set to True to publish immediately, False to save as a draft.
    series (Optional[str]): The name of the series this article belongs to.
    canonical_url (Optional[str]): The canonical URL of the article if it's cross-posted.
    cover_image (Optional[str]): URL of the cover image for the article.

Returns:
    str: A message indicating the success or failure of the publishing operation,
         including the article URL if successful.
ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNo
titleYes
seriesNo
publishedNo
cover_imageNo
body_markdownYes
canonical_urlNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does explain the effect of the 'published' parameter and the return value, but it does not mention authentication, potential side effects, idempotency, or failure handling. It provides some transparency but leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence summary, followed by a detailed Args section and a Returns note. It is efficient, with no wasted words, and each parameter explanation earns its place given the schema's lack of descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all inputs and the return type, which is sufficient for a straightforward publishing action. However, it omits context about prerequisites (e.g., authentication credentials, rate limits) and specific failure modes. Given the tool's moderate complexity and presence of an output schema, a score of 4 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no descriptions for its parameters, so the description fully compensates. Each parameter (title, body_markdown, tags, published, series, canonical_url, cover_image) is explained with its meaning and role, including examples for tags and the behavior of the published flag. This is extensive and valuable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Publishes a blog post to dev.to,' which is a specific verb+resource statement. It clearly identifies the tool's action and target platform, leaving no ambiguity about its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (publishing to dev.to) but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Since there are no sibling tools, a score of 3 reflects the implied but not explicit usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedpublish_blog_to_devto

TDQS

A4/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusing it with others. The tool's purpose is clear from its name and description.

Naming Consistency5/5

The single tool uses a clear verb_noun pattern (publish_blog_to_devto), consistent with common MCP naming conventions, though there is no other tool to compare.

Tool Count3/5

Having exactly one tool for a blogging platform is very thin; a typical integration would need at least listing, updating, and deleting articles. This falls on the borderline of being too few.

Completeness2/5

The server only supports publishing posts; there are no operations for reading, updating, deleting, or listing existing articles. This is a significant gap that would prevent an agent from managing a blog lifecycle.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dineshv0311/devto-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server