Show HN: MCP Gateway – Unifying Access to MCP Servers Without N×M Integrations
truefoundry.comMany teams connecting LLMs to external tools eventually encounter the same architectural issue: as more tools and agents are added, the integration pattern becomes an N×M mesh of direct connections. Each agent implements its own auth, retries, rate limiting, and logging; each tool needs credentials distributed to multiple places and observability becomes fragmented.
We built LLM gateway with this goal to provide a single place to manage authentication, authorization, routing, and observability for MCP servers, with a path toward a more general agent-gateway architecture in the future.
The system includes a central MCP registry, support for OAuth2/DCR integration, Virtual MCP Servers for curated toolsets, and a playground for experimenting with tool calls.
Resources -
Architecture Blog – Covers the N×M problem, gateway motivation, design choices, auth layers, Virtual MCP Servers, and the overall model.
https://www.truefoundry.com/blog/introducing-truefoundry-mcp...
Tutorial – Step-by-step guide to writing an MCP server, adding Okta-based OAuth, and integrating it with the Gateway.
https://docs.truefoundry.com/docs/ai-gateway/mcp-server-oaut...
Feedback on gaps and edge cases is welcome.
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.