A bit more context: this Gateway is part of a progression from an LLM Gateway - MCP Gateway - a future Agent Gateway. The intent is to provide a consistent control plane for tool access, authentication, and policies around agent execution. MCP offers a clean interoperability layer, so the Gateway focuses on security, observability, and operational consistency rather than tool-specific logic.

There are areas still evolving (more granular budget/rate controls, extended tool composition inside Virtual MCP Servers, richer audit traces). Input from people who’ve built multi-tool agent systems or worked with MCP at scale would be especially useful.

Refer to our roadmap here - https://www.truefoundry.com/roadmap

One of the trickiest parts of MCP in practice has been auth propagation. As soon as the agent backend invokes the MCP server instead of the client, the original user’s auth context disappears—tools that require the user's session_id (or equivalent) suddenly only see a generic token. We ended up needing a pattern for:

- M2M-issued short-lived tokens for backend → MCP calls

- Per-request user metadata injection so tool calls can still act on behalf of the user

- Consistent OAuth2 / Okta validation so both layers trust each other

Was looking for this standarization.

Congrats on the launch!