Connect Dev.to to Claude: Create, Edit, and List Technical Posts

If you need to connect Dev.to to Claude to automate technical content pipelines, manage cross-posted blogs, or streamline your developer relations operations, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's LLM tool calls and Dev.to's underlying REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting Dev.to to ChatGPT or explore our broader architectural overview on connecting Dev.to to AI Agents.

Giving a Large Language Model (LLM) read and write access to a developer publishing platform like Dev.to is an engineering challenge. You have to handle API key lifecycles, map nested JSON schemas to MCP tool definitions, and deal with Forem's strict API constraints. Every time Dev.to updates an endpoint or changes a payload requirement, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Dev.to, connect it natively to Claude Desktop, and execute complex publishing workflows using natural language.

The Engineering Reality of the Dev.to API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against Dev.to's APIs is painful. Dev.to is powered by the open-source Forem architecture. Its API was built to serve the Forem frontend first, meaning it carries specific design patterns that do not always translate cleanly to LLM tool calling.

If you decide to build a custom MCP server for Dev.to, here are the specific integration challenges you will face:

Strict Payload Nesting and Tag Limits Unlike standard REST APIs that accept flat JSON payloads for creation events, Dev.to strictly requires article creation payloads to be wrapped in an article object. Furthermore, Dev.to enforces a hard limit of exactly four tags per article. Because most blogging platforms allow unlimited tags, LLMs frequently hallucinate requests with five or six tags, resulting in immediate HTTP 422 Unprocessable Entity errors. You must build an abstraction layer that intercepts LLM outputs, enforces the four-tag limit, and constructs the nested {"article": {...}} payload before hitting the Forem backend.

Fragmented Article State Endpoints In a typical REST API, querying published versus unpublished drafts is handled by a simple query parameter (e.g., ?status=draft). Dev.to fragments these concepts entirely. Querying your published articles hits /api/articles/me/published, while querying drafts requires a separate call to /api/articles/me/unpublished. An LLM has no context on this architectural split. If you ask Claude to "list all my articles," a naive implementation will miss half the user's content. Your MCP server must aggregate these fragmented endpoints into distinct, clearly defined tools so the LLM understands exactly which state it is querying.

Transparent Rate Limit Handling Dev.to enforces strict rate limits to prevent spam on the platform. When building an MCP server, a common mistake is attempting to build internal retry queues within the server itself. This leads to connection timeouts and disjointed LLM responses. Truto takes a deterministic approach: it does not retry, throttle, or apply backoff on rate limit errors. When Dev.to returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (the LLM or your agent framework) is fully responsible for reading these headers and executing the appropriate backoff.

How to Create a Managed Dev.to MCP Server

Truto's MCP architecture turns any connected Dev.to account into a fully compliant JSON-RPC 2.0 endpoint. Tool generation is dynamic and documentation-driven. Rather than hand-coding tool definitions for Dev.to, Truto derives them from the integration's resource endpoints and attached JSON Schema documentation.

You can generate this server using either the Truto UI or programmatically via the Truto API.

Method 1: Via the Truto UI

For IT admins or developers looking for immediate access, the Truto dashboard provides a one-click deployment interface.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Dev.to account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure the server parameters. You can filter the server to only allow read operations if you want Claude to analyze your blogs without the risk of publishing them.
5. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method 2: Via the Truto API

For engineering teams embedding AI capabilities into their own infrastructure, MCP servers can be provisioned programmatically.

Make a POST request to /integrated-account/:id/mcp. Truto runs an AI-readiness check to ensure the Dev.to integration has documented tools available, generates a cryptographically hashed token stored in Cloudflare KV, and returns a ready-to-use URL.

curl -X POST https://api.truto.one/api/integrated-account/{dev_to_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Dev.to Content Pipeline MCP",
    "config": {
      "methods": ["read", "write"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The response returns the self-contained endpoint. This URL contains a cryptographic token that encodes the Dev.to account, the tool filters, and the expiration time. No further client-side auth is required.

{
  "id": "mcp_8f92j39k",
  "name": "Dev.to Content Pipeline MCP",
  "config": { "methods": ["read", "write"] },
  "expires_at": "2026-12-31T23:59:59.000Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6g7h8..."
}

How to Connect the Dev.to MCP Server to Claude

Once you have your Truto MCP URL, connecting it to Claude is a straightforward process. You do not need to install local npm packages or manage python environments; the remote URL handles the entire JSON-RPC lifecycle.

Method 1: Via the Claude UI

If you are using Claude's web interface or enterprise workspace, you can add the server directly via the UI settings.

1. In Claude, navigate to Settings -> Integrations -> Add MCP Server.
2. Paste your Truto MCP Server URL (https://api.truto.one/mcp/...).
3. Click Add.

Claude will immediately execute the initialize handshake. The Truto router will respond with the protocol version (2024-11-05) and the Dev.to tool capabilities. Claude is now ready to interact with your developer profile.

Method 2: Via the Manual Config File (Claude Desktop)

If you are using Claude Desktop, you must configure the local JSON file to point to the remote Truto server. Truto communicates over Server-Sent Events (SSE), so you will use the official @modelcontextprotocol/server-sse package to bridge the local desktop client to the remote HTTP endpoint.

Open your Claude Desktop configuration file:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the Dev.to server configuration:

{
  "mcpServers": {
    "dev_to_publishing": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f6g7h8..."
      ]
    }
  }
}

Restart Claude Desktop. The application will discover the new Dev.to tools automatically.

Dev.to MCP Server Hero Tools

When Claude connects to the server and issues a tools/list request, Truto dynamically generates the tool definitions from the integration's schemas. Here are the highest-leverage Dev.to operations now available to your model.

list_all_dev_to_me

Retrieves the profile information of the authenticated Dev.to user, including their numeric ID, username, summary, location, and website. This tool is critical for establishing context before the LLM attempts to author content that matches the user's existing brand.

"Fetch my Dev.to profile summary and identify my core content themes based on my bio. I need to write a new article that aligns with this brand."

list_all_dev_to_draft_articles

Fetches only the unpublished (draft) articles associated with the user account. Because Dev.to isolates draft retrieval from published retrieval, this tool guarantees the model is only reading work-in-progress content.

"List all my current draft articles on Dev.to. Give me the titles and numeric IDs so we can decide which one to polish and publish today."

list_all_dev_to_published_articles

Retrieves the user's published Dev.to articles, ordered with the newest first. This is highly useful for auditing past performance, checking existing tags, or generating a portfolio summary without exposing private drafts.

"Pull my 5 most recent published Dev.to articles and extract the primary tags I used for each one. I want to see if I am indexing too heavily on front-end topics."

get_single_dev_to_article_by_id

Retrieves the complete payload of a single published Dev.to article by its numeric ID, including the raw markdown body and frontmatter. Note: Drafts cannot be retrieved via this specific endpoint; they must be accessed via the draft list tools.

"Fetch the published Dev.to article with ID 140928. Analyze the markdown structure and tell me if I included a clear call-to-action at the bottom."

create_a_dev_to_article

Creates a new Dev.to article from raw markdown. The MCP server automatically wraps the parameters under the required article JSON object. You can set published: false to safely save a draft, or published: true to publish immediately to the Forem network. Limit of 4 tags enforced.

"Take the Kubernetes tutorial we just drafted in this chat and create a new Dev.to article. Add the tags 'kubernetes', 'devops', and 'tutorial'. Set published to false so I can review it in the Dev.to UI first."

update_a_dev_to_article_by_id

Updates an existing Dev.to article by its numeric ID. This tool is frequently used to finalize content edits or toggle the state of a draft to live by passing published: true in the payload.

"Update my Dev.to draft article with ID 189201. Replace the markdown body with the revised version we just wrote, and change the published status to true."

To view the complete inventory of available Dev.to endpoints, query parameters, and JSON schemas, visit the Dev.to integration page.

Workflows in Action

Connecting Dev.to to Claude via MCP transforms the model from a passive text generator into an active participant in your Developer Relations pipeline. Here are two concrete workflows showing how an LLM orchestrates these tools in the real world.

Use Case 1: The Draft-to-Publish Review Pipeline

Persona: Developer Relations Manager

A DevRel manager often has dozens of half-finished drafts sitting in Dev.to. They need an agent to review a specific draft, improve the technical accuracy, and push it live.

"Find my Dev.to draft about 'React Server Components'. Read the content, rewrite the conclusion to be punchier, and publish the updated article directly to my profile."

1. Claude calls list_all_dev_to_draft_articles to search the user's unpublished content and locates the article titled "React Server Components" (ID: 94021).
2. Claude extracts the markdown body from the draft response.
3. Claude processes the text internally, rewriting the conclusion to match the prompt's instructions.
4. Claude calls update_a_dev_to_article_by_id, passing ID 94021, the revised markdown body, and setting published: true.

The manager gets back a confirmation that the draft was rewritten, finalized, and pushed live to the Forem network without ever opening a browser.

flowchart TD
    A["Claude receives prompt<br>to publish draft"] --> B["list_all_dev_to_draft_articles"]
    B --> C["Extracts draft ID 94021<br>and markdown body"]
    C --> D["Claude processes text<br>and rewrites conclusion"]
    D --> E["update_a_dev_to_article_by_id<br>(published: true)"]
    E --> F["Dev.to API returns 200 OK<br>Article goes live"]

Use Case 2: Content Audit and Repurposing

Persona: Technical Content Engineer

A technical writer needs to audit their existing published content to find older tutorials that can be repurposed into a new mega-guide.

"Fetch my most recent published Dev.to articles. Find any articles tagged with 'python' or 'django'. Extract their URLs and summaries, and draft a new Dev.to article that combines these concepts into a '2026 Django Masterclass'. Save the new article as a draft."

1. Claude calls list_all_dev_to_published_articles to retrieve the user's live portfolio.
2. Claude filters the returned JSON array, identifying three articles matching the 'python' and 'django' tags.
3. Claude synthesizes the concepts from those summaries and generates a new, comprehensive markdown tutorial.
4. Claude calls create_a_dev_to_article with the new markdown, using tags python, django, tutorial, and setting published: false.

The engineer receives a link to a brand new, highly relevant draft sitting safely in their Dev.to dashboard, ready for a final human review.

Security and Access Control

Giving an LLM direct access to a publishing platform introduces significant operational risk. A hallucination could result in an unfinished draft being blasted to thousands of followers. Truto provides strict, server-side access controls to mitigate this risk.

• Method Filtering (config.methods): You can explicitly restrict an MCP server to specific operations. By passing methods: ["read"] during server creation, Claude will only have access to get and list tools. It becomes physically impossible for the model to invoke the create or update tools.
• Tag Filtering (config.tags): If your Dev.to integration resources are tagged (e.g., ["content", "profile"]), you can restrict the MCP server to only expose tools matching those specific tags.
• Time-to-Live (expires_at): For temporary access (e.g., giving a contractor AI agent access to your Dev.to account for a weekend campaign), you can set an ISO datetime expiration. The server's Cloudflare KV token and background cleanup alarms will automatically revoke access at the specified time.
• Conditional Auth (require_api_token_auth): By default, the cryptographic MCP URL is the only authentication needed. If you require higher security, enabling this flag forces the client to pass a valid Truto API token in the Authorization header, adding a strict second layer of identity verification.

Strategic Wrap-Up

Integrating Dev.to with Claude using a custom MCP server is a slow process of mapping nested payloads, untangling Forem API fragmentation, and dealing with undocumented CDN edge cases.

By leveraging Truto's managed MCP architecture, you bypass the infrastructure overhead entirely. You get dynamically generated, documentation-driven tools that respect Dev.to's strict API schemas. Your agents can read drafts, publish content, and execute complex Developer Relations workflows with zero point-to-point integration code.