Skip to main content
Glama
Ucode-io

Postman MCP Generator

by Ucode-io
OverviewSchemaRelated ServersScoreDiscussions
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:

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: Postman MCP Generator

🌐 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:

  1. Visit Postman MCP Generator.

  2. Pick new API request(s), generate a new MCP server, and download it.

  3. Copy new generated tool(s) into your existing project's tools/ folder.

  4. 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

4 tools
delete_dataC

Delete data from the Ucode Items API.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe identifier of the entity to be deleted.

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 full burden for behavioral disclosure. While 'Delete' implies a destructive operation, it doesn't specify whether deletion is permanent or reversible, what permissions are required, whether there are confirmation steps, or what happens to related data. This is inadequate for a destructive 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 no wasted words. It's appropriately sized for a simple tool and gets straight to the point 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?

For a destructive deletion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'data' means in this context, what the deletion consequences are, what gets returned (if anything), or how this differs from other data manipulation operations. The minimal description leaves critical gaps.

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 the single 'id' parameter completely. The description doesn't add any parameter information beyond what's in the schema, meeting the baseline expectation when 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 action ('Delete') and target resource ('data from the Ucode Items API'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'update_data' or 'post_data' beyond the different action verb.

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 about when to use this tool versus alternatives like 'update_data' or 'get_data'. The description doesn't mention prerequisites, consequences, or appropriate contexts for deletion versus other operations.

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

get_dataC

Get data from the Ucode Items API.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the resource to retrieve.

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get data' which implies a read operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what the response looks like. This is a significant gap for a tool with no 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.

Conciseness4/5

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to parse, though it could be more informative without sacrificing brevity.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'data' is returned, how it's structured, or any behavioral traits like side effects. For a tool with siblings indicating a CRUD-like API, more context is needed to guide the agent effectively.

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 description adds no parameter-specific information beyond the input schema, which has 100% coverage for the single parameter 'id'. Since the schema already fully documents the parameter, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's completeness.

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

Purpose3/5

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

The description states the action ('Get data') and target ('from the Ucode Items API'), which is clear but vague. It doesn't specify what kind of data is retrieved or differentiate from sibling tools like 'delete_data' or 'update_data', which would require more specificity about the operation's scope.

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. With siblings like 'delete_data', 'post_data', and 'update_data', the description lacks explicit instructions on use cases, prerequisites, or 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.

post_dataC

Post data to the Ucode Items API.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesThe name to be added in the request body.

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Post data' implies a write operation, but it doesn't specify permissions needed, side effects, error handling, or response format. This leaves critical behavioral traits undocumented, making it insufficient for safe and effective use.

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 directly states the tool's action and target without unnecessary details. It's appropriately sized and front-loaded, making it easy to parse quickly. This is an example of optimal 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 the lack of annotations and output schema, the description is incomplete for a write operation tool. It doesn't explain what happens after posting (e.g., success response, error cases), nor does it address behavioral aspects like authentication or rate limits. For a tool with one parameter but no structured safety info, more context is needed.

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 the 'name' parameter clearly documented. The description adds no additional meaning beyond the schema, such as examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

Purpose3/5

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

The description states the action ('Post data') and target ('Ucode Items API'), which clarifies the basic purpose. However, it doesn't specify what type of data is posted or how it differs from sibling tools like 'update_data', making it somewhat vague. It avoids tautology by not just restating the name.

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 'update_data' or 'delete_data'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on the name alone. This lack of explicit direction reduces its effectiveness.

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

update_dataC

Update data on the Ucode Items API.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe identifier of the entity to be updated.
nameYesThe new name to update in the data.

TDQS

C2.7/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 data,' which implies a mutation operation, but doesn't cover permissions, side effects, error handling, or response format. For a mutation tool without annotations, this is insufficient to inform the agent adequately.

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 no wasted words. It's front-loaded with the core action and target, making it easy to parse. Every part of the sentence contributes directly to the tool's purpose, earning a high score 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 the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, usage context, and return values, which are critical for an agent to operate effectively. The schema covers parameters well, but overall context is insufficient.

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, clearly documenting both parameters ('id' and 'name'). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. According to the rules, with high schema coverage, the baseline is 3, which is appropriate here.

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

Purpose3/5

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

The description states the action ('Update') and target ('data on the Ucode Items API'), which is clear but vague. It doesn't specify what type of data or entity is being updated, and it doesn't differentiate from sibling tools like 'post_data' (create) or 'delete_data' (remove). The purpose is understandable but lacks specificity.

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 'post_data' for creation or 'delete_data' for removal. The description implies it's for updates but doesn't clarify prerequisites, such as needing an existing entity ID, or contextual constraints. This leaves the agent with minimal direction.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • First observeddelete_data
    • First observedget_data
    • First observedpost_data
    • First observedupdate_data
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: delete, get, post, and update data, with no overlap in functionality. The action verbs (delete, get, post, update) are unambiguous and map directly to standard HTTP methods, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., delete_data, get_data, post_data, update_data), using snake_case uniformly. This predictable naming scheme enhances readability and usability for agents.

Tool Count5/5

With 4 tools, the set is well-scoped for the Ucode Items API domain, covering the essential CRUD operations (create, read, update, delete). This count is appropriate, as each tool earns its place without being excessive or insufficient for the server's purpose.

Completeness5/5

The tool set provides complete CRUD coverage for the Ucode Items API, with no obvious gaps. It includes post_data (create), get_data (read), update_data (update), and delete_data (delete), ensuring agents can handle the full lifecycle of data operations without dead ends.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Postman MCP Generator

    abhishekms1047
    F
    license
    Not graded
    quality
    D
    maintenance
    Generates MCP servers from Postman API requests, automatically creating JavaScript tools that enable LLMs to interact with any API documented in Postman collections. Supports authentication configuration and deployment via STDIO or SSE.
    -

  • Postman MCP Generator

    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.
    -

  • postman-mcp

    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.
    19
    25
    31
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ucode-io/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server