Skip to main content
TrustGate can turn an OpenAPI 3 document into MCP tools without standing up a separate MCP server. The registry is still type: MCP. The discriminator is mcp_target.source: mcp (default, a real MCP URL) or openapi (compile operations from a spec). Agents keep talking MCP to TrustGate. TrustGate compiles the document, lists each callable operation as a tool, and on tools/call issues the matching REST request.
OpenAPI registries are tools only. prompts/* and resources/* from that registry are empty. Other MCP registries on the same consumer still federate prompts and resources as usual.

Console

  1. Open TrustGateRegistryMCPAdd custom.
  2. Set Source to OpenAPI document (instead of MCP server URL).
  3. Enter the OpenAPI spec URL (http/https, OpenAPI 3.x). This must be the raw JSON or YAML document, not a Swagger UI page. Optionally set API base URL to override servers[0].
  4. Choose upstream auth: None, Static header, or OAuth2 client credentials.
  5. Select Validate OpenAPI. TrustGate fetches the spec, compiles tools, and previews names, methods, and paths. Connect stays blocked until validation succeeds (ok).
  6. Connect / Save. Bind the registry to an MCP consumer and use toolkits the same way as for a remote MCP server.
The data plane must be able to fetch the spec URL and call the resolved API base URL. SaaS cannot reach private VPC hosts unless you expose them; use Hybrid for internal APIs.

What gets compiled

Validate always returns HTTP 200 for spec outcomes and reports ok plus the failing stage (fetch, parse, compile). Create and update still compile server-side and return 422 if the document is invalid. Only OpenAPI 3.x is accepted. A Swagger 2.0 document fails at the parse stage with value of openapi must be a non-empty string; convert it first (for example with swagger2openapi) and publish the OpenAPI 3 result.

Auth to the REST API

How TrustGate authenticates to the OpenAPI backend (not how the agent authenticates to TrustGate): passthrough, exchange, and forwarded are not supported for OpenAPI sources.

Example: TrustGate Admin API

The Admin plane serves its own OpenAPI 3 document at GET /docs/openapi.json, public like Swagger UI. You can register it as an OpenAPI MCP source to drive Admin from an agent — useful for dogfooding and for checking a large real document.
  1. Use the Admin origin plus that path as the spec URL, for example https://admin.example/docs/openapi.json.
  2. Leave API base URL empty. The document declares servers: [{ "url": "/" }], so the base resolves to the host that served the spec.
  3. Use static auth with an Admin JWT (Authorization + Bearer <token>).
  4. Validate, connect, bind a consumer, then call tools/list. Expect on the order of tens of tools (GET /healthz, POST /v1/gateways, registry CRUD, including POST /v1/gateways/{gateway_id}/registries/validate-openapi).
  5. Curate with a toolkit before giving an agent the full Admin surface.
/docs/* (Swagger UI) publishes Swagger 2.0, which the compiler rejects at the parse stage. Always point spec_url at /docs/openapi.json, and never at the Swagger UI HTML page.
Do not point a production agent at live Admin unless that is an explicit operational choice. Prefer a scoped toolkit and a dedicated Admin token.