Como parei de construir coleções do Postman manualmente (Claude + Postman MCP)

Se você testa serviços de backend, você conhece o
ritual. Um novo serviço aparece, você precisa testar seus endpoints, então você abre o Postman e começa a construir uma coleção, requisição por requisição. Método, URL, cabeçalhos, autenticação, corpo da requisição, arrumar a estrutura de pastas, nomear tudo para que o você do futuro possa ler. Em um serviço com algumas dezenas de endpoints, isso leva uma ou duas horas antes de você enviar uma única requisição.

Eu não faço isso há meses.

Agora eu entrego a definição da API para o Claude, e ele constrói toda a coleção através do servidor Postman MCP em poucos segundos - organizado como um manual passo a passo, com os valores já preenchidos. Eu apenas clico em Enviar e leio as respostas. Este post é sobre como eu configurei isso e como eu realmente uso no dia a dia.

A maneira usual, e por que é um desperdício

As informações sobre uma API vivem em lugares diferentes dependendo da equipe. Às vezes é uma página limpa do Swagger / OpenAPI. Às vezes é uma descrição em um ticket do Jira. Às vezes uma página do Confluence, ou apenas uma mensagem do desenvolvedor que escreveu o endpoint. Onde quer que isso viva, o movimento manual é o mesmo: leia, então reescreva cada endpoint no Postman.

Não é um trabalho difícil. É apenas lento, repetitivo e fácil de errar sutilmente - um cabeçalho faltando aqui, um tipo de conteúdo errado ali. E nada disso é realmente teste. É uma configuração que fica entre você e a parte do trabalho que importa.

O que você precisa

Três coisas:

1. Uma conta no Postman e uma chave de API
2. Claude (Claude Code ou o aplicativo desktop) com o servidor Postman MCP conectado
3. A definição da API - de onde quer que ela viva

1. Obtenha sua chave de API do Postman

No Postman: Configurações -> Chaves de API -> Gerar Chave de API. Copie em um lugar seguro - você a passará para o servidor MCP, não a colará em chats.

2. Conecte o servidor Postman MCP ao Claude

MCP (Modelo de Protocolo de Contexto) permite que Claude converse diretamente com o Postman em vez de você copiar e colar de um lado para o outro. Adicione o servidor ao seu .mcp.json (raiz do projeto, ou ~/.claude/mcp.json para global):

{
 "mcpServers": {
 "postman": {
 "command": "npx",
 "args": ["-y", "@postman/postman-mcp-server", "--full"],
 "env": {
 "POSTMAN_API_KEY": "${POSTMAN_API_KEY}"
 }
 }
 }
}

Defina POSTMAN_API_KEY em seu ambiente, reinicie o Claude e execute /mcp para confirmar que está conectado. Agora Claude pode criar e editar coleções em seu espaço de trabalho por conta própria.

3. Aponte para a API

Se você tiver Swagger, ainda melhor - serviços Spring expõem toda a biblioteca de métodos como OpenAPI em /v3/api-docs:

curl -s http://seu-serviço/v3/api-docs -o api.json

Mas a fonte não precisa ser Swagger. Cole o texto do ticket do Jira, a exportação do Confluence, ou a descrição do endpoint diretamente no Claude. Ele extrai os endpoints de qualquer maneira.

Como isso realmente funciona

Aqui está a parte que eu gosto. Eu não recebo apenas um despejo plano de requisições - eu peço ao Claude para construir a coleção como um manual de execução, onde a ordem das requisições é a ordem em que eu executo o teste:

• nomes das requisições são etapas: 1) criar limite, 2) obter por id, 3) atualizar, 4) excluir e verificar
• de cima para baixo é a sequência do teste
• cada valor (host, ids, corpos de requisição) é codificado diretamente na requisição - sem {{variáveis}} para preencher manualmente

Então, o teste fica assim: eu abro a coleção e pressiono Enviar, de cima para baixo. Quando uma requisição cria algo e retorna um novo id, Claude lê isso da resposta e atualiza nas próximas requisições através da API do Postman. Eu continuo pressionando Enviar.

Um exemplo rápido

Diga que eu dou ao Claude uma especificação de endpoint como esta:

POST /api/threshold - criar um limite de detecção para um recurso
GET /api/threshold/{id} - ler de volta
PUT /api/threshold/{id} - atualizar
DELETE /api/threshold/{id}

Eu pergunto: "Construa uma coleção do Postman no meu espaço de trabalho como um manual passo a passo para criar um limite, lê-lo, atualizá-lo e excluí-lo. Codifique os valores, nomeie cada requisição como um passo numerado."

Alguns segundos depois, há uma coleção com quatro requisições ordenadas, corpos preenchidos, autenticação configurada no nível da coleção. Eu as executo em ordem. Depois que o passo 1 retorna o novo id do limite, os passos GET/PUT/DELETE já apontam para ele. Eu leio cada resposta e decido se o serviço se comportou corretamente.

Onde isso ajuda, e onde não ajuda

O trabalho de configuração desaparece na maior parte. O raciocínio não, e esse é o ponto.

A IA é boa em: transformar uma especificação em uma coleção estruturada, nomear e ordenar requisições, preencher boilerplate, atualizar ids entre os passos.

A IA não faz o QA real: decidir quais cenários importam, quais são os casos extremos, se um 201 realmente significa que a lógica de negócios está correta, ler logs para descobrir por que algo falhou. Uma resposta verde não é um teste aprovado - esse julgamento ainda é meu.

Portanto, isso não é "IA testa por mim". É "IA elimina o trabalho repetitivo para que eu passe meu tempo na parte que precisa de um testador".

Conclusão

Se você faz testes de API REST e ainda não tentou Claude + Postman MCP, vale a pena meia hora para configurar. A primeira vez que uma coleção que você teria levado uma hora para construir aparece pronta em segundos, faz sentido.

Eu escrevi minha configuração completa, modelos de prompt e notas honestas sobre onde a IA falha aqui: github.com/anton-kirilchuk/ai-assisted-qa-mcp

Eu posto mais sobre QA de backend e testes aumentados por IA no LinkedIn - feliz em comparar notas.

Quanto do seu tempo de teste ainda vai para a configuração antes que os testes reais comecem?