If a service already publishes an OpenAPI 3.0 document, this is two environment variables away from being usable by an agent, with no per-endpoint code. The lever worth learning is the route map: a spec with hundreds of paths would flood the model's tool list, and a method-plus-pattern filter cuts it to the handful that matter.
A converter that reads an OpenAPI 3.0 document and exposes the API it describes as MCP tools. It runs locally over stdio, or in Docker as a streamable-HTTP server.
- Tools generated from the spec, so an internal API becomes callable without writing a server
- HTTP header pass-through, so the caller's auth header reaches the upstream service
- Route filtering with `ROUTE_MAPS` — a list of HTTP methods plus a regex pattern, so only the endpoints you want become tools
- Two deployment shapes from the same package: `uvx openapi2mcpserver` for local stdio, or the published Docker image for a shared streamable-HTTP endpoint
- A server name you set yourself with `SERVER_NAME`, which is what the client will show
Two environment variables do the work: `BASE_URL` for your API host and `OPEN_API_DOC_JSON_URL` for the spec JSON. Set them in the client config, in a .env file at the project root, or as `-e` flags on the Docker run, which publishes port 9087.
One command — uvx openapi2mcpserver