Skip to main content

TrustGate’s MCP gateway (:8082) aggregates Model Context Protocol servers into one endpoint. Agents see a composed catalog of tools, prompts, and resources, with tenancy, auth, and observability applied in one place.

OpenAPI tools

Turn an OpenAPI 3 document into MCP tools instead of a server URL.

MCP registries

Each upstream is a registry of type MCP.

MCP Store

The self-service catalog people install from at /store/mcp.

Access

Who may install what from the Store, and the approval queue.

End users

Let your application connect each of its users’ own accounts.

Coding agents

Claude Code, Cursor, Codex, Copilot, and Copilot Studio.
The TrustGate data plane must reach each MCP registry url. SaaS cannot call private VPC endpoints unless you expose them. Use Hybrid for internal MCPs.

One endpoint, many servers

An agent connects to one TrustGate MCP endpoint and sees a unified surface. TrustGate speaks JSON-RPC over the streamable-http transport and implements the standard methods: Behind the endpoint, each upstream is an MCP registry (type: MCP). TrustGate fans list calls out to the bound registries, merges the results, and routes each call/read/get to the owning server. The initialize response carries an instructions string that tells the agent to route everything through the gateway and never wire an upstream MCP server into the client directly.

Tool name composition

How a tool or prompt is named on the merged surface depends on how many servers stand behind the endpoint: Both hashes are the first 16 hex characters of a SHA-256 digest (of the registry id and of the original name). The readable <name> part is cut at 26 characters, so the whole name stays within 64 characters. The name is stable for as long as the registry exists. Names are not aliased across an upgrade: a client that cached federated names from an earlier TrustGate release must refresh its tool and prompt lists (TrustGate pushes tools/list_changed when the stream opens).

Registering an MCP server

Connect MCP servers from the console:
  1. Open Agent GatewayRegistryMCP.
  2. Pick a catalog server (one-click when no extra config is needed) or Add custom. For a remote MCP server, paste the server URL. To expose a REST API instead, set Source to OpenAPI document and follow OpenAPI tools.
  3. For MCP URLs: configure transport (streamable HTTP), static headers, and upstream auth. For OpenAPI: the document URL, then Validate OpenAPI.
  4. Select Test connection (MCP URL) or complete validation (OpenAPI), then Connect / Save.
  5. Open the registry to browse live tools the server exposes.
Catalog servers can also be installed by people themselves through the MCP Store; a registry the Store creates carries origin: "store".

Toolkits and capability scope

A consumer does not automatically get every tool on every bound server. Access is governed by the consumer’s toolkit (mcp.toolkit), which lists grants that scope a registry to specific tools, prompts, or resources: A consumer with no toolkit exposes every capability of its bound registries. The surface is identical for every caller the consumer admits: the Access page governs the Store only and never narrows a consumer. To give two audiences different tools, create two consumers.

Fail mode

fail_mode on the consumer decides what happens when an upstream server is unavailable:
  • open: skip the failed server. When nothing was reachable, the error names the first skipped server’s cause instead of a generic “no upstream MCP server reachable”.
  • closed: fail the call.

Gateway meta-tools

Every MCP consumer with at least one MCP server bound also lists a few tools TrustGate implements itself. They are plumbing for managing the caller’s surface, not user capabilities; their descriptions say so, and trustgate_list_tools excludes them from its answer. A consumer whose toolkit is a deny-all (a toolkit with no tool entry) gets no gateway tools either.

Upstream authentication

mcp_target.auth.mode controls how TrustGate authenticates to the MCP server. Each mode has its own requirements: There is no mtls upstream mode. Client certificates authenticate to TrustGate (inbound mTLS), not from TrustGate to the MCP server.

Exchange patterns

The exchange mode implements standard token-exchange patterns:

Forwarded (per-user OAuth)

For SaaS servers where each end-user must connect their own account (e.g. their Asana), forwarded mode stores a per-user OAuth credential:
  • Set provider and either registration: auto (TrustGate registers the client) or registration: manual with client_id, authorize_url, and token_url.
  • A call for a user with no usable credential fails with JSON-RPC error -32003 (consent required). Its data carries provider, a connect_url, and a cause. The user opens the link, authorizes the provider once, and the credential is vaulted.
  • TrustGate refreshes expiring credentials automatically and re-prompts for consent only when a grant can no longer be refreshed. After a provider rejects a refresh token, the same token is not replayed.
Credentials are keyed per provider and per instance of the server (a fingerprint of the upstream resource), so two instances of the same catalog server on different deployments hold separate accounts. A connection is reported as connected — on the connect page, in trustgate_list_tools, and in the Portal — only while the credential can still be redeemed.

Machine callers: API key and mTLS

An MCP consumer called with an API key or a client certificate runs as the application itself, principal app:<consumer_id>. Rotating or renaming a key never strands an upstream account. The API key may be sent as X-AG-API-Key, x-api-key, or Authorization: Bearer ag_…. Machine callers carry no token of their own, so passthrough and the obo / token_exchange exchange patterns fail with an error naming the fix: give the upstream its own credential (static, client_credentials), link one account for the application (forwarded), or call the consumer with an identity-provider token. For forwarded servers, one shared account is linked to the application. Admins link it from the consumer’s Connect tab or the Admin API, with no API key in hand: An application that wants each of its users to hold their own account instead uses End users.

Agent authentication

The MCP Gateway is itself an OAuth2 authorization server for the agents connecting to it, implementing the standard discovery and flow endpoints: Together these let an agent register, obtain a token, call the unified MCP endpoint, and complete a one-time connection when a downstream service requires per-user authorization.

Keeping tool lists fresh

TrustGate pushes notifications/tools/list_changed on the SSE stream (GET /<slug>/mcp) once when the stream opens, and again whenever the caller’s surface changes: bound MCP registries or the toolkit are edited, a stored credential is connected or revoked, or a Store install, grant, or access level changes. Clients that honour the notification re-list without a reconnect.

Limits

Closing an MCP session cancels its in-flight requests.

Connect an agent

All clients use the same endpoint for a given consumer. The consumer’s Connect tab provides Cursor, Claude Code, and generic JSON snippets. Do not use a TrustGuard collector tgk_… as an MCP credential.