# Postman Collection to MCP: From Requests to MCP Tools > Source: > Published: 2026-09-12 19:29:57+00:00 A Postman collection can be a surprisingly useful starting point for an MCP server. Many teams have Postman collections before they have polished OpenAPI documentation. The collection already contains working requests, paths, query parameters, headers, bodies, example responses, and authentication notes. That is enough to begin thinking about MCP tools. But there is a catch. A Postman request is still a developer artifact. An MCP tool is an AI-facing capability. Converting one into the other takes review, naming, schema cleanup, authentication decisions, testing, and production preparation. This article walks through the practical path from Postman requests to MCP tools. Before importing a Postman collection anywhere, clean it. A real collection often contains more than production-ready API requests: Do not treat the collection as safe because it works in Postman. Before using it for MCP, check: This cleanup step matters because the MCP tool list will inherit a lot of meaning from the collection. If the collection is messy, the MCP server will probably be messy too. At a high level, each useful Postman request can become a candidate MCP tool. A request like this: ``` GET {{baseUrl}}/v1/customers/{{customer_id}}/tickets?status=open Authorization: Bearer {{token}} ``` Can become a tool like: ``` { "name": "list_open_customer_tickets", "description": "List open support tickets for one customer.", "inputSchema": { "type": "object", "properties": { "customer_id": { "type": "string", "description": "The customer ID to search tickets for." }, "limit": { "type": "integer", "description": "Maximum number of tickets to return." } }, "required": ["customer_id"] } } ``` The mapping includes more than method and URL. You need to review: Postman gives you the raw request shape. MCP needs a clear tool contract. Path variables usually become required tool inputs. For example: ``` GET /v1/customers/{{customer_id}} ``` Should map to: ``` { "customer_id": { "type": "string", "description": "The unique ID of the customer to retrieve." } } ``` If the endpoint cannot run without `customer_id`, the MCP schema should mark it as required. Bad schema: ``` { "customer_id": { "type": "string" } } ``` Better schema: ``` { "customer_id": { "type": "string", "description": "The customer ID from your application." } } ``` Path variables deserve clear descriptions because the AI client may have several IDs in context. `customer_id`, `workspace_id`, `ticket_id`, and `invoice_id` should not be blurred into a generic `id`. Query parameters often become optional tool inputs. Example: ``` GET /v1/tickets?customer_id={{customer_id}}&status={{status}}&limit={{limit}} ``` Candidate schema: ``` { "type": "object", "properties": { "customer_id": { "type": "string", "description": "Return tickets for this customer." }, "status": { "type": "string", "enum": ["open", "pending", "resolved"], "description": "Optional ticket status filter." }, "limit": { "type": "integer", "minimum": 1, "maximum": 50, "description": "Maximum number of tickets to return." } }, "required": ["customer_id"] } ``` Good query-parameter mapping should answer: For AI clients, unbounded list endpoints are risky. If your API supports `limit`, `cursor`, `page`, or `offset`, make those fields clear. Postman bodies often contain example payloads. That does not automatically mean the MCP tool should accept the same raw JSON blob. A request like: ``` POST /v1/tickets Content-Type: application/json { "customer_id": "{{customer_id}}", "subject": "{{subject}}", "priority": "{{priority}}", "message": "{{message}}" } ``` Can become: ``` { "name": "create_support_ticket", "description": "Create a support ticket for a customer.", "inputSchema": { "type": "object", "properties": { "customer_id": { "type": "string", "description": "The customer the ticket belongs to." }, "subject": { "type": "string", "description": "Short ticket subject." }, "priority": { "type": "string", "enum": ["low", "normal", "high"], "description": "Ticket priority." }, "message": { "type": "string", "description": "Initial support message." } }, "required": ["customer_id", "subject", "message"] } } ``` Avoid schemas that accept one giant `payload` object unless the API genuinely needs arbitrary JSON. A specific schema gives the AI client better boundaries and gives your team better validation tests. For write operations, the description should also say what changes. Many Postman collections contain requests like: ``` POST /login POST /oauth/token POST /refresh-token GET /api-keys ``` Those are usually not good MCP tools. Authentication should be part of the runtime connection and request flow. The model should not need to call `login` before using product capabilities. For API-backed MCP tools, the safer pattern is: When reviewing a Postman collection, remove personal tokens and secrets from the export. Keep variables like `{{token}}` or `{{apiKey}}` as placeholders, not real credentials. Then test: Authentication that works in Postman with your personal token may fail in MCP for a customer credential. Test that before production. A Postman collection can contain a lot of requests that are useful for developers and bad for AI agents. Start with a small workflow. "Let an AI support assistant look up customer context and create ticket notes." Useful requests might be: ``` GET /customers/{customer_id} GET /tickets?customer_id={customer_id} GET /tickets/{ticket_id} POST /tickets/{ticket_id}/notes ``` Requests to exclude from the first release might be: ``` DELETE /customers/{customer_id} POST /admin/reindex PATCH /users/{user_id}/role GET /internal/debug POST /oauth/token ``` This is the core selection rule: A request should become an MCP tool only when it maps to a clear, useful, authorized AI capability. The tool list is an allowlist. Treat it like a product and security decision. Postman request names are often written for humans browsing a collection. Examples: ``` Get Customer Create Update v2 List Old invoice route Test request ``` Those names are weak MCP tool names. Prefer names that are stable, specific, and action-oriented: ``` get_customer list_customer_tickets create_ticket_note get_customer_subscription list_unpaid_invoices ``` Tool descriptions should add the missing context: ``` List unpaid invoices for one customer. Use this when the user asks about outstanding billing or payment status. ``` The AI client should be able to choose the tool without reading your Postman folder structure. If two tools sound the same, fix the names before adding more tools. After importing and selecting operations, test the tool set before connecting a real client workflow. For each tool, test: For write tools, also test: Then test discovery: This is where Postman-derived tools either become reliable or stay as "requests that worked once on my machine." A hosted MCP server needs more than a successful import. Before production, confirm: With [0mcp](https://0mcp.io/), teams can import Postman collections, review detected requests, select useful API operations, refine tools, test in the Playground, and host the MCP server over Streamable HTTP. Existing API authentication continues to be used through API key, Bearer token, or OAuth pass-through, and customer credentials are passed through during requests rather than stored by 0mcp. 0mcp currently supports hosted Streamable HTTP servers, not local `stdio` servers. The original API remains responsible for business logic, authorization, pagination, rate limits, tenant boundaries, and validation. For the website version of this workflow, see [Postman to MCP](https://0mcp.io/blog/postman-to-mcp?utm_source=devto).