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.
1. The Gap: No MCP Connector for dev.to Writes
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.
2. The Workaround: dev.to's Real REST API
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.
3. Turning It Into a Reusable Skill
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.
4. Applying This Pattern Elsewhere
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:
- Check whether the service has a plain REST API, even without an MCP wrapper — most established platforms do.
- Have Claude write the skill file after the problem has been solved once, so it captures the real constraints (rate limits, required headers, field-naming quirks) rather than a guess.
- Keep secrets out of anything durable. If a workflow needs a credential, the skill should describe how to obtain one and where to provide it — never store the value itself.
- State the no-storage requirement explicitly when asking for a skill to be created, since the entire purpose of a skill is to outlive the conversation.
5. Example Prompts for Each Step
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.
Top comments (1)
If the have an OpenAPI specification, you could significantly simplify there process ==> hyperlambda.dev/blog/connect-your-...