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.
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 thestreamable-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:- Open Agent Gateway → Registry → MCP.
- 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.
- For MCP URLs: configure transport (streamable HTTP), static headers, and upstream auth. For OpenAPI: the document URL, then Validate OpenAPI.
- Select Test connection (MCP URL) or complete validation (OpenAPI), then Connect / Save.
- 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, andtrustgate_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
Theexchange 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
providerand eitherregistration: auto(TrustGate registers the client) orregistration: manualwithclient_id,authorize_url, andtoken_url. - A call for a user with no usable credential fails with JSON-RPC error
-32003(consent required). Itsdatacarriesprovider, aconnect_url, and acause. 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, principalapp:<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 pushesnotifications/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.
Related
- MCP Store: the self-service catalog people install from
- Access: Store levels, grants, and approvals
- End users: per-user accounts behind an API-key application
- OpenAPI to MCP: expose REST API operations as tools
- Architecture: how the MCP plane sits next to Admin and Proxy
- Okta · Entra ID