Postman Collection to MCP: From Requests to MCP Tools

A developer outlines a practical workflow for converting Postman collections into Model Context Protocol (MCP) server tools, mapping raw API requests into AI-facing tool contracts. The guide covers cleaning collections, translating path and query parameters into typed input schemas, and defining required versus optional fields. It emphasizes that Postman requests are developer artifacts requiring review, naming, schema cleanup, and authentication decisions before becoming MCP tools.

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 .