> For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://learning.postman.com/llms.txt.

# About MCP toolsets in Postman

Postman's MCP toolsets are a way to design, group, and test the tools you plan to expose to AI agents, without building a real MCP server first. You define a tool's interface, try it out, and refine it, all before you write or touch any backend logic.

For a full walkthrough of generating and refining a toolset, see [Generate and implement MCP tools in Postman](/docs/design-apis/toolsets/generate-toolsets/).

## Toolset structure

A toolset is a named set of tool definitions. Each tool has:

* A **name**
* A **description**
* An **input schema**

These are the same three fields a real MCP server would expose. The difference is what's behind them: instead of pointing at production backend code, each tool in a toolset is backed by a mock response or a short script, so it behaves consistently in tests without a real implementation behind it.

Because a toolset is backed by mocks, it still runs as a real MCP server. You get an actual MCP endpoint you can point any agent harness at, inside or outside Postman. Tool calls just resolve against mock data rather than a live backend.

## Tool design before implementation

A tool's name, its description, and the shape of its input schema all affect whether an agent picks the right tool, passes the right arguments, and gets the job done. Those are also the parts of a tool that are easiest to get wrong on the first try, and the hardest to fix once real traffic depends on them.

Tools don't exist in isolation, either. Whether a given tool is easy for an agent to use often depends on what other tools are available alongside it, so a toolset is worth reviewing as a whole, not just one tool at a time. As you iterate, you might need to combine tools, split them, or change their input or output shapes. This is what API design starts to look like in an AI-native environment.

Testing a toolset's design first means you find naming collisions, ambiguous descriptions, and overcomplicated input schemas before they cost you a production incident or a confused agent, instead of after.

## Toolsets vs. API-spec generation

You likely already have a way to turn an existing API into an MCP server. That solves a different problem than a toolset does.

Auto-generating tools from an API specification gets you something that works, but it doesn't tell you whether the result is a good set of tools for an agent to use. Historically, tuning that design has meant redeploying a real server every time you change a description or a schema, to see whether the change helped. That's a slow loop that discourages iteration.

Toolsets separate the design problem from the implementation. You can take a generated tool list, or build one from scratch, and reshape the names, descriptions, and schemas until an agent actually calls them the way you intend, without redeploying anything.

## Agent Mode's role in toolsets

Agent Mode assists at both ends of the toolset workflow:

* It can generate and edit a toolset from a natural-language prompt, adding tools, adjusting descriptions, or reshaping schemas as you describe what you want.
* Once you're happy with a toolset's design, you can connect a repository and ask Agent Mode to build out the complete MCP server, implementation included, directly from that design. What started as a mock becomes real, working code, with no separate build step.

## Audit existing tools

Toolsets aren't only for brand-new tools. If you already ship an MCP server, you can recreate its tool list as a toolset and experiment with renaming, re-describing, or restructuring its inputs, all without touching the real server. Once you land on an improved design, carry it back to your actual implementation, or have Agent Mode regenerate that implementation from the updated toolset.