If you test backend services, you know the
ritual. A new service shows up, you need to poke its endpoints, so you open Postman and start building a collection request by request. Method, URL, headers, auth, request body, fix the folder structure, name everything so future-you can read it. On a service with a few dozen endpoints, that's an hour or two gone before you send a single request.

I haven't done that in months.

Now I hand the API definition to Claude, and it builds the whole collection through the Postman MCP server in a few seconds - laid out as a step-by-step runbook, with values already filled in. I just hit Send and read the responses. This post is how I set it up and how I actually use it day to day.

The usual way, and why it's a waste

The information about an API lives in different places depending on the team. Sometimes it's a clean Swagger / OpenAPI page. Sometimes it's a description in a Jira ticket. Sometimes a Confluence page, or just a message from the developer who wrote the endpoint. Wherever it lives, the manual move is the same: read it, then re-type each endpoint into Postman.

It's not hard work. It's just slow, repetitive, and easy to get subtly wrong - a missing header here, a wrong content type there. And none of it is actually testing. It's setup that stands between you and the part of the job that matters.

What you need

Three things:

1. A Postman account and an API key
2. Claude (Claude Code or the desktop app) with the Postman MCP server connected
3. The API definition - from wherever it lives

1. Get your Postman API key

In Postman: Settings -> API keys -> Generate API Key. Copy it somewhere safe - you'll pass it to the MCP server, not paste it into chats.

2. Connect the Postman MCP server to Claude

MCP (Model Context Protocol) lets Claude talk directly to Postman instead of you copy-pasting back and forth. Add the server to your .mcp.json (project root, or ~/.claude/mcp.json for global):

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

Set POSTMAN_API_KEY in your environment, restart Claude, and run /mcp to confirm it connected. Now Claude can create and edit collections in your workspace on its own.

3. Point it at the API

If you have Swagger, even better - Spring services expose the full method library as OpenAPI at /v3/api-docs:

curl -s http://your-service/v3/api-docs -o api.json

But the source doesn't have to be Swagger. Paste the Jira ticket text, the Confluence export, or the endpoint description straight into Claude. It pulls the endpoints out either way.

How it actually works

Here's the part I like. I don't just get a flat dump of requests - I ask Claude to build the collection as a runbook, where the order of the requests is the order I run the test:

• request names are steps: 1) create threshold, 2) get by id, 3) update, 4) delete and verify
• top to bottom is the test sequence
• every value (host, ids, request bodies) is hardcoded right into the request - no {{variables}} to fill in by hand

Then testing looks like this: I open the collection and press Send, top to bottom. When a request creates something and returns a new id, Claude reads it from the response and patches it into the next requests through the Postman API. I keep pressing Send.

A quick example

Say I give Claude an endpoint spec like this:

POST /api/threshold - create a detection threshold for a resource
GET /api/threshold/{id} - read it back
PUT /api/threshold/{id} - update it
DELETE /api/threshold/{id}

I ask: "Build a Postman collection in my workspace as a step-by-step runbook to create a threshold, read it, update it, and delete it. Hardcode the values, name each request as a numbered step."

A few seconds later there's a collection with four ordered requests, bodies filled in, auth set at the collection level. I run them in order. After step 1 returns the new threshold id, the GET/PUT/DELETE steps already point at it. I read each response and decide whether the service behaved correctly.

Where this helps, and where it doesn't

The setup work mostly disappears. The thinking doesn't, and that's the point.

AI is good at: turning a spec into a structured collection, naming and ordering requests, filling in boilerplate, patching ids between steps.

AI does not do the actual QA: deciding which scenarios matter, what the edge cases are, whether a 201 actually means the business logic is correct, reading logs to find why something failed. A green response is not a passing test - that judgment is still mine.

So this isn't "AI tests for me". It's "AI clears the busywork so I spend my time on the part that needs a tester".

Wrapping up

If you do REST API testing and haven't tried Claude + Postman MCP yet, it's worth half an hour to set up. The first time a collection you'd have spent an hour building shows up ready in seconds, it clicks.

I wrote up my full setup, prompt templates, and honest notes on where AI breaks down here: github.com/anton-kirilchuk/ai-assisted-qa-mcp

I post more about backend QA and AI-augmented testing on LinkedIn - happy to compare notes.

How much of your testing time still goes to setup before the real testing starts?