MCP plane

Beyond LLM traffic, TrustGate runs a dedicated MCP plane (:8082) that fronts Model Context Protocol servers. Rather than connecting an agent to each MCP server directly, TrustGate aggregates several servers into a single MCP endpoint — composing their tools, prompts, and resources — and applies the same tenancy, access control, auth, and observability as LLM traffic.

​

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.

​

Tool name composition

Because two servers can expose the same tool name, TrustGate keeps names unique on the merged surface:

• Unique names pass through unchanged.
• On a collision, the tool is prefixed with the registry name (e.g. asana_create_task).
• If that still collides, a short registry id is added; as a last resort a numeric suffix.

So an agent always sees stable, unambiguous names regardless of how many servers are behind the endpoint.

​

Registering an MCP server

Register a server as a registry of type: MCP with an mcp_target: Browse pre-seeded enterprise servers via GET /v1/mcp-servers-catalog, validate a connection with test-connection, and list a registry’s live tools via GET /v1/gateways/{gateway_id}/registries/{id}/tools.

​

Toolkits — scoping what an agent can use

A consumer doesn’t automatically get every tool on every bound server. Access is governed by a toolkit — a list of grants, each scoping a registry to specific tools, prompts, or resources: For inline MCP consumers, the toolkit lives on the consumer (mcp.toolkit). For role-based consumers, the effective view is built from the matched roles:

• Registries = the union of the matched roles’ MCP registries.
• Toolkit = the union of the roles’ mcp_policies toolkits. A role that binds an MCP registry without an explicit toolkit grants that server fully.

So one MCP endpoint can present a different, identity-scoped toolkit to each caller.

​

Fail mode

fail_mode decides what happens when an upstream server is unavailable:

• open — degrade gracefully (skip the failed server).
• closed — fail the call.

For role-based consumers, the effective mode is open only when every contributing role declares it open; otherwise it is closed (and closed when no role grants access).

​

Upstream authentication

mcp_target.auth.mode controls how TrustGate authenticates to the MCP server. Each mode has its own requirements:

​

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.
• The first call for a user with no stored credential returns a consent-required signal with a connect link; the user 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.

​

Agent authentication

The MCP plane 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 — when a downstream needs per-user authorization — complete a one-time connect without leaving the gateway.