Postman MCP vs OpenAPI MCP vs FastAPI MCP (2026)

Before comparing these three, one practical warning, because two of the three have an npm package that is not what the name suggests.

Running npx -y postman-mcp-server does not install Postman's MCP server. The unscoped name on npm belongs to ankit-roy-0602/postman-mcp-server and was on version 1.2.0 when I checked the registry on 22 August 2026. Postman's own server is scoped: @postman/postman-mcp-server, version 2.12.0, published from postmanlabs/postman-mcp-server. The unscoped one is a working project, not malware, and it is also not the thing you meant to hand your Postman API key to.

The same trap sits on the OpenAPI side. mcp-openapi-server on npm resolves to a package published from a GitLab repository by a different author. Ivo Toby's widely linked server, the one at github.com/ivo-toby/mcp-openapi-server, publishes as @ivotoby/openapi-mcp-server at version 1.16.1. And plain openapi-mcp-server is a third project entirely, built for the openapisearch.com API.

Skill directories propagate the short names because they look tidier. Check the scope.

The three at a glance

Star counts and dates come from the GitHub API on the publication date. FastAPI MCP's are inflated relative to the others by being a general-purpose library rather than an agent add-on, so read the column as scale, not quality.

They are not competitors

The comparison people expect is which of these is the best API MCP server. That question does not resolve, because they sit at different points in the request.

Postman MCP points the agent at work you have already written down. OpenAPI MCP points it at somebody else's API through the contract. FastAPI MCP points somebody else's agent at the API you are building. Most teams end up wanting two of the three, and the pair depends on whether you are mostly consuming or mostly publishing.

Postman MCP — for teams already living in Postman

If your API knowledge is already encoded in collections, environments and monitors, this is the least work by a wide margin. The agent browses collections, reads environment variables, runs requests and manages workspaces through the Postman API.

Two deployment modes. The hosted remote server at https://mcp.postman.com authenticates with OAuth and needs no key handling, and Postman's docs push you there first. Local stdio runs through npx and expects POSTMAN_API_KEY in the environment:

npx @postman/postman-mcp-server

Four tool configurations ship: minimal, the default; code, which adds client code generation; full, advertised at over 100 tools; and learn, which searches Postman's documentation. Flags like --code and --full select them locally.

Stay on minimal unless something specific is missing. Over 100 tool definitions is a large amount of context spent before the agent has read a single request, and the practical effect of a bloated tool list is worse selection, not better coverage.

Apache-2.0, and the repository was pushed three days before this was written, which is the healthiest maintenance signal of the three.

The limitation is the dependency. This server talks to the Postman platform, so an agent using it needs a Postman account, and collections that have drifted from the running API produce confidently wrong requests. It automates your documented intent, including where that intent is stale.

OpenAPI MCP — for calling APIs you do not own

This is the one to reach for when a third-party API has a spec and you want the agent to use it without you writing a wrapper.

npx -y @ivotoby/openapi-mcp-server

Two environment variables carry the configuration: API_BASE_URL for the target, and OPENAPI_SPEC_PATH for the spec, which loads from a URL, a local file, stdin, or inline JSON or YAML. API_HEADERS takes comma-separated key:value pairs for authentication.

The design decision that makes it usable is tool modes. Loading every operation in a large spec generates hundreds of tools and swamps the context, so it also offers dynamic meta-tools, where the agent discovers operations on demand, and an explicit mode where you name the tools you want. On any real enterprise spec, one of the latter two is the correct choice.

It also supports MCP prompts and resources, so you can attach templated messages and static reference content next to the endpoints. Handy for the conventions a spec does not capture: which of four status endpoints is authoritative, which fields are deprecated in practice.

MIT, last pushed mid-June 2026. Quieter than Postman's but not stale.

The honest caveat is that this inherits your spec's quality. A spec with vague descriptions and untyped responses produces tools the agent picks badly, and no amount of prompting fixes a contract that does not describe the API.

FastAPI MCP — the other direction entirely

FastAPI MCP is a library you add to your own service so agents can call it.

uv add fastapi-mcp
# or
pip install fastapi-mcp

from fastapi import FastAPI
from fastapi_mcp import FastApiMCP

app = FastAPI()
mcp = FastApiMCP(app)
mcp.mount()

That is the whole integration. Your endpoints become MCP tools served at your app's base URL plus /mcp, over ASGI transport that talks to the app directly rather than round-tripping over HTTP.

The part worth appreciating: authentication reuses FastAPI's Depends(). Whatever guards your REST endpoints guards the MCP surface, with no second auth path to get wrong. Given how much MCP tooling ships with authorisation bolted on afterwards, this is the right default.

The concern is cadence. The repository was last pushed in November 2025, roughly nine months before this was published, against a protocol that has moved in that window. PyPI shows 0.4.0. Twelve thousand stars and no recent commits usually means widely adopted and lightly maintained. Read the open issues before it becomes load-bearing.

It is also not on npm at all, so any listing printing claude mcp add fastapi-mcp -- npx -y ... was generated rather than checked.

Picking

Already on Postman: take the Postman server, run minimal, use the remote OAuth endpoint, skip the key handling.

Consuming third-party APIs with specs: take @ivotoby/openapi-mcp-server, and pick dynamic or explicit tool mode from the start rather than after your context fills.

Publishing a FastAPI service you want agents to call: take FastAPI MCP, and check the issue tracker first.

Wanting one server that covers all three: none of them do, and a wrapper that tried would be worse at each job.

For the layer beneath this, our guide to building your own MCP servers covers writing one from scratch, which is often less work than bending an existing server into a shape it was not built for. On the testing side, agent skills for QA and test automation covers what to do once the agent can reach your endpoints. And the full tool list for developers covers the non-MCP options.

One security note that applies to all three

Each of these hands an agent the ability to make authenticated requests to real systems. Postman MCP with a workspace key can modify collections and trigger monitors. The OpenAPI server sends whatever headers you configured to whatever base URL you set. FastAPI MCP exposes your endpoints, including any you forgot were mounted.

The mitigations are ordinary and worth stating anyway. Scope the credentials, so a read-only Postman key for an agent that only needs to read. Point at staging before production. Read the tool list once after install, because that is the shortest honest description of what the agent can now do. And pin the exact package name, scope included, since that is where this article started.

FAQ

Which one should I install if I only pick one? If your team already runs Postman, take the Postman MCP server, because the collections and environments your agent needs are already written. If you consume third-party APIs and have their OpenAPI specs, take @ivotoby/openapi-mcp-server. FastAPI MCP is not an alternative to either: it exposes an API you are building rather than helping you call someone else's.

Is npx postman-mcp-server the official Postman package? No. The unscoped postman-mcp-server on npm is published from ankit-roy-0602/postman-mcp-server and sat at version 1.2.0 when this was checked. Postman's own server is the scoped @postman/postman-mcp-server, version 2.12.0, published from postmanlabs/postman-mcp-server. Installing the unscoped name gives you a different maintainer's code with your Postman API key in its environment.

Can I use FastAPI MCP with Claude Code? Yes, but you connect to it rather than install it. You add FastApiMCP(app) and mcp.mount() to your own FastAPI application, which serves MCP at your app's base URL plus /mcp, then point Claude Code at that endpoint. It ships on PyPI, not npm, so any claude mcp add fastapi-mcp -- npx line you see published is wrong.

Does the Postman MCP server need a Postman API key? For the local stdio mode, yes, set POSTMAN_API_KEY in the environment. The hosted remote server at mcp.postman.com uses OAuth instead and needs no manual key, which is the faster setup and the one Postman's own docs point to first.

Why does tool count matter when choosing an MCP server? Every exposed tool spends context before the agent does any work. Postman's full mode advertises over 100 tools, which is why minimal is the default. The OpenAPI server has the same problem in a sharper form, since a large spec can generate hundreds of tools, and it offers a dynamic meta-tool mode and an explicit allow-list to avoid that. Load the endpoints the task needs.