Create an MCP server with Postman Flows

In Postman Flows, you can define a special scenario to create an Action that functions as a Model Context Protocol (MCP) server with MCP tools, prompts, and resources. Once deployed, the action’s URL can receive requests, process incoming data using blocks, and send responses.

Create an action and a toolDefinition scenario

To begin building an MCP server in Postman Flows, do the following:

Create an action in Postman Flows.
In the action, create a scenario and name it "toolDefinition".

Add tools to the toolDefinition scenario

In the toolDefinition scenario, you define the MCP tools that you want to make available to the MCP server you're building. Meanwhile, in the flow canvas, you add blocks to work with the data that the MCP server will obtain through each tool.

In the Body section of your toolDefinition scenario, enter one or more tools using the MCP tool definition structure. For example, adding the following to the scenario defines a tool that greets a user by name:

{
  "tools": [
    {
      "name": "greeter",
      "description": "Says hello to a person by their first name",
      "inputSchema": {
        "type": "object",
        "properties": {
          "first_name": {
            "type": "string",
            "description": "The person's first name"
          }
        },
        "required": [
          "first_name"
        ]
      }
    }
  ]
}

Each item in the properties element of the tool definition will become an argument in calls to the tool.

Add blocks to the action to perform the tool's task. For the greeter tool, you can use a Template block to concatenate the user's name to the message "Hello":

Recall that in your tool definition, the properties element defines a first_name property. Since tool definition properties become tool call arguments, the path to that property in the example Select block is arguments.first_name.
(Optional) For MCP servers that have multiple tools, you can use a Condition block to check which tool is being called in the request. Then a Select block can parse the tool's arguments.

If you don't want to add prompts or resources to your MCP server, go ahead and deploy the action, then test your MCP server.

(Optional) Add prompts to the MCP server

You can add prompts to your MCP server in Flows. Servers with prompts can provide structured messages and instructions for interacting with language models. Clients can discover available prompts, retrieve their contents, and provide arguments to customize them.

The unique identifier for a prompt is in the name field. MCP requests will include this name field in the params section of the request body. Once it receives the request, the action strips away outer elements of the request body. What's left for the action to process is a JSON object with two key-value pairs: one whose key is name and the other whose key is arguments. The value of arguments is one or more key-value pairs.

You can add one or more prompts to the Body section of a toolDefinition scenario with the structure shown in the following example prompt:

"prompts": [
  {
    "name": "example-prompt",
    "title": "Request Code Review",
    "description": "Asks the LLM to analyze data file to find anomalies",
    "arguments": [
      {
        "name": "file",
        "description": "The data file to review",
        "required": true
      }
    ]
  }
]

A real-life toolDefinition will include any prompts and resources along with tools. But the tool, prompt, and resource examples provided in this topic are all from different use cases. They're not intended to be part of a single toolDefinition. If you add your own prompts to the toolDefinition given in the tools example, you can use the structure that the example prompt illustrates. But don't add the same content – that is, the field values.

(Optional) Add resources to the MCP server

Resources enable servers to share data that provides context to language models. Each resource is uniquely identified by a URI (not a name as in a tool or a prompt). MCP requests will include this uri field in the params section of the request body. Once it receives the request, the action strips away outer elements of the request body. What's left for the action to process is a JSON object with one key-value pair whose key is uri.

You can add one or more resources to the Body section of your toolDefinition scenario with the structure shown in the following example resource:

"resources": [
      {
        "uri": "http://example.com/data.json",
        "name": "data.js",
        "title": "Data file",
        "description": "File containing important data",
        "mimeType": "application/json"
      }
    ]

If you want to parameterize the resources your MCP server exposes, you can add one or more resource templates to the Body section of your toolDefinition scenario. MCP resource templates are URI templates, structured as shown in the following example:

"resourceTemplates": [
      {
        "uriTemplate": "file:///{path}",
        "name": "Project Files",
        "title": "Project Files",
        "description": "Access files in the project directory",
        "mimeType": "application/octet-stream"
      }
    ]

Once it receives the request, the action strips some outer elements of the request body away. What's left for the action to process is a JSON object with two key-value pairs: one whose key is name and the other whose key is arguments. The value of arguments is one or more key-value pairs.

A real-life toolDefinition will include any prompts and resources along with tools. But the tool, prompt, and resource examples provided in this topic are all from different use cases. They're not intended to be part of a single toolDefinition. If you add your own resources to the toolDefinition given in the tools example, you can use the structure that the example resource illustrates. But don't add the same content – that is, the field values.

Deploy the MCP server

Given an action with a toolDefinition scenario that defines tools and (optionally) prompts and resources, you can deploy the action. Once deployed, your action will be an MCP server, meaning that the deployed action's URL will respond to MCP requests.

Test the MCP server

This topic assumes that your goal is to configure an AI application such as Claude, Cursor, or ChatGPT to use your new MCP server. Before you do that, you can use Postman to create and send an MCP request to the server.

This procedure tests whether the MCP tool definition and the flow itself work as designed. It won't test the functionality of any prompts or resources that you add to the tool definition, because those would require interacting with an LLM, which an MCP request won't do.

To test your MCP server, do the following:

Click Deploy (even if you have already deployed the action) to open the Deploy dialog.
Hover over the MCP URL and click Open in MCP request. A new MCP request opens.
In the MCP request, make sure HTTP is selected from the protocol dropdown list.
Click Connect. The MCP server's tools appear in the Message section. Click a tool to view and enter any required arguments.
Click Run to send the request to the MCP server. The params element of the request body will include the tool name and the arguments. Below that you'll find the response body in the Response section.