Tips and best practices for using the Postman API MCP server

With the Postman API MCP server, you empower AI agents (such as Cursor, Claude, or VS Code) to manage your Postman resources. You can request complex workflows and API interactions, and let the AI take care of the heavy lifting. This document covers some useful tips for working with agents and prompts you can use to get started with the Postman API MCP server.

Tips and best practices

AI agents can make mistakes, so when using agents with the Postman API MCP server, follow these best practices:

• Specify the MCP server to interact with Postman resources. Some LLM models try to interact with Postman using curl or the Postman CLI. To prevent this, it’s good practice beginning your prompts with a clear “When interacting with Postman resources, use the Postman MCP server you have access to” statement.
• Always review and confirm operations. When performing operations that make changes or are destructive, such as updating or deleting resources, always validate responses before you accept them from the agent.
• Pass resource IDs to reduce API calls. For example, to operate with a specific workspace, get the workspace’s ID and be clear when you state it. Otherwise, the LLM has to fetch all the workspaces, then select the specific one you want to work with, which can result in multiple API requests.

Postman API MCP server prompts

The following examples use VS Code's GitHub Copilot.

The following provide examples of useful prompts you can use to work with and manage your Postman elements:

Managing environments

In this use case, the user wants to update an environment variable’s value.

Prompt: Change the value of my Postman environment variable "baseUrl" in the "Local" environment to use http://localhost:8001.

Response: After passing the prompt, the agent returns the following response, confirming the variable change:

Create an OpenAPI and sync the spec with Postman

In this example, the user is working on a back end Django REST Framework API and wants to keep it in sync with Postman.

Prompt: This repository contains a Django REST Framework API. We’ve implemented a CRUD API for a resource called "Customer". We already have a Postman workspace called "Customers". I want you to:

• Infer an OpenAPI definition for my API (Customers CRUD), based on the model fields.
• Retrieve my workspace "Customers" ID. Use the Postman API MCP server tools.
• Create a Postman Spec in the existing “Customers” workspace.
• Create the collection from the spec.

Response: The agent confirms that it created the API specification and its related collection:

Update a collection’s documentation

In this example, the user updated their Postman Collection and wants to update its documentation to match the changes they've made.

Prompt: Update my collection "Customer API Collection" information to: "CRUD operations on the customers table. These endpoints require authentication and permissions on the Customer table."

Response: Here, the agent used the PATCH /collection/{collectionId} endpoint. It was able to fetch all the collections, then get the specific collection by name:

Perform a back end change based on Postman Spec changes

This example assumes the user is working with a Django REST Framework app. They're also an employee of an API design-first company, and want to make the changes in Postman's Spec Hub. The back end developers will then use the specification to implement the changes.

Prompt: I’ve updated the Postman Spec called "Customer API" and I’ve added some new fields to the Customer resources. Analyze the changes in the spec (retrieve it from Postman using the Postman API MCP server you have access to) and reflect them in the Django code (model and serializer).

Response: The agent performs several requests to get the workspace, then the list of specifications, and gets the specific spec. After analyzing the spec and model, the agent makes the proper changes in the code: