Como Conectar Claude à API do dev.to e Construir uma Habilidade Reutilizável

Conectores MCP (Modelo de Protocolo de Contexto) estendem o alcance do Claude para serviços externos, mas a cobertura dos conectores é desigual entre as plataformas. dev.to é uma dessas lacunas: atualmente, nenhum conector MCP suporta a escrita nele. Este post documenta a solução alternativa — chamando diretamente a API REST do dev.to, convertendo esse fluxo de trabalho em uma habilidade reutilizável do Claude, e a razão por trás de manter a chave da API fora dessa habilidade completamente.

1. A Lacuna: Nenhum Conector MCP para Escritas no dev.to

Claude se conecta a serviços externos através de conectores MCP (Modelo de Protocolo de Contexto) — Gmail, Google Drive, Shopify, e assim por diante. Um servidor dev-to-mcp construído pela comunidade existe, mas ele apenas envolve a API pública do dev.to: get_articles, get_article, get_user, get_tags, get_comments, search_articles. Somente leitura, por design — o autor explicitamente deixou de fora os endpoints de escrita autenticada para manter o lançamento inicial simples.

A existência de um servidor MCP para um serviço não significa que tudo o que a API desse serviço pode fazer está exposto através dele. Essa distinção é importante ao planejar qualquer integração de agente de IA contra uma plataforma de terceiros.

2. A Solução Alternativa: A Verdadeira API REST do dev.to

O dev.to possui uma API REST autenticada completa há anos — criar, ler, atualizar, excluir artigos, além de endpoints de seguidores e notificações. É uma API simples, não uma ferramenta MCP, o que significa que usá-la requer uma maneira geral de fazer chamadas HTTP: um ambiente isolado com acesso à rede e um shell. A referência completa — cada endpoint, cabeçalhos necessários e esquema de resposta — está publicada em developers.forem.com/api/v1. Esta é a página que um agente de IA (ou uma pessoa) deve ler diretamente antes de escrever qualquer código de integração contra ela, em vez de confiar no conhecimento prévio sobre a forma da API.

O fluxo de trabalho se reduz a três chamadas HTTP simples:

1. GET  /api/articles/:username/:slug   → encontrar o ID numérico do artigo
2. GET  /api/articles/:username/:slug   → puxar body_markdown para editar localmente
3. PUT  /api/articles/:id  (com cabeçalho de api-key)  → enviar o novo título, tags, corpo

O markdown bruto é buscado, editado com substituição de texto padrão, e enviado de volta com uma solicitação assinada. A URL publicada e o slug permanecem inalterados após uma edição de título, de modo que os links existentes continuam a resolver corretamente.

3. Transformando Isso em uma Habilidade Reutilizável

Claude suporta "habilidades" — arquivos markdown que documentam um fluxo de trabalho para que não precise redescobrir os mesmos passos em uma sessão futura. O fluxo de trabalho do dev.to acima foi escrito como um SKILL.md cobrindo os padrões exatos de curl, um link para a referência oficial da API, as restrições de formato de tag (máximo de quatro tags, apenas alfanuméricas), e a nota de que um PUT apenas altera os campos explicitamente enviados.

Esse arquivo está ao lado de habilidades semelhantes construídas para um fluxo de trabalho de listagem cruzada do Shopify e um fluxo de trabalho de publicação do WordPress — cada uma convertendo uma sessão de resolução de problemas única em algo reutilizável, em vez de reexplicar as mesmas restrições a cada vez.

🔐 A regra que importava mais do que qualquer um dos códigos: a chave da API nunca foi para o arquivo de habilidade.

Os arquivos de habilidade persistem. Eles são lidos de volta ao contexto automaticamente em cada conversa futura, em qualquer dispositivo, indefinidamente. Uma credencial ativa em um é uma responsabilidade permanente — sem expiração, sem criptografia, sem trilha de auditoria, e sem maneira de verificar depois quem ou o que pode ter acessado. A habilidade, portanto, documenta onde obter a chave e inclui um lembrete para solicitá-la nova a cada sessão, mas o valor em si nunca é escrito. Ele é usado para as chamadas curl em uma única conversa, depois descartado.

A chave é gerada em dev.to → Configurações → Extensões, na seção "Chaves da API DEV" perto do final daquela página.

4. Aplicando Este Padrão em Outros Lugares

Este padrão não é específico do dev.to. Ele se aplica a qualquer serviço onde um conector MCP ainda não exista, ou cobre apenas parte da API:

• Verifique se o serviço possui uma API REST simples, mesmo sem um wrapper MCP — a maioria das plataformas estabelecidas possui.
• Faça o Claude escrever o arquivo de habilidade após o problema ter sido resolvido uma vez, para que capture as verdadeiras restrições (limites de taxa, cabeçalhos necessários, peculiaridades de nomenclatura de campos) em vez de um palpite.
• Mantenha segredos fora de qualquer coisa durável. Se um fluxo de trabalho precisar de uma credencial, a habilidade deve descrever como obter uma e onde fornecê-la — nunca armazene o valor em si.
• Declare explicitamente a exigência de não armazenamento ao solicitar a criação de uma habilidade, uma vez que o propósito de uma habilidade é sobreviver à conversa.

5. Exemplos de Prompts para Cada Etapa

As etapas acima se mapeiam diretamente em solicitações em linguagem simples. Estes são os prompts reais que impulsionam cada estágio do fluxo de trabalho:

Cada prompt é uma descrição simples do resultado desejado, não um conjunto de instruções técnicas — o arquivo de habilidade fornece a mecânica (endpoints, cabeçalhos, restrições de campo) para que a solicitação em si possa permanecer curta.