MCP (Model Context Protocol) connectors extend Claude's reach into external services, but connector coverage is uneven across platforms. dev.to is one such gap: no MCP connector currently supports writing to it. This post documents the workaround — calling dev.to's REST API directly, converting that workflow into a reusable Claude skill, and the reasoning behind keeping the API key out of that skill entirely.
Claude connects to external services through MCP (Model Context Protocol) connectors — Gmail, Google Drive, Shopify, and so on. A community-built dev-to-mcp server exists, but it only wraps dev.to's public API: get_articles
, get_article
, get_user
, get_tags
, get_comments
, search_articles
. Read-only, by design — the author explicitly left out the authenticated write endpoints to keep the initial release simple.
The existence of an MCP server for a service doesn't mean everything that service's API can do is exposed through it. That distinction matters when planning any AI-agent integration against a third-party platform.
dev.to has had a full authenticated REST API for years — create, read, update, delete articles, plus follower and notification endpoints. It's a plain API, not an MCP tool, which means using it requires a general-purpose way to make HTTP calls: a sandboxed environment with network access and a shell. The complete reference — every endpoint, required headers, and response schema — is published at developers.forem.com/api/v1. This is the page an AI agent (or a person) should read directly before writing any integration code against it, rather than relying on prior training knowledge of the API shape.
The workflow reduces to three plain HTTP calls:
1. GET /api/articles/:username/:slug → find the numeric article ID
2. GET /api/articles/:username/:slug → pull body_markdown to edit locally
3. PUT /api/articles/:id (with api-key header) → push the new title, tags, body
The raw markdown is fetched, edited with standard text-replacement, and pushed back with a signed request. The published URL and slug remain unchanged after a title edit, so existing links continue to resolve correctly.
Claude supports "skills" — markdown files that document a workflow so it doesn't need to rediscover the same steps in a future session. The dev.to workflow above was written up as a SKILL.md
covering the exact curl patterns, a link to the official API reference, the tag-format constraints (max four tags, alphanumeric only), and the note that a PUT only changes the fields explicitly sent.
That file sits alongside similar skills built for a Shopify cross-listing workflow and a WordPress publishing workflow — each one converting a one-off problem-solving session into something reusable, rather than re-explaining the same constraints each time.
🔐
The rule that mattered more than any of the code: the API key never went into the skill file.Skill files persist. They are read back into context automatically in every future conversation, on any device, indefinitely. A live credential sitting in one is a standing liability — no expiry, no encryption, no audit trail, and no way to verify later who or what might have accessed it. The skill therefore documents where to obtain the key and includes a reminder to request it fresh each session, but the value itself is never written down. It is used for the curl calls in a single conversation, then discarded.
The key is generated at
[dev.to → Settings → Extensions], under the "DEV API Keys" section near the bottom of that page.
This pattern is not dev.to-specific. It applies to any service where an MCP connector doesn't yet exist, or only covers part of the API:
The steps above map directly onto plain-language requests. These are the actual prompts that drive each stage of the workflow:
| Step | Example Prompt |
|---|---|
| Check what's possible | "Check your connectors and skills — can you update a post on dev.to?" |
| Set up (first time) | "Look up the API docs at developers.forem.com/api/v1, figure out how to update a dev.to article, then store what you learn into a skill — don't save the API key in it." |
| Connect (each session) | "Use the dev.to skill to update this post: [url]" — Claude should then ask for the API key and remind you it's generated at dev.to → Settings → Extensions. |
| Look up an article | "Look up this dev.to article and tell me its current title, tags, and ID: [url]" |
| Create a new post | "Publish a new dev.to post titled '[title]' with this content: [markdown], tagged [tag1, tag2, tag3]." |
| Update an existing post | "Update my dev.to post at [url] — change the title to '[new title]' and add the tag [tag]." |
| Sync with a source article | "This dev.to post is a cross-post of [source URL]. Update it to match the current version." |
Each prompt is a plain description of the desired outcome, not a set of technical instructions — the skill file supplies the mechanics (endpoints, headers, field constraints) so the request itself can stay short.