Postman MCP Server

The Postman MCP Server provides several core capabilities for managing and executing Postman workflows:

• Collection Running: Execute collections locally or in CI/CD environments. Supports environment integration, folder-specific runs, and multiple iterations.
• Authentication: Uses API key-based authentication with secure key handling and support for CI/CD variables.
• Reporting: Supports multiple reporter formats including CLI, JSON, JUnit, and HTML. Output paths are customizable and content filtering options are available.
• CI/CD Integration: Supports multiple providers with environment variable handling, artifact management, and pipeline configuration.

The Postman API allows you to perform CRUD operations on monitors, which are used for scheduled or manual testing of collections.

Key Capabilities:

• Create/Update/Delete: Manage monitor configurations including names, collections, and environments.
• Scheduling: Configure runs using cron expressions and timezones.
• Execution: Trigger manual runs in either synchronous or asynchronous modes.
• Monitoring: Retrieve run results, statistics, and failure data.

Important Constraints:

• You cannot create monitors for collections that were added via an API definition.
• When running a monitor asynchronously (async=true), the immediate response will not include statistics, executions, or failures. You must use GET /monitors/{monitorId} to retrieve that information later.

When using the Postman MCP Server, be aware of the following constraints:

• Authentication: Interactive authentication flows are not supported. You must provide pre-configured tokens.
• File Handling: Local file references are not supported. All files must be uploaded to Postman to be accessible.
• Real-time Feedback: Feedback is limited to CLI reporter output; the server does not support streaming responses.

The Postman API supports several authentication methods:

• API Key: Use the x-api-key header for standard authentication.
• SCIM API Key: Supported for SCIM-based authentication workflows.
• Collection Access Keys: Specific keys used for accessing individual collections.

You can add comments to various resources like APIs and Collections.

• Structure: Comments are organized into thread-based discussions.
• Limits: Each comment has a maximum length of 10,000 characters.
• Thread Deletion: Deleting the first comment in a thread will delete the entire thread.

When implementing Prompt Handlers in the Postman API MCP server, follow these requirements:

• Naming Convention: Prompt IDs must use snake_case (e.g., create_collection instead of Create Collection).
• Validation: Use TypeScript type guards to perform input validation.
• Schema: Each prompt must have a defined input schema and be capable of generating appropriate messages.

When interacting with workspaces, you must capture and store the createdBy field (the owner ID) from the workspace response. This ID is required to construct valid resource identifiers when accessing other resources related to that specific workspace.

Example workspace response structure:

{
  "id": "5ead536b-e095-403c-89f9-f9f03872537a",
  "name": "My Workspace",
  "type": "personal",
  "visibility": "personal",
  "createdBy": "31912785"
}

Resource Template Handlers manage parameterized URIs, allowing for access to specific entities and their nested sub-resources.

• URI Format: postman://{resource-type}/{id}/[sub-resource]
• Capabilities: Supports nested resources like workspace collections or API versions.
• Validation: Template parameters must be validated before initiating API requests.

postman://workspaces/{id}/collections     # Collections in a workspace
postman://apis/{id}/versions              # Versions of an API
postman://collections/{id}/requests       # Requests in a collection