openapi-mcp-gateway v0.5.0 adds resources, dynamic exposure, and spec-compliant auth
openapi-mcp-gateway `v0.5.0` ships MCP resource primitives, dynamic tool exposure for large specs like GitHub's ~1,200-operation API, and spec-compliant OAuth2 and bearer auth.
Score breakdown
The dynamic exposure mode directly solves the context-window overflow problem caused by large OpenAPI specs, which the post identifies as a fundamental limitation of static MCP tool registration.
- 01v0.5.0 ships MCP resource primitives, dynamic exposure, spec-compliant auth, and tool name/description overrides.
- 02GitHub's REST API has ~1,190 operations; static registration at ~300 tokens per tool produces 350K+ tokens in tools/list, exceeding frontier model context windows.
- 03Dynamic exposure replaces all operations with three meta-tools: list_operations, get_operation, and call_operation.
MrOops's `openapi-mcp-gateway` `v0.5.0` fulfills several items from the project's original roadmap, shipping MCP resource primitives, dynamic tool exposure, spec-compliant auth, and tool name/description overrides in a single release. The update is configured via a `servers.yml` file and launched with `uvx openapi-mcp-gateway --config servers.yml`.
The dynamic exposure feature targets the scaling problem posed by large OpenAPI specs.
The dynamic exposure feature targets the scaling problem posed by large OpenAPI specs. GitHub's REST API carries ~1,190 operations; static registration would emit every name, description, and JSON Schema at connect time, totalling 350K+ tokens in `tools/list` — larger than any frontier model's context window before the agent makes a single call. Setting `exposure: dynamic` on a server replaces all operations with three meta-tools: `list_operations` (discovery), `get_operation` (schema retrieval for a named operation), and `call_operation` (invocation). The agent walks them in sequence, adding two round trips before the first real call. The post offers a rough rule of thumb: under ~30 operations use static mode, 30–100 use static with `policy.allow` narrowing, and over ~100 use dynamic. The flag is per-server, so different backends in the same gateway can use different modes.
The `mode: auto` setting partitions a spec at startup: GET operations with no required query, header, or body parameters become MCP resources, while everything else (POST, PUT, DELETE, and GETs with required args) becomes tools. Vanilla Petstore3 produces 13 tools, 3 concrete resources, and 3 resource templates under this mode. Per-operation YAML overrides under an `operations:` key — matched by `operationId` — allow renaming resources, setting custom URI templates, and specifying non-JSON MIME types without forking the upstream spec. Unknown `operationId` values raise an error at startup so typos do not silently no-op. On the auth side, the gateway supports bearer tokens (e.g., for GitHub) and per-user OAuth2 with audience-bound tokens (e.g., for Asana), with no credential passthrough.
Key facts
- 01v0.5.0 ships MCP resource primitives, dynamic exposure, spec-compliant auth, and tool name/description overrides.
- 02GitHub's REST API has ~1,190 operations; static registration at ~300 tokens per tool produces 350K+ tokens in tools/list, exceeding frontier model context windows.
- 03Dynamic exposure replaces all operations with three meta-tools: list_operations, get_operation, and call_operation.
- 04Dynamic mode adds two round trips before the first real API call; recommended for specs with over ~100 operations.
- 05mode: auto partitions a spec at startup — eligible GETs become MCP resources, everything else becomes tools.
- 06Vanilla Petstore3 under mode: auto yields 13 tools, 3 concrete resources, and 3 resource templates.
- 07Per-operation YAML overrides keyed by operationId allow custom resource names, URI templates, and MIME types; unknown IDs raise an error at startup.
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Jun 9, 2026 · 17:05 UTC. How this works →