Connect Dev.to to ChatGPT: Manage Content Lifecycles and Profiles

If you need to connect Dev.to to ChatGPT to automate your technical content pipeline, draft markdown posts, or orchestrate your publisher profile, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's function calls and Dev.to's REST API. You can either spend weeks building, hosting, and maintaining a custom MCP server, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL in seconds.

If your team uses Claude, check out our guide on connecting Dev.to to Claude 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 community platform like Dev.to is an engineering challenge. You have to handle nested payload structures, enforce strict tagging limits, and manage the dual-state logic of drafts versus published posts. Every time you want to expose a new endpoint to the LLM, you have to write more JSON-RPC boilerplate.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Dev.to, connect it natively to ChatGPT, and execute complex content 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, implementing it against Dev.to's specific API design requires careful engineering.

If you decide to build a custom MCP server for Dev.to, you own the entire API lifecycle. Here are the specific integration challenges you must solve to prevent LLM hallucinations and API errors:

Nested Markdown Payloads

Dev.to expects content submissions to be formatted as Markdown. However, the API requires this data to be nested inside an article wrapper object in the JSON body. If your MCP tool schema just asks the LLM for body_markdown, the Dev.to API will reject it with a 422 Unprocessable Entity. Your tool definition must explicitly instruct the LLM to construct a payload like {"article": {"body_markdown": "...", "title": "..."}}. Truto handles this automatically by generating tools directly from the API's body schemas.

Dual-State Publishing Logic

There is no dedicated /publish endpoint in the Dev.to API. Moving an article from a draft to a live state requires an update operation (PUT /api/articles/{id}) passing the boolean flag published: true. Conversely, setting it to false unpublishes it. If you do not provide the LLM with explicit context on how this state machine operates, it will hallucinate calls to non-existent publishing endpoints.

Tagging Constraints

Dev.to strictly limits articles to a maximum of 4 tags. LLMs are notoriously overzealous with categorization and will routinely attempt to pass arrays of 10+ tags if left unchecked. Your custom MCP server must either silently truncate this array (which leads to unpredictable categorization) or enforce the schema limit so the LLM knows to compress its concepts down to the 4 most relevant tags.

Rate Limits and Headers

When connecting AI agents that can rapidly execute multiple tool calls in a loop, you will hit rate limits. Factual note: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Dev.to API returns an HTTP 429, Truto passes that error directly back to the caller (your LLM client). Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller - whether that is ChatGPT or a custom LangChain agent - is entirely responsible for reading these headers and executing its own retry and backoff logic.

Step 1: Generating the Dev.to MCP Server

To connect ChatGPT to Dev.to, we first need to generate the MCP server URL. Truto dynamically generates these tools from the integration's documentation records - meaning only well-documented, curated endpoints are exposed to the AI.

You can generate the server using either the Truto dashboard or the API.

Method A: Via the Truto UI

1. Log into your Truto account and navigate to Integrated Accounts.
2. Connect a Dev.to account (providing the necessary API key).
3. Open the integrated account page and click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., allow read and write methods).
6. Copy the generated MCP server URL (it will look like https://api.truto.one/mcp/<token>). Treat this URL as a secret, as it contains the authentication hash.

Method B: Via the API

For teams building automated agent provisioning, you can generate the MCP server programmatically. Make a POST request to /integrated-account/:id/mcp.

curl -X POST https://api.truto.one/integrated-account/<INTEGRATED_ACCOUNT_ID>/mcp \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Dev.to Content Engine for ChatGPT",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The API responds with the tokenized endpoint:

{
  "id": "mcp-12345",
  "name": "Dev.to Content Engine for ChatGPT",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Step 2: Connecting the MCP Server to ChatGPT

Now that you have your secure MCP URL, you need to register it with your ChatGPT environment. You can do this directly through the desktop UI or via a manual configuration file for automated deployments.

Method A: Via the ChatGPT UI

1. Open the ChatGPT Desktop app.
2. Navigate to Settings -> Apps -> Advanced settings.
3. Ensure Developer mode is enabled (MCP support is currently behind this flag and requires a Plus, Pro, Team, or Enterprise plan).
4. Under MCP servers / Custom connectors, click Add new server.
5. Name the connector (e.g., "Dev.to (Truto)").
6. Paste your Truto MCP URL into the Server URL field and save.

ChatGPT will immediately ping the endpoint, execute the MCP handshake, and ingest the tool capabilities.

Method B: Via Manual Config File

If you are running a custom ChatGPT-compatible interface or a local testing environment, you can define the server via an mcp.json configuration file using the standard Server-Sent Events (SSE) transport.

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

This instructs the MCP client to route traffic through an SSE bridge directly to the Truto endpoint.

Security and Access Control

Giving an LLM direct access to your developer platform account carries risk. Truto provides several layers of access control directly on the MCP token to constrain what the AI can do:

• Method Filtering: By defining config.methods: ["read"], the MCP server will only expose GET and LIST tools. The LLM physically cannot execute a CREATE or UPDATE, eliminating the risk of accidental rogue publishing.
• Tag Filtering: Integrations group resources by tags. You can set config.tags: ["articles"] to only expose article-related tools, preventing the LLM from touching account settings or follower lists.
• Token Expiration: Pass an expires_at ISO datetime when generating the server. Once the time is reached, the token is automatically wiped from the KV store and database via a scheduled alarm, immediately severing the LLM's access.
• Extra Authentication: By setting require_api_token_auth: true, possession of the URL is no longer enough. The client must also pass a valid Truto API token in the Authorization header, enforcing a dual-layer security model for zero-trust environments.

Dev.to Hero Tools for ChatGPT

Once connected, Truto dynamically maps the Dev.to REST API into JSON-RPC tools. Here are the highest-leverage tools available to your ChatGPT agent.

1. list_all_dev_to_me

Fetches the Dev.to profile details of the authenticated user. This includes the internal ID, username, name, summary, and location. This is critical for context-gathering, allowing the LLM to understand who is authoring the posts and referencing their profile in content.

"Who am I currently authenticated as on Dev.to, and what does my profile summary say? Do I need to update my bio to mention my latest open-source project?"

2. create_a_dev_to_article

Drafts or publishes a new article. The payload must wrap fields inside an article object. Crucially, the LLM must set published: false to create a draft. It accepts standard Markdown in the body_markdown field and a maximum of 4 tags.

"Draft a new Dev.to article titled 'Understanding MCP Servers'. Use the markdown file in my current context. Add the tags 'api', 'architecture', and 'ai'. Make sure it is saved as a draft and NOT published immediately."

3. update_a_dev_to_article_by_id

Modifies an existing article. This is the tool used for the publishing lifecycle. To publish a draft, the agent calls this tool with the target article ID and sets published: true. To unpublish a live post, it sets published: false.

"Take article ID 123456, which is currently a draft, fix the typo in the second paragraph, and change its status to published."

4. list_all_dev_to_draft_articles

Retrieves a strictly filtered list of the user's unpublished articles. This bypasses the need for the LLM to fetch all articles and filter them in-memory, saving massive amounts of context window space.

"List all of my current draft articles on Dev.to. Are there any drafts from 2023 that I should review and finally publish?"

5. list_all_dev_to_published_articles

Retrieves the user's live articles, ordered by newest first. Useful for auditing content, checking engagement stats (if included in the response payload), or retrieving links to share on other platforms.

"Get my 5 most recent published Dev.to articles and generate a short Twitter thread summarizing them."

To view the complete schema definitions and the full list of available tools, visit the Dev.to integration page.

Workflows in Action

Here is how an AI agent orchestrates these tools in the real world to automate content engineering tasks.

Scenario 1: The Developer Advocate Drafting & Review Flow

Developer advocates often write content locally and need to push drafts into the CMS for formatting checks before going live.

"I have a new tutorial on Rust macros. Create a new draft article on Dev.to with this content. Once it's created, list my drafts to confirm it's there, and return the preview URL."

Step-by-step execution:

1. create_a_dev_to_article: ChatGPT formats the markdown, places it inside the article wrapper, and sets published: false. It attaches the tags "rust" and "tutorial".
2. list_all_dev_to_draft_articles: The agent fetches the drafts to verify the ID and status of the newly created post.

Result: The user gets a confirmation that the draft is safely stored on Dev.to, completely bypassing the manual copy-paste process from their local IDE to the Dev.to web editor.

Scenario 2: Content Manager Audit & Publishing

A content manager needs to clean up old drafts and push approved content live.

"Review my Dev.to drafts. Find the article titled 'Migrating from REST to GraphQL'. If the markdown body looks complete, update the tags to include 'graphql' and 'api', and publish it."

Step-by-step execution:

1. list_all_dev_to_draft_articles: ChatGPT retrieves the list of drafts and identifies the ID of the target article.
2. update_a_dev_to_article_by_id: The agent constructs an update payload for that specific ID, appending the requested tags (ensuring it stays under the 4-tag limit), and changes the state to published: true.

Result: The agent successfully locates the draft, verifies the content, updates the metadata, and pushes it live to the Dev.to community in a single conversational turn.

sequenceDiagram
    participant User as User
    participant ChatGPT as ChatGPT
    participant MCP as Truto MCP Server
    participant DevTo as Dev.to API
    
    User->>ChatGPT: "Publish my GraphQL draft"
    ChatGPT->>MCP: Call list_all_dev_to_draft_articles
    MCP->>DevTo: GET /api/articles/me/unpublished
    DevTo-->>MCP: [ { id: 8901, title: "..." } ]
    MCP-->>ChatGPT: Result (Draft List)
    
    ChatGPT->>MCP: Call update_a_dev_to_article_by_id (id: 8901, published: true)
    MCP->>DevTo: PUT /api/articles/8901
    DevTo-->>MCP: 200 OK (Article Published)
    MCP-->>ChatGPT: Result (Success)
    ChatGPT-->>User: "Your article is now live."

The Strategic Advantage of Managed MCP Infrastructure

Building an AI agent that can generate technical content is impressive, but if it cannot securely write that content back to the system of record, it remains a toy.

Connecting ChatGPT to Dev.to requires more than just knowing the API endpoints. You have to translate LLM intent into specific, nested JSON structures, handle pagination schemas, and manage state transitions. By using Truto to generate your MCP server, you offload the entire infrastructure burden.

You get dynamic, documentation-driven tools, secure token lifecycle management, and built-in access controls without writing a single line of integration code. Your engineering team can focus on refining the AI's core capabilities, while the MCP server handles the dirty work of API execution.