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. Notes:
  1. When the client includes a progressToken in the tools/call request’s _meta, virtual servers relay notifications/progress from the backing server to the client over the response stream. OpenAPI MCP servers do not emit progress notifications.

​
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 (the 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 2026-07-28, and handles upstream OAuth (registration, discovery, grants, and refresh — see MCP Gateway Auth & Security). Version negotiation is automatic: the client first probes the upstream server for 2026-07-28 (server/discover) and falls back to the initialize handshake for servers that only speak earlier revisions, so older upstream servers keep working without any configuration change.

​
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

“Playground” here refers to the MCP server details page in the TrueFoundry UI — the page where you open a registered MCP server to list its tools, call a tool with sample arguments, and browse its prompts and resources. It interacts with the server through the gateway’s internal MCP client. The operations available are the same regardless of the revision the server speaks:

​
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.