runCollection often times out, and there's no tool to execute a single request – making fully automated API testing unreliable

[2457205703]

Description

Problem Summary

I'm using the official Postman MCP server (@postman/postman-mcp-server with --full mode) in Claude Code, trying to achieve fully automated API testing without manually clicking "Send" in Postman UI.

However, I encountered two major limitations that prevent reliable automation:

1. runCollection frequently times out – even for moderate-sized collections, the MCP tool often exceeds the client's timeout limit (e.g., 60s). Newman execution inside may take longer, but the MCP wrapper doesn’t handle long-running tasks gracefully.
2. No tool to execute a single request – there is no runRequest or similar tool. This forces me to run an entire collection even when I only need to test one endpoint, which is inefficient and more prone to timeout.

Expected Behavior

As a user who wants to manage collections across machines (official MCP is great for sync/CRUD), I also need reliable execution of API tests – either full collections or individual requests – directly from Claude, without leaving the terminal.

Specifically, I'd expect:

• A stable runCollection that either:
  • Supports a configurable timeout (passed from the client), or
  • Runs asynchronously with a job ID and allows polling for results.
• A runRequest tool that can execute a single request (by its UID or path within a collection) and return the response + test results.

Steps to Reproduce

1. Configure official Postman MCP server with --full mode in Claude Code:

   claude mcp add postman --env POSTMAN_API_KEY=xxx -- npx @postman/postman-mcp-server@latest --full

2. In Claude, ask: "Run my collection 'API Tests' and show me the results."
3. The runCollection tool is called, but after ~60 seconds Claude reports a timeout / the MCP call is interrupted.
4. No response is returned, and the automation fails.

(Note: The same collection runs fine via newman CLI in <10 seconds.)

Environment

• @postman/postman-mcp-server version: latest (as of June 2026)
• MCP client: Claude Code (also reproducible with Claude Desktop)
• OS: macOS / Linux (happens on both)
• Collection size: ~20 requests, each with simple assertions

Proposed Solutions (Ideas)

1. Add a --execution-timeout parameter to runCollection so the MCP server can wait longer before failing.
2. Introduce a new runRequest tool that accepts a request UID and optionally environment variables.
3. Provide an asynchronous execution model – return a task ID immediately, then a getTaskResult tool to fetch the output later. This would solve timeout issues entirely.
4. Under the hood, consider delegating to Newman (like community MCPs do) – it's stable, fast, and supports streaming output.

Why This Matters

The official MCP is excellent for managing collections, folders, requests, and environments across machines. But for executing tests (especially in CI-like or fully automated agent workflows), the current runCollection is unreliable. Many users (including me) are forced to switch to community MCPs just for execution, while still using the official MCP for management. It would be great if the official server could cover both use cases seamlessly.

Additional Context

I've also explored community alternatives:

• @iflow-mcp/mcp-postman (Newman-based) – stable execution, but lacks cloud management.
• swag-mcp – more flexible but doesn't run collections in one shot.

Ideal world: Keep the official MCP as the single source of truth – manage and execute – with reliable primitives.

Thanks for considering!

[Naveen-Boddepalli]

Hi @2457205703 — I ran into the same root cause and did some digging into src/tools/runner/index.ts
and src/index.ts to pin down exactly why this happens. Since this report bundles two separate
problems, I split it into two focused issues per the contributing guide's "one focused change"
guidance, with the specific code path each issue traces through:

• fix: runCollection blocks on the full Newman run, causing MCP client timeouts #169 — the runCollection timeout itself (root cause: synchronous await with no progress
  streaming, plus why requestTimeout/scriptTimeout don't actually fix it)
• Request: add a runRequest tool for executing a single request #170 — the missing runRequest tool

Linking here so they don't get duplicated/lost. Happy to consolidate into this issue instead if a
maintainer prefers keeping one thread — just let me know.