Which integrations are available for this server?

Supports containerized deployment of the MCP server for production environments. Enables configuration of API keys and other environment variables needed for the tools to authenticate with various APIs. Provides a runtime environment for the MCP server, with specific support for Node.js v18+ required for the server's functionality. Used for package management of the MCP server's dependencies. Integrates with Postman's API ecosystem, allowing conversion of Postman API requests into MCP-compatible tools that can be accessed by AI agents.

How do I use Postman MCP Generator?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Postman MCP Generator fetch the latest user data from our CRM API" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Postman MCP Generator

by Amit-Lakhani

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Postman MCP Generator

Welcome to your generated MCP server! 🚀 This project was created with the Postman MCP Generator, configured to Model Context Provider (MCP) Server output mode. It provides you with:

✅ An MCP-compatible server (mcpServer.js)
✅ Automatically generated JavaScript tools for each selected Postman API request

Let's set things up!

🚦 Getting Started

⚙️ Prerequisites

Before starting, please ensure you have:

Node.js (v18+ required, v20+ recommended)
npm (included with Node)

Warning: if you run with a lower version of Node, fetch won't be present. Tools use fetch to make HTTP calls. To work around this, you can modify the tools to use node-fetch instead. Make sure that node-fetch is installed as a dependency and then import it as fetch into each tool file.

📥 Installation & Setup

1. Install dependencies

Run from your project's root directory:

npm install

🔐 Set tool environment variables

In the .env file, you'll see environment variable placeholders, one for each workspace that the selected tools are from. For example, if you selected requests from 2 workspaces, e.g. Acme and Widgets, you'll see two placeholders:

ACME_API_KEY=
WIDGETS_API_KEY=

Update the values with actual API keys for each API. These environment variables are used inside of the generated tools to set the API key for each request. You can inspect a file in the tools directory to see how it works.

// environment variables are used inside of each tool file
const apiKey = process.env.ACME_API_KEY;

Caveat: This may not be correct for every API. The generation logic is relatively simple - for each workspace, we create an environment variable with the same name as the workspace slug, and then use that environment variable in each tool file that belongs to that workspace. If this isn't the right behavior for your chosen API, no problem! You can manually update anything in the .env file or tool files to accurately reflect the API's method of authentication.

Related MCP server: OpenAPI to MCP

🌐 Test the MCP Server with Postman

The MCP Server (mcpServer.js) exposes your automated API tools to MCP-compatible clients, such as Claude Desktop or the Postman Desktop Application. We recommend that you test the server with Postman first and then move on to using it with an LLM.

The Postman Desktop Application is the easiest way to run and test MCP servers. Testing the downloaded server first is optional but recommended.

Step 1: Download the latest Postman Desktop Application from https://www.postman.com/downloads/.

Step 2: Read out the documentation article here and see how to create an MCP request inside the Postman app.

Step 3: Set the type of the MCP request to STDIO and set the command to node </absolute/path/to/mcpServer.js>. If you have issues with using only node (e.g. an old version is used), supply an absolute path instead to a node version 18+. You can get the full path to node by running:

which node

To check the node version, run:

node --version

To get the absolute path to mcpServer.js, run:

realpath mcpServer.js

Use the node command followed by the full path to mcpServer.js as the command for your new Postman MCP Request. Then click the Connect button. You should see a list of tools that you selected before generating the server. You can test that each tool works here before connecting the MCP server to an LLM.

👩‍💻 Connect the MCP Server to Claude

You can connect your MCP server to any MCP client. Here we provide instructions for connecting it to Claude Desktop.

Step 1: Note the full path to node and the mcpServer.js from the previous step.

Step 2. Open Claude Desktop → Settings → Developers → Edit Config and add a new MCP server:

{
  "mcpServers": {
    "<server_name>": {
      "command": "<absolute/path/to/node>",
      "args": ["<absolute/path/to/mcpServer.js>"]
    }
  }
}

Restart Claude Desktop to activate this change. Make sure the new MCP is turned on and has a green circle next to it. If so, you're ready to begin a chat session that can use the tools you've connected.

Warning: If you don't supply an absolute path to a node version that is v18+, Claude (and other MCP clients) may fall back to another node version on the system of a previous version. In this case, the fetch API won't be present and tool calls will not work. If that happens, you can a) install a newer version of node and point to it in the command, or b) import node-fetch into each tool as fetch, making sure to also add the node-fetch dependency to your package.json.

Additional Options

🐳 Docker Deployment (Production)

For production deployments, you can use Docker:

1. Build Docker image

docker build -t <your_server_name> .

2. Claude Desktop Integration

Add Docker server configuration to Claude Desktop (Settings → Developers → Edit Config):

{
  "mcpServers": {
    "<your_server_name>": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "--env-file=.env", "<your_server_name>"]
    }
  }
}

Add your environment variables (API keys, etc.) inside the .env file.

The project comes bundled with the following minimal Docker setup:

FROM node:22.12-alpine AS builder

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install

COPY . .

ENTRYPOINT ["node", "mcpServer.js"]

🌐 Server-Sent Events (SSE)

To run the server with Server-Sent Events (SSE) support, use the --sse flag:

node mcpServer.js --sse

🛠️ Additional CLI commands

List tools

List descriptions and parameters from all generated tools with:

node index.js tools

Example:

Available Tools:

Workspace: acme-workspace
  Collection: useful-api
    list_all_customers
      Description: Retrieve a list of useful things.
      Parameters:
        - magic: The required magic power
        - limit: Number of results returned
        [...additional parameters...]

➕ Adding New Tools

Extend your MCP server with more tools easily:

Visit Postman MCP Generator.
Pick new API request(s), generate a new MCP server, and download it.
Copy new generated tool(s) into your existing project's tools/ folder.
Update your tools/paths.js file to include new tool references.

💬 Questions & Support

Visit the Postman MCP Generator page for updates and new capabilities.

Join the #mcp-lab channel in the Postman Discord to share what you've built and get help.

Available Tools

3 tools

update_activity_priorityC

Update the priority of an activity in Adobe Target.

ParametersJSON Schema

Name	Required	Description	Default
`tenant`	Yes	The tenant identifier.
`priority`	Yes	The new priority value for the activity.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates priority, implying a mutation, but fails to disclose critical traits such as required permissions, whether changes are reversible, potential side effects, or rate limits. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded with the core action and resource, making it highly concise and well-structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, return values, and usage context, failing to compensate for the absence of structured data and leaving the agent under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with clear documentation for both parameters ('tenant' and 'priority'). The description adds no additional meaning beyond what the schema provides, such as explaining priority values or tenant context, so it meets the baseline for high schema coverage without enhancing parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and the resource ('priority of an activity in Adobe Target'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'update_activity_schedule' or 'update_activity_state', but the focus on 'priority' provides implicit distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like the sibling tools. The description lacks context about prerequisites, scenarios where priority updates are appropriate, or any exclusions, leaving the agent without usage direction beyond the basic function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_activity_scheduleC

Update the activity schedule in Adobe Target.

ParametersJSON Schema

Name	Required	Description
`tenant`	Yes	The tenant identifier.
`startsAt`	Yes	The start time of the activity in ISO 8601 format.
`endsAt`	Yes	The end time of the activity in ISO 8601 format.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update' which implies a mutation, but doesn't clarify if this requires specific permissions, is destructive, has side effects, or what the response might be. This leaves significant gaps for a tool that modifies data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with zero wasted words. It is appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, error handling, or what the update entails, which is insufficient for safe and effective use by an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with clear documentation for all three parameters (tenant, startsAt, endsAt). The description adds no additional parameter details beyond what the schema provides, so it meets the baseline of 3 without compensating for any gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and the resource ('activity schedule in Adobe Target'), making the purpose immediately understandable. It distinguishes from sibling tools like 'update_activity_priority' and 'update_activity_state' by specifying the schedule aspect, though it doesn't explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like the sibling tools. It lacks context about prerequisites, such as needing an existing activity to update, or any exclusions, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_activity_stateC

Update the state of an activity in Adobe Target.

ParametersJSON Schema

Name	Required	Description	Default
`tenant`	Yes	The tenant identifier.
`state`	Yes	The new state to set for the activity.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether the change is reversible, error handling, or rate limits. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral traits like side effects. For a tool that changes system state, more context is needed to guide safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters (tenant and state). The description doesn't add any meaning beyond what the schema provides, such as explaining what 'state' values are valid or how 'tenant' relates to the activity. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Update') and resource ('state of an activity in Adobe Target'), making the purpose understandable. However, it doesn't differentiate this tool from its siblings (update_activity_priority and update_activity_schedule), which also update activity attributes, so it doesn't reach the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its siblings or alternatives. It lacks context about prerequisites, such as needing an existing activity, and doesn't mention when-not-to-use scenarios, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesAug 15, 2025
- First observedupdate_activity_priority
- First observedupdate_activity_schedule
- First observedupdate_activity_state

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-04-18 09:50 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting different attributes of an activity in Adobe Target: priority, schedule, and state. There is no overlap or ambiguity between them, making it easy for an agent to select the correct tool based on the specific update needed.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'update_activity_' as a prefix followed by the specific attribute (priority, schedule, state). This uniformity enhances readability and predictability across the tool set.

Tool Count2/5

With only 3 tools, the set feels thin for a server named 'Postman MCP Generator', which might imply broader functionality. While the tools cover specific update operations for Adobe Target activities, the scope seems limited, lacking create, get, delete, or other essential CRUD operations for a complete activity management surface.

Completeness2/5

The tool set is severely incomplete for managing activities in Adobe Target. It only provides update operations for priority, schedule, and state, missing create, read, delete, and other lifecycle operations. This will likely cause agent failures when trying to perform full activity workflows, as there are significant gaps in coverage.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1

Related MCP Servers

Postman MCP Generator
API Testing Developer Tools
Ucode-io
F
license
B
quality
D
maintenance
A server that implements the Model Context Protocol (MCP) standard, enabling LLMs like Claude to interact with selected Postman API requests through generated JavaScript tools.
Updated a year ago (2025-06-18 11:07 UTC)
4
-
OpenAPI to MCP
API Testing Developer Tools App Automation
procoders
A
license
Not graded
quality
D
maintenance
Automatically converts any OpenAPI specification or Postman Collection into an MCP server, enabling AI assistants like Claude to directly interact with REST APIs without writing any code.
Updated 9 months ago (2025-12-22 00:29 UTC)
Apache 2.0
Postman MCP Generator
API Testing Developer Tools App Automation
harichandra599
F
license
Not graded
quality
D
maintenance
An MCP server that converts Postman API requests into executable tools for LLMs using the Postman Runtime. It supports complex authentication types and enables seamless integration between Postman collections and MCP clients like Claude Desktop.
Updated 6 months ago (2026-03-27 12:50 UTC)
-
postman-mcp
API Testing Developer Tools
SalehKhatri
A
license
B
quality
D
maintenance
A Model Context Protocol (MCP) server that provides seamless integration with the Postman API, enabling AI assistants and applications to interact with Postman workspaces, collections, requests, environments, and folders programmatically.
Updated 7 months ago (2026-02-20 03:55 UTC)
19
13 npm
31
MIT