The full loop, start to finish, using the official Postman Claude Code plugin. Twenty minutes gets you a dozen badges and a working API.
New to learnmcp? Install it first — see the README.
claude plugin install postman@claude-plugins-officialRestart Claude Code, then authenticate:
/postman:setup
Start a session in the project you're working on. Before you do anything Postman-related:
learnmcp is tracking this project. Rank Initiate · 10 pts · 1 badges. Active learning tracks: postman (0/13). Suggested next: Send a request against your API — Seeing a real response is the fastest way to find out your API doesn't behave the way the spec claims.
It read your installed plugins, saw Postman's MCP server, and loaded the matching cartridge. Nothing in your repo mentions Postman and you configured nothing.
You also just earned Plugged In 🥉 from the always-on general cartridge, for adding
your first MCP server.
You don't run commands — you just ask for what you want, the way you'd ask a colleague.
Claude decides whether that means running a /postman:… command or calling an MCP tool
directly; learnmcp catches it either way, so the badge fires regardless of which one it
picked. Roughly first-run to advanced:
learnmcp — 🏅 Spec Author (+10) · ✅ Generate an OpenAPI spec from your codebase · Initiate · 20 pts (80 to Apprentice) · Next: Search for an existing API before building your own
The integration you're about to hand-roll may already exist as a maintained collection.
Keeps the spec and your requests from drifting apart.
There's no /postman: command for this one — Claude just calls the createCollectionResponse
tool directly. Examples are what your mock server returns and what your published docs
show, so without them both are empty shells.
Also MCP-only, no slash command behind it. Hardcoded hosts and tokens in requests leak into git and make the same collection unusable against staging.
Do this ten times over the life of the project and it upgrades to Marathoner 🥇.
Chaining calls in a Flow beats a scratch script nobody else can run or debug.
This one you can't earn by running a command. It asks a question no regex can answer:
"Do the operations have clear summaries/descriptions and named, described parameters suitable for an AI agent to call?"
learnmcp reads your openapi.yaml and has an LLM score it against that rubric, gated at
0.8 confidence. A thin spec sits pending indefinitely — no partial credit. Flesh out
your summaries and parameter descriptions and it clears.
Postman's own /postman:agent-ready-apis skill targets the same bar, so run that first.
POSTMAN_API_KEY staying out of git is tracked as a best practice. No badge — just a nudge
if it ever shows up in a committed file.
/badges # everything earned, by tier
/progress # rank, points, how far to the next one
/learn # just tell me the next thing
Worth understanding if you're writing your own cartridge, because Postman is a good example of a tool that can't be tracked one single way — and it's why asking naturally in §2 above works at all rather than requiring you to memorize command names.
A plugin's commands and its MCP tools are different names for the same action.
/postman:mock is a slash command; underneath it calls the MCP tool createMock. Match
only one and you miss half the ways a user gets there. So the cartridge accepts either:
Some actions never touch an MCP tool at all. /postman:run-collection shells out to
the Postman CLI, so a bash matcher is the only thing that sees it:
{ "type": "bash", "matches": "postman\\s+collection\\s+run" }And some have no tool of their own. /postman:security is composed from generic reads
(getWorkspaces, getAllSpecs, getSpecDefinition) that any other command might also
call — matching those would hand out the badge for unrelated work. The command invocation
itself is the only trustworthy signal.
The full cartridge is cartridges/postman/postman.json,
and the walkthrough above is executed as tests in
packages/server/test/detection.test.ts —
including a guard that every tool name it references is one the Postman MCP really exposes.
The installed plugin's hook is a plain script — you can drive it directly to see detection work, against your real hosted progress:
cd ~/.claude/plugins/cache/quintonwall/learnmcp/*/
# a slash command
echo '{"hook_event_name":"UserPromptSubmit","prompt":"/postman:mock"}' \
| node hooks/learnmcp-hook.mjs post-tool-use
# the MCP tool underneath it
echo '{"tool_name":"mcp__postman__createMock","tool_input":{}}' \
| node hooks/learnmcp-hook.mjs post-tool-use
# the CLI path
echo '{"tool_name":"Bash","tool_input":{"command":"postman collection run abc"}}' \
| node hooks/learnmcp-hook.mjs post-tool-useEach prints the JSON the hook feeds back to Claude Code — a systemMessage when
something is newly earned, nothing when it's already been credited. Since this talks to
your real hosted learner, use a throwaway HOME to try things without touching your
actual progress: prefix any of the above with HOME=$(mktemp -d).