Postman: use the local MCP server so runCollection is available

[christosgkoros]

Summary

The Postman power's core workflow is running a collection and reporting test results. The onboarding hook says so explicitly:

"…get the collection ID and run the collection, showing me the results and propose fixes for any errors found."

That isn't possible with the current configuration. runCollection is only exposed by the local (stdio) Postman MCP server — Postman's hosted remote endpoints don't include it, and the power currently points at https://mcp.postman.com/minimal. So the tool the hook depends on isn't there.

This PR switches the power to the local server.

Verification

Live tools/list against each server (protocol 2025-06-18, authenticated):

Server	Tools	runCollection
Remote https://mcp.postman.com/minimal	41	❌
Remote https://mcp.postman.com/mcp (full)	124	❌
Local npx @postman/postman-mcp-server@latest (minimal, default)	42	✅
Local npx … --full	125	✅

The local minimal toolset is exactly the remote minimal toolset plus runCollection — a set difference of one tool, in our favour. Nothing is lost by switching.

I also launched the server using the exact command/args from the new mcp.json and confirmed it completes the MCP handshake and advertises all 42 tools.

Why local, beyond tool availability

runCollection runs Newman in-process, so requests originate from wherever the MCP server runs. On the local server that's the developer's machine, which means collections targeting http://localhost:3000 — the exact case in this power's own createEnvironment example — actually work. The remote server has no network route to a user's workstation. This matches the guidance in the server README:

Use the local server to test local APIs, as the remote server won't have network access to your workstation.

Changes

postman/mcp.json — local stdio server, API key forwarded with Kiro's ${VAR} substitution (same idiom as the localstack power):

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

postman/POWER.md

• Auth is now a Postman API key. The local server doesn't support OAuth, so the previous "OAuth — no API key required" text no longer applies.
• New onboarding Step 1 for obtaining and exporting the key (existing hook step becomes Step 2). Following the localstack power's convention, it tells the agent to confirm with the user in chat rather than probing the secret from the shell, and to use a getAuthenticatedUser call as the real connectivity check.
• Added a "Why the local server" note so this doesn't get reverted to the remote URL later.
• Updated Configuration and Troubleshooting; documented --full and --region eu.
• Corrected the tool list to match the server. It was inaccurate independently of this change: it listed getStatusOfAnAsyncApiTask, which the server doesn't expose, and omitted updateCollectionRequest and searchPostmanElements. Now 42/42, cross-checked programmatically against tools/list.

postman/steering/steering.md — one line under "Verify API availability" noting runs execute locally, so private hosts are reachable.

Trade-off worth flagging

This does trade browser-based OAuth for a manually exported API key, which is a small step backwards on first-run friction. It's unavoidable if the power is to run collections at all: the local server only supports API key auth. Happy to adjust the onboarding wording if you'd prefer it framed differently.

🤖 Generated with Claude Code