Skip to main content
This page documents which parts of the Model Context Protocol the TrueFoundry MCP Gateway supports, for each way an MCP server can be exposed through the gateway:
  1. Remote MCP servers accessed by third-party clients (Cursor, Claude Code, VS Code, custom agents) through the gateway
  2. Remote MCP servers accessed from the Playground and MCP server details page
  3. Virtual MCP servers that curate tools from multiple servers
  4. OpenAPI MCP servers generated from OpenAPI specifications
  5. Hosted stdio MCP servers run from a command via the gateway’s stdio proxy
Across these surfaces the gateway situationally acts as an MCP server toward your clients and as an MCP client toward upstream servers — Gateway Roles and Feature Support covers both.

​
Gateway Roles and Feature Support

​
Gateway as an MCP Server

The gateway serves MCP to your clients in two modes: as a direct proxy for remote and hosted stdio MCP servers, and as a gateway-implemented server for virtual and OpenAPI MCP servers. In both modes it handles authorization itself, independently of the upstream server.

​
Authorization

The gateway authenticates clients itself — 401 responses carry WWW-Authenticate challenges pointing at per-server RFC 9728 protected-resource metadata endpoints (/.well-known/oauth-protected-resource/...) — and acquires, stores, and refreshes upstream tokens on the user’s behalf; see MCP Gateway Auth & Security. Notes:
  1. The resource parameter is sent automatically with dynamic client registration, otherwise opt-in via the MCP server’s auth configuration.

​
Direct Proxy

For remote MCP servers and hosted stdio MCP servers the gateway is a transparent proxy: JSON-RPC bodies are forwarded unmodified, the protocol version is negotiated end to end, and the spec’s protocol headers (MCP-Protocol-Version, Mcp-Method, Mcp-Name, Mcp-Param-*) are forwarded by default. Incremental spec additions — pagination, audio content, icons, title/_meta fields, and SSE stream resumability — are all forwarded transparently by the gateway from the revision that introduced them.

​
Gateway-Implemented Servers

Virtual and OpenAPI MCP servers are implemented by the gateway itself over streamable HTTP at fixed protocol version 2025-06-18; unsupported methods return “method not found”. For virtual servers, tools/list merges and de-duplicates tools from all backing servers and tools/call routes each call to the right one; for OpenAPI servers, tool calls are translated into HTTP requests against your API.

​
Gateway as an MCP Client

Scenarios where the gateway connects out to MCP servers with its own internal client:
  • Virtual MCP servers — connections to each backing server
  • Playground and MCP server details page — listing and trying tools, prompts, and resources from the TrueFoundry UI
The internal client probes streamable HTTP first with automatic fallback to legacy HTTP+SSE, negotiates protocol versions up to 2025-11-25, and handles upstream OAuth (registration, discovery, grants, and refresh — see MCP Gateway Auth & Security).

​
Extensions

On the direct-proxy path, extension negotiation and extension methods are forwarded unmodified; whether an extension works depends on your client and the upstream server.

​
Playground

The Playground and the MCP server details page interact with MCP servers through the gateway’s internal MCP client:

​
Frequently Asked Questions

Yes. MCP-Protocol-Version and the Mcp-* header family (Mcp-Method, Mcp-Name, Mcp-Param-*) are forwarded to upstream servers by default, alongside content-type, accept, mcp-session-id, and last-event-id. The forwarded header set remains configurable at the gateway deployment level.
Sessions (mcp-session-id) are forwarded between your client and the upstream server without modification.
Use streamable HTTP. It is the current MCP standard, is preferred by the gateway in both directions, and is required for virtual, OpenAPI, and stdio MCP servers. Legacy HTTP+SSE is supported only for remote MCP servers, for compatibility with older servers and clients.