Which integrations are available for this server?

Provides specialized tools to automatically parse .NET C# controller code and migrate API endpoints to Postman, including support for routes, HTTP methods, XML documentation comments, and request body generation. Enables comprehensive management of Postman collections, folders, and requests, allowing users to list, create, update, and delete API resources programmatically.

How do I use Postman MCP Server?

1. Click on "Install 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 Server Sync endpoints from this C# controller to my 'API V1' collection." 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 Server

by sondang91

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Postman MCP Server

Model Context Protocol (MCP) server for integrating Postman API with Cursor IDE, enabling automatic migration of API endpoints from .NET controllers to Postman collections.

🎯 Features

✅ List Collections: List all Postman collections in workspace
✅ Get Collection: Get detailed collection information
✅ Create Collection: Create new Postman collections
✅ Create Folder: Create folders to organize requests (with auto-fix validation errors)
✅ Create Request: Create API requests manually
✅ Update Request: Update existing requests
✅ Delete Request: Delete requests by ID or name (with recursive search)
✅ Sync from Controller: Automatically parse .NET controller code and migrate endpoints to Postman

Related MCP server: Postman MCP Generator

📋 Requirements

Node.js >= 18.0.0
Postman API Key (Get from Postman Account Settings)
Cursor IDE with MCP support

🚀 Quick Start

Step 1: Install Dependencies

cd .cursor/mcp-servers/postman
npm install

Step 2: Build Project

npm run build

Or use the setup script:

./setup.sh

Step 3: Get Postman API Key

Go to Postman Account Settings
Create or copy your API Key (format: PMAK-xxxxx-xxxxx)

Step 4: Configure Cursor MCP Settings

Add to Cursor MCP configuration (usually in ~/.cursor/mcp.json or Cursor Settings):

macOS - Get absolute path:

cd .cursor/mcp-servers/postman
./get-path.sh
# Script will copy path to clipboard

Configuration:

{
  "mcpServers": {
    "postman": {
      "command": "node",
      "args": ["/absolute/path/to/.cursor/mcp-servers/postman/dist/index.js"],
      "env": {
        "POSTMAN_API_KEY": "your-postman-api-key-here"
      }
    }
  }
}

Example for macOS:

{
  "mcpServers": {
    "postman": {
      "command": "node",
      "args": ["/Users/dangvietson/Desktop/feec-phase1-pm/feec-phase1-pmsystem/.cursor/mcp-servers/postman/dist/index.js"],
      "env": {
        "POSTMAN_API_KEY": "PMAK-xxxxx-xxxxx-xxxxx"
      }
    }
  }
}

Note: Replace /absolute/path/to/ with your actual absolute path.

Step 5: Restart Cursor IDE

Quit Cursor completely (Cmd + Q on macOS)
Reopen Cursor
Test: Type "List all Postman collections" in Cursor chat

📖 Usage Examples

1. List Collections

List all Postman collections

2. Create Collection

Create a new Postman collection named "FEEC PM System APIs" with description "Project Management System API endpoints"

3. Create Folder

Create folder "API V1" with description "Version 1.0 endpoints" in Postman collection 97f3e1da-a4e9-44f6-8d1a-83766a827e54

4. Create Request Manually

Create a new GET request in collection 97f3e1da-a4e9-44f6-8d1a-83766a827e54:
- Name: "Get User by ID"
- Method: GET
- URL: {{baseUrl}}/api/v1/users/{userId}
- Headers: Content-Type: application/json
- Description: Retrieve user details by ID

5. Auto-Sync from Controller (Recommended)

Use the custom command /migrate-endpoint-to-postman or manually:

Sync API endpoints from this controller code to Postman collection 97f3e1da-a4e9-44f6-8d1a-83766a827e54:

[Paste full C# controller code here]

Base URL: http://localhost:5020
API Version: 1.0
Folder: PM System API V1

The server will automatically:

Parse all HTTP endpoints ([HttpGet], [HttpPost], etc.)
Extract routes from [Route] attributes
Extract API version from [ApiVersion] attributes
Extract XML comments for descriptions
Extract API Code and Screen ID from comments
Generate request names: {API Code} - {API Name}
Generate request bodies for POST/PUT/PATCH
Handle path parameters ({id:guid} → :id)
Handle query parameters ([FromQuery])
Expand PagedRequest into pageNumber, pageSize, searchTerm
Add Authorization header only if [Authorize] attribute is present

6. Delete Request

Delete request "Test API Request" from Postman collection PMSystem

Or by ID:

Delete request with ID 8ea7c1f4-c9ba-4293-bbf4-b037f7962854 from collection 97f3e1da-a4e9-44f6-8d1a-83766a827e54

🔧 API Reference

Tool: `list_collections`

Description: List all Postman collections
Parameters: None
Returns: Array of collections with id, name, uid

Tool: `get_collection`

Description: Get detailed collection information
Parameters:
- collectionId (string, required): Collection ID (UID)
Returns: Full collection object with items, variables, etc.

Tool: `create_collection`

Description: Create new Postman collection
Parameters:
- name (string, required): Collection name
- description (string, optional): Collection description
Returns: Created collection object

Tool: `create_folder`

Description: Create folder in collection to organize requests
Parameters:
- collectionId (string, required): Collection ID
- name (string, required): Folder name
- description (string, optional): Folder description
Returns: Updated collection object
Features:
- Auto-fixes invalid collection variables (type validation)
- Creates folder with placeholder request (avoids empty folder validation error)
- Preserves entire collection structure

Tool: `create_request`

Description: Create API request in collection
Parameters:
- collectionId (string, required): Collection ID
- name (string, required): Request name
- method (string, required): HTTP method (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)
- url (string, required): Full URL or path
- headers (object, optional): HTTP headers as key-value pairs
- body (object, optional): Request body for POST/PUT/PATCH
  - mode: "raw", "urlencoded", "formdata"
  - raw: JSON string for raw body
- description (string, optional): Request description
- folderId (string, optional): Folder ID to organize requests
Returns: Updated collection object

Tool: `update_request`

Description: Update existing request
Parameters:
- collectionId (string, required): Collection ID
- requestId (string, required): Request ID (UID) to update
- name, method, url, headers, body, description (optional): Fields to update
Returns: Updated collection object

Tool: `delete_request`

Description: Delete API request from collection
Parameters:
- collectionId (string, required): Collection ID
- requestId (string, optional): Request ID (UID) to delete
- requestName (string, optional): Request name to find and delete
Returns: Updated collection object
Features:
- Delete by ID or name
- Recursive search in folders
- Auto-fixes collection variables
- Preserves collection structure

Tool: `sync_from_controller`

Description: Automatically migrate endpoints from .NET controller code
Parameters:
- collectionId (string, required): Postman collection ID
- controllerCode (string, required): Full C# controller code with XML comments
- baseUrl (string, required): Base URL (e.g., http://localhost:5020)
- apiVersion (string, optional): API version (default: "1.0")
- folderName (string, optional): Folder name to organize requests (will be created if not exists)
Returns: Summary of created requests with endpoint details
Features:
- Parses [Route], [HttpGet], [HttpPost], [HttpPut], [HttpDelete], [HttpPatch] attributes
- Extracts XML comments (/// <summary>, API Code:, Screen ID:)
- Generates request names: {API Code} - {API Name} (from summary)
- Generates request bodies from DTO properties
- Handles path parameters ({id:guid} → :id Postman format)
- Handles query parameters ([FromQuery])
- Expands PagedRequest into individual query parameters
- Adds Authorization header only if [Authorize] attribute is present
- Replaces [controller] placeholder with actual controller name
- Extracts major version from API version (e.g., "1.0" → "v1")
- Uses {{baseUrl}} Postman variable for URLs

🎨 Controller Code Requirements

For sync_from_controller to work optimally:

✅ Controller must have [ApiController] attribute
✅ Methods must have HTTP method attributes ([HttpGet], [HttpPost], etc.)
✅ XML comments with /// <summary> for descriptions
✅ API Code: XXXX in comments for request naming
✅ Screen ID: XXXX in comments (optional)

Example:

/// <summary>
/// Get vendor quotation history for specified vendors within a specific ES Version (v1.0)
/// API Code: QS0041
/// Screen ID: QS-L0004-2 (Estimation quotation vendor history)
/// </summary>
[HttpGet("quotation-history")]
public async Task<IActionResult> GetVendorQuotationHistory(
    [FromQuery] Guid versionId,
    [FromQuery(Name = "vendorId")] List<Guid> vendorIds,
    CancellationToken cancellationToken)
{
    // Implementation...
}

Generated Request:

Name: QS0041 - Get vendor quotation history for specified vendors within a specific ES Version
URL: {{baseUrl}}/api/v1/Vendors/quotation-history?versionId=...&vendorId=...
Method: GET
Headers: Only Authorization if [Authorize] is present

🔄 Development Workflow

Workflow 1: Manual Migration (Step-by-step)

Create Collection for each system (PM, DC, ES, QS, Master)
Develop API in .NET controller
Create Request in Postman via Cursor prompt
Test in Postman

Workflow 2: Auto-Sync (Bulk Migration) ⭐ Recommended

Develop API in .NET controller with complete XML comments
Use /migrate-endpoint-to-postman command or sync manually
Verify in Postman
Update if needed

Workflow 3: GitHub Actions Integration (Future)

Create GitHub Action workflow to auto-sync when PR is merged:

name: Sync APIs to Postman

on:
  pull_request:
    types: [closed]

jobs:
  sync-postman:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: |
          # Parse changed controllers
          # Call Postman MCP Server
          # Create/update requests

🔐 Security Notes

API Key: Do not commit POSTMAN_API_KEY to git (already in .gitignore)
Local Only: Server runs locally, not exposed externally
Environment Variables: Use .env file if needed (do not commit)

🐛 Troubleshooting

Server Not Starting

Check Node.js version: node --version (requires >= 18)
Check build: npm run build
Check absolute path in MCP config (must be absolute path)
After code changes: Quit Cursor completely and rebuild with npm run build

Postman API Errors

Verify API Key: Check key format (PMAK-...)
Check API limits: Postman has rate limits
Verify Collection ID: Collection ID must be UID (not name)
Check workspace permissions: Need Editor or Admin role

Endpoints Not Parsed

Ensure controller code has complete attributes
Check XML comments format (must use ///)
Verify route patterns
Check for [ApiController] attribute

Request Names Not Correct

Ensure API Code: XXXX is present in XML comments
Check summary format in <summary> tags
Rebuild MCP server after code changes: npm run build

Headers Not Added

Authorization header is only added when [Authorize] attribute is explicitly present
No default headers (X-API-Version, Accept, Content-Type) are added automatically
Headers are only added when explicitly defined in code (e.g., [FromHeader] parameters)

📁 Project Structure

.cursor/mcp-servers/postman/
├── src/
│   ├── index.ts              # Main MCP server implementation
│   └── controller-parser.ts  # .NET controller parser
├── dist/                     # Compiled JavaScript (after build)
├── package.json
├── tsconfig.json
├── .gitignore
├── README.md                 # This file
├── get-path.sh              # Helper script to get absolute path
├── setup.sh                 # Setup script
└── rebuild-after-quit.sh    # Rebuild script after quitting Cursor

🛠️ Development

Run in Development Mode

npm run dev

Type Check

npm run type-check

Build

npm run build

Important: After making code changes, you must:

Quit Cursor completely
Run npm run build
Reopen Cursor

Or use the helper script:

./rebuild-after-quit.sh

📚 References

🗺️ Roadmap

✅ Completed Features

List collections
Get collection details
Create collection
Create folder (with auto-fix validation errors)
Create request
Update request
Delete request (by ID or name, recursive search)
Sync from .NET controller (parse routes, methods, parameters)
Extract XML comments (summary, API Code, Screen ID)
Generate request names: {API Code} - {API Name}
Handle path/query parameters
Expand PagedRequest into individual parameters
Authorization header based on [Authorize] attribute
No default headers (only explicit headers from code)

🔄 Planned Enhancements

Phase 1: Enhanced Parsing

Support for [FromForm] parameters (multipart/form-data)
Support for [FromHeader] parameters (already parsed, need to add to headers)
Better DTO property type detection
Support for nested DTOs
Extract validation rules from FluentValidation

Phase 2: Advanced Features

Update existing requests (detect changes and update)
Delete deprecated endpoints
Support for multiple API versions in same collection
Generate Postman tests from controller code
Support for authentication (JWT, API Key, etc.)

Phase 3: Integration

GitHub Actions integration (auto-sync on PR merge)
Support for other frameworks (FastAPI, Express.js, etc.)
Export collection to OpenAPI/Swagger
Import from OpenAPI/Swagger

📝 Best Practices

Naming: Use API Code in XML comments for consistent naming
Organization: Create folders by system/version for easy management
Documentation: Add descriptions for requests for better understanding
Testing: Test requests after migration to ensure correctness
Authorization: Use [Authorize] attribute explicitly when authentication is required
Headers: Only add headers when explicitly defined in code

🤝 Contributing

When adding new features:

Update this README with new features
Test thoroughly
Update roadmap section
Rebuild and test in Cursor

Last Updated: 2026-01-23
Version: 1.0.0
Status: ✅ Production Ready

Available Tools

8 tools

create_collectionC

Create a new Postman collection

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Collection name
`description`	No	Collection description

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 but only states the basic action. It doesn't mention authentication requirements, whether this creates a local or cloud collection, what happens on duplicate names, rate limits, or the response format. For a mutation tool with zero annotation coverage, this is inadequate.

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 communicates the core purpose without any wasted words. It's appropriately sized for a simple creation tool and gets straight to the point.

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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation, whether the collection is immediately usable, what permissions are required, or what format the response takes. Given the complexity of creating a resource in an API platform, 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?

Schema description coverage is 100%, with both parameters ('name' and 'description') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the structured schema, so the baseline score of 3 is appropriate.

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 ('Create') and resource ('Postman collection'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like 'create_folder' or 'create_request' - all create operations on different Postman entities.

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. The description doesn't mention prerequisites, when collections should be created versus using existing ones, or how this relates to sibling tools like 'list_collections' or 'get_collection' for checking existing collections first.

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

create_folderC

Create a new folder in a Postman collection

ParametersJSON Schema

Name	Required	Description
`collectionId`	Yes	Postman collection ID (UID)
`name`	Yes	Folder name
`description`	No	Optional folder description

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 creates a folder but doesn't mention whether this requires specific permissions, if it's idempotent, what happens on failure, or what the response looks like (since there's no output schema). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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 unnecessary words. It's appropriately sized and front-loaded, with every part of the sentence contributing essential information about what the tool does.

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 that this is a mutation tool (creating a folder) with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, error handling, or response format, which are crucial for an agent to use the tool effectively. The 100% schema coverage helps with parameters, but other contextual gaps remain significant.

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 semantics beyond what the input schema already provides. Since schema description coverage is 100%, the schema fully documents all three parameters (collectionId, name, description) and their requirements. The description doesn't explain parameter relationships, constraints, or usage examples, so it meets the baseline of 3 where 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 action ('Create a new folder') and the resource ('in a Postman collection'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling tools like 'create_collection' or 'create_request', which would require mentioning what makes folder creation distinct from those other creation operations.

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. It doesn't mention prerequisites (e.g., needing an existing collection), exclusions, or comparisons to sibling tools like 'create_collection' for creating collections instead of folders. This leaves the agent without context for tool selection.

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

create_requestB

Create a new API request in a Postman collection

ParametersJSON Schema

Name	Required	Description
`collectionId`	Yes	Postman collection ID (UID) where to add the request
`name`	Yes	Request name (e.g., 'Get User by ID')
`method`	Yes	HTTP method
`url`	Yes	Full URL or path (e.g., 'https://api.example.com/users/{id}' or '/api/v1/users/{id}')
`headers`	No	HTTP headers as key-value pairs
`body`	No	Request body (for POST/PUT/PATCH)
`description`	No	Request description/documentation
`folderId`	No	Optional: Folder ID to organize requests. If provided, request will be created in this folder.
`folderName`	No	Optional: Folder name to organize requests. Will auto-find folderId. Takes precedence over folderId if both provided.

TDQS

B3.2/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 'Create' implies a write operation, it doesn't address permissions needed, whether the operation is idempotent, what happens on duplicate names, or what the response looks like. For a creation tool with 9 parameters and no annotation coverage, this leaves significant behavioral gaps.

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 states exactly what the tool does with zero wasted words. It's appropriately sized for a creation tool and front-loads the essential information 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 creation tool with 9 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation, error handling, or behavioral constraints. While the schema documents parameters well, the overall context for using this tool remains incomplete for 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?

Schema description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

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

Purpose5/5

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

The description clearly states the specific action ('Create a new API request') and resource ('in a Postman collection'), distinguishing it from siblings like create_collection or create_folder. It uses precise terminology that leaves no ambiguity about what the tool does.

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_request or delete_request. There's no mention of prerequisites (e.g., needing an existing collection), error conditions, or typical use cases. The agent must 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.

delete_requestC

Delete an API request from a Postman collection

ParametersJSON Schema

Name	Required	Description
`collectionId`	Yes	Postman collection ID (UID)
`requestId`	No	Request ID (UID) to delete. Can also use request name to find and delete.
`requestName`	No	Optional: Request name to find and delete (alternative to requestId)

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 deletes a request, implying a destructive mutation, but fails to mention critical details like permission requirements, whether deletion is reversible, error handling, 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, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.

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 tool's destructive nature, lack of annotations, and absence of an output schema, the description is incomplete. It does not address behavioral aspects like side effects, return values, or error conditions, which are crucial for safe and effective tool invocation in this context.

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, documenting all three parameters clearly. The description does not add any additional meaning or context beyond what the schema provides, such as explaining parameter interactions or usage nuances. Thus, it meets the baseline for high schema coverage.

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 the resource ('an API request from a Postman collection'), providing a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like 'update_request' or 'create_request' in terms of purpose, which prevents a perfect 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 offers no guidance on when to use this tool versus alternatives, such as 'update_request' for modifications or other deletion-related tools. It lacks context on prerequisites, exclusions, or specific scenarios, leaving the agent without usage direction.

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

get_collectionC

Get details of a specific Postman collection by ID

ParametersJSON Schema

Name	Required	Description	Default
`collectionId`	Yes	Postman collection ID (UID)

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 'Get details' but doesn't clarify whether this is a read-only operation, what permissions are required, how errors are handled, or what format the details are returned in. 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, clear sentence that efficiently conveys the core purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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 'details' are returned, how to interpret them, or any behavioral aspects like error handling. For a tool with no structured metadata, the description should provide more context to be fully useful.

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 schema description coverage is 100%, with the single parameter 'collectionId' fully documented in the schema as 'Postman collection ID (UID)'. The description adds no additional semantic context beyond what the schema already provides, so it meets the baseline score of 3.

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 tool's purpose with a specific verb ('Get details') and resource ('specific Postman collection by ID'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_collections', which retrieves multiple collections rather than a single one by ID.

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. It doesn't mention when to choose 'get_collection' over 'list_collections' or other sibling tools, nor does it specify any prerequisites or contextual usage scenarios.

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

list_collectionsB

List all Postman collections

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/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 action but doesn't describe what 'List all' entails—such as pagination, sorting, filtering, or response format—leaving critical behavioral traits unspecified for a tool that likely returns multiple items.

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 fluff. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.

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 listing multiple items and the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like how results are returned, potential limits, or error handling, which are essential for an agent to use the tool effectively.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't add parameter details, and the baseline score is 4 for tools with zero parameters, as it avoids unnecessary complexity.

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 ('List') and resource ('all Postman collections'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get_collection' which might retrieve a single collection, leaving some ambiguity about 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 like 'get_collection' or 'sync_from_controller'. The description lacks context about prerequisites, timing, 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.

sync_from_controllerB

Auto-migrate API endpoint from .NET controller code to Postman

ParametersJSON Schema

Name	Required	Description	Default
`collectionId`	Yes	Postman collection ID
`controllerCode`	Yes	Full C# controller code with XML comments
`baseUrl`	Yes	Base URL (e.g., 'http://localhost:5020' or 'https://api.example.com')
`apiVersion`	No	API version (e.g., '1.0') - extracted from [ApiVersion] attribute	1.0
`folderName`	No	Optional: Folder name to organize requests (will be created if not exists)
`folderId`	No	Optional: Folder ID to organize requests. Takes precedence over folderName if both provided.

TDQS

B3.2/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 mentions 'auto-migrate' but fails to detail critical behaviors: whether this is a read-only or write operation (implied mutation), how conflicts are handled, what happens to existing endpoints, authentication needs, rate limits, or error responses. This leaves significant gaps for an agent to understand the tool's impact.

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 front-loads the core purpose without unnecessary elaboration. Every word contributes directly to understanding the tool's function, making it appropriately sized and 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 migration tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, output format, and integration with sibling tools, leaving the agent with insufficient context to use it effectively beyond basic parameter passing.

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 all parameters thoroughly. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., folderName vs. folderId precedence) or usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the specific action ('auto-migrate') and resources involved ('.NET controller code to Postman API endpoint'), distinguishing it from sibling tools that perform individual operations like create_collection or update_request. It precisely communicates the tool's function without being vague or tautological.

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 manually creating requests with create_request or organizing collections with create_folder. It lacks context about prerequisites, such as needing an existing Postman collection, or exclusions, like not handling non-.NET code.

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

update_requestC

Update an existing API request in a Postman collection

ParametersJSON Schema

Name	Required	Description
`collectionId`	Yes	Postman collection ID
`requestId`	Yes	Request ID (UID) to update
`name`	No	Updated request name
`method`	No
`url`	No
`headers`	No
`body`	No
`description`	No

TDQS

C2.8/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 it's an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling, or response format. 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 that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy to parse quickly.

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 (8 parameters with nested objects, low schema coverage, no annotations, and no output schema), the description is insufficient. It doesn't address behavioral traits, parameter details, or output expectations, leaving significant gaps for a mutation tool that modifies API requests.

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

Parameters2/5

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

Schema description coverage is low at 38%, with only 'collectionId' and 'requestId' documented. The description doesn't add any parameter-specific information beyond the tool's general purpose, failing to compensate for the coverage gap. For example, it doesn't explain what 'body.mode' enums mean or how 'headers' should be structured.

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 ('an existing API request in a Postman collection'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_request' or 'delete_request', which would require mentioning it modifies rather than creates or removes requests.

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. It doesn't mention prerequisites (e.g., needing an existing request), exclusions, or compare to siblings like 'create_request' for new requests or 'delete_request' for removal, leaving usage context unclear.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific Postman entities (collections, folders, requests) with unambiguous actions. There is no overlap between tools like create_collection, create_folder, and create_request, which operate on different resources.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (e.g., create_collection, list_collections, update_request). The naming is predictable and uniform across all eight tools, making them easy to identify and use.

Tool Count5/5

With 8 tools, the server is well-scoped for managing Postman collections and requests. Each tool serves a clear purpose in the domain, covering essential operations without being overly sparse or bloated, which is appropriate for this functionality.

Completeness4/5

The tool set provides strong CRUD coverage for collections and requests, including create, get, list, update, and delete operations. However, there are minor gaps such as missing update/delete for collections and folders, and the sync_from_controller tool stands out as a specialized feature not fully integrated into the core workflow.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Carbon Voice
app.carbonvoice.mcp
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
Communication Knowledge & Memory Text Summarization
2
Sirro
io.github.Jonathanmberg
Shared memory for AI coding agents. Save once, reuse from Cursor, Claude Code, Codex.
Knowledge & Memory Developer Tools
1
Reqistry A
dev.reqistry
Discover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
Developer Tools Search Monitoring
131
Sprawl
to.sprawl
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
Agent Orchestration Autonomous Agents App Automation
1

Related MCP Servers

REST-to-Postman MCP
API Testing Developer Tools App Automation
runninghare
A
license
A
quality
D
maintenance
Converts REST API code (like NestJS controllers or FastAPI endpoints) to Postman collections and environments, helping developers automatically sync their API endpoints with Postman.
Updated a year ago (2025-04-13 08:33 UTC)
2
25
MIT
Postman MCP Generator
API Testing Developer Tools App Automation
ramborau
F
license
Not graded
quality
D
maintenance
Automatically converts Postman API collections into MCP-compatible tools for AI assistants. Enables users to interact with any API through natural language by generating JavaScript tools from Postman requests.
Updated 10 months ago (2025-10-22 00:04 UTC)
Postman MCP Server
API Testing Developer Tools App Automation
anarsyakir
A
license
Not graded
quality
D
maintenance
Enables interaction with Postman workspaces, collections, requests, responses, and monitors through the Postman API. Allows users to manage API collections, create and update requests/responses, and execute monitors directly from chat.
Updated 10 months ago (2025-10-23 09:59 UTC)
25
MIT
Code2Postman MCP
Code Analysis API Testing Developer Tools
marioToribi0
A
license
B
quality
D
maintenance
Automatically generates Postman collections from code directories by analyzing API endpoints and parameters, enabling easy testing, documentation, and sharing.
Updated 10 months ago (2025-11-02 22:41 UTC)
14
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/sondang91/postman-mcp-server'

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

Postman MCP Server

🎯 Features

📋 Requirements

🚀 Quick Start

Step 1: Install Dependencies

Step 2: Build Project

Step 3: Get Postman API Key

Step 4: Configure Cursor MCP Settings

Step 5: Restart Cursor IDE

📖 Usage Examples

1. List Collections

2. Create Collection

3. Create Folder

4. Create Request Manually

5. Auto-Sync from Controller (Recommended)

6. Delete Request

🔧 API Reference

Tool: list_collections

Tool: get_collection

Tool: create_collection

Tool: create_folder

Tool: create_request

Tool: update_request

Tool: delete_request

Tool: sync_from_controller

🎨 Controller Code Requirements

🔄 Development Workflow

Workflow 1: Manual Migration (Step-by-step)

Workflow 2: Auto-Sync (Bulk Migration) ⭐ Recommended

Workflow 3: GitHub Actions Integration (Future)

🔐 Security Notes

🐛 Troubleshooting

Server Not Starting

Postman API Errors

Endpoints Not Parsed

Request Names Not Correct

Headers Not Added

📁 Project Structure

🛠️ Development

Run in Development Mode

Type Check

Build

📚 References

🗺️ Roadmap

✅ Completed Features

🔄 Planned Enhancements

Phase 1: Enhanced Parsing

Phase 2: Advanced Features

Phase 3: Integration

📝 Best Practices

🤝 Contributing

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Tool: `list_collections`

Tool: `get_collection`

Tool: `create_collection`

Tool: `create_folder`

Tool: `create_request`

Tool: `update_request`

Tool: `delete_request`

Tool: `sync_from_controller`