How to Connect Claude to the dev.to API and Build a Reusable Skill

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 . 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:

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.