Skip to main content
Glama
Anuragck

Dev Blog MCP Server

by Anuragck
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Dev Blog MCP Server

A Model Context Protocol (MCP) server that enables AI assistants to publish blog posts directly to Dev.to. This server provides a seamless way to integrate blog publishing capabilities into your AI workflows.

Features

  • šŸš€ Direct Dev.to Publishing: Publish blog posts directly to Dev.to via MCP

  • šŸ“ Rich Content Support: Full Markdown support with tags, series, and cover images

  • šŸ”’ Secure API Integration: Uses environment variables for API key management

  • šŸ› ļø Easy Integration: Simple setup with uv package manager

  • šŸ“Š Comprehensive Logging: Detailed logging for debugging and monitoring

Related MCP server: Dev.to Blog Publisher MCP Server

Prerequisites

Before you begin, ensure you have the following installed:

  • Python 3.13+

  • uv (Python package manager)

  • Git (for version control)

  • Dev.to API Key (get it from Dev.to Settings)

Installation

1. Install uv (if not already installed)

# On macOS and Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# On Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

# Or using pip
pip install uv

2. Clone the Repository

git clone https://github.com/anuragck2/dev-blog-mcp-server.git
cd dev-blog-mcp-server

3. Install Dependencies

# Install project dependencies using uv
uv sync

4. Environment Setup

Create a .env file in the project root:

# Copy the example environment file
cp .env.example .env

# Edit the .env file and add your Dev.to API key
echo "DEVTO_API_KEY=your_devto_api_key_here" > .env

Get your Dev.to API key:

  1. Go to Dev.to Settings

  2. Scroll down to the "API Keys" section

  3. Generate a new API key

  4. Copy the key and add it to your .env file

Usage

Running the MCP Server

# Activate the virtual environment and run the server
uv run python main.py

The server will start and listen for MCP connections via stdio transport.

Using with MCP Inspector

The MCP Inspector is a powerful tool for testing and debugging MCP servers. Here's how to set it up:

1. Install MCP Inspector

# Install MCP Inspector globally
npm install -g @modelcontextprotocol/inspector

2. Configure MCP Inspector

Create a configuration file for the MCP Inspector:

{
  "mcpServers": {
    "dev-blog-mcp-server": {
      "command": "uv",
      "args": ["run", "python", "main.py"],
      "cwd": "/path/to/your/dev-blog-mcp-server"
    }
  }
}

3. Run MCP Inspector

# Start the MCP Inspector
mcp-inspector

This will open a web interface where you can:

  • Test the publish_blog_to_devto tool

  • View server logs

  • Debug MCP communication

  • Monitor tool execution

Using with Claude Desktop

To use this MCP server with Claude Desktop:

  1. Open Claude Desktop Settings

  2. Add MCP Server Configuration

Add the following to your Claude Desktop configuration:

{
  "mcpServers": {
    "dev-blog-mcp-server": {
      "command": "uv",
      "args": ["run", "python", "main.py"],
      "cwd": "/path/to/your/dev-blog-mcp-server"
    }
  }
}

  1. Restart Claude Desktop

After adding the configuration, restart Claude Desktop to load the new MCP server.

API Reference

publish_blog_to_devto Tool

Publishes a blog post to Dev.to with the following parameters:

Parameter

Type

Required

Description

title

string

āœ…

The title of the blog post

body_markdown

string

āœ…

The content in Markdown format

tags

List[string]

āŒ

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

published

boolean

āŒ

Set to true to publish immediately, false for draft

series

string

āŒ

The name of the series this article belongs to

canonical_url

string

āŒ

Canonical URL if cross-posted

cover_image

string

āŒ

URL of the cover image

Example Usage

# Example tool call
publish_blog_to_devto(
    title="Getting Started with MCP",
    body_markdown="# Introduction\n\nThis is a great article about MCP!",
    tags=["mcp", "ai", "tutorial"],
    published=False,  # Save as draft
    series="MCP Fundamentals"
)

Development

Project Structure

dev-blog-mcp-server/
ā”œā”€ā”€ main.py              # Main MCP server implementation
ā”œā”€ā”€ pyproject.toml       # Project configuration and dependencies
ā”œā”€ā”€ .env.example         # Environment variables template
ā”œā”€ā”€ sample_prompt.md     # Sample prompts for testing
ā”œā”€ā”€ README.md           # This file
ā””ā”€ā”€ uv.lock             # Dependency lock file

Adding New Features

  1. Add new tools by creating functions decorated with @mcp.tool()

  2. Update dependencies in pyproject.toml

  3. Test with MCP Inspector before deploying

  4. Update documentation in this README

Testing

# Run the server in development mode
uv run python main.py

# Test with MCP Inspector
mcp-inspector

Troubleshooting

Common Issues

  1. "DEVTO_API_KEY environment variable not set"

    • Ensure your .env file exists and contains the correct API key

    • Verify the API key is valid and has the necessary permissions

  2. "Network or API request error"

    • Check your internet connection

    • Verify the Dev.to API is accessible

    • Ensure your API key has not expired

  3. MCP Inspector connection issues

    • Verify the server is running

    • Check the configuration file paths

    • Ensure all dependencies are installed

Debug Mode

Enable debug logging by modifying the logging level in main.py:

logging.basicConfig(level=logging.DEBUG, format='%(asctime)s - %(levelname)s - %(message)s')

Contributing

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add some amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

License

This project is licensed under the MIT License - see the LICENSE file for details.

Support

Acknowledgments

Happy Blogging! šŸš€

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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It explains that the tool publishes or saves a draft and returns a success/failure message with the article URL. However, it does not mention prerequisites like authentication, the public/irreversible nature of publishing, or potential side effects (e.g., modifying existing posts). This is adequate but not exhaustive.

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-organized with a one-line summary, a bullet-like Args list, and a Returns section. Each line provides essential information without fluff or redundancy. It is front-loaded with the core purpose, making it easy for an agent to quickly grasp the tool's function and parameters.

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?

Given the tool's complexity (7 parameters, no annotations), the description covers all parameters and the return value adequately. It does not mention prerequisites like API authentication or rate limits, but these may be implicit for a dev.to integration. The presence of an output schema and the Returns section reduce the need for additional return-value explanation. Overall, it is sufficiently complete for an agent to use the tool correctly.

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 input schema has no parameter descriptions (0% coverage), so the description's Args section is the sole source of parameter meaning. It explains every parameter clearly, including the distinction for 'published' (True for immediate, False for draft), examples for 'tags', and the purpose of 'canonical_url' (cross-posting). This exceeds the schema's minimal type/title information.

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 begins with a clear, action-oriented statement: 'Publishes a blog post to dev.to.' This specifies the exact verb, resource, and target platform, leaving no ambiguity about the tool's function. Since there are no sibling tools, there is no differentiation needed, but the purpose is fully clear.

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 does not explicitly state when to use this tool or provide alternatives, but the tool name and opening sentence make its usage obvious. It lacks guidance on edge cases (e.g., when to use draft vs. publish) beyond parameter semantics, so usage context is only implied rather than explicitly directed.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or misselection. The tool's purpose is clear from its name and description.

Naming Consistency4/5

The single tool name 'publish_blog_to_devto' is descriptive and follows a verb-object pattern, though it's somewhat verbose. Since there is only one tool, consistency is trivially maintained.

Tool Count1/5

A single tool for a blog publishing server is extremely thin. Typical blog workflows require listing, editing, and deleting posts, so one tool is insufficient for the apparent scope.

Completeness1/5

The tool only supports publishing, with no ability to retrieve, update, or delete existing posts. This leaves significant gaps in the content lifecycle and would force agents to use external APIs.

Maintenance

ActivityInactive
ResponsivenessSyncing

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/Anuragck/dev-blog-mcp-server'

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