When Anthropic introduced the Model Context Protocol (MCP) in late 2024, it felt like a turning point. Almost overnight, MCP became the default way to expose tools, services, and data sources to LLM-powered agents. The ecosystem exploded new MCP servers, integrations, and examples appeared at a pace I hadn’t seen before.
At the time, the excitement made sense. MCP solved a real problem: standardizing how models interact with external systems. But as the tooling ecosystem grew, something else started to emerge more quietly alongside it a new category that wasn’t getting as much attention yet.
MCP gateways.
I didn’t arrive at that conclusion by reading a whitepaper. I ran into it the hard way, while trying to take an MCP-based agent from “cool demo” to something that could actually run in production.
Building a Production Agent Changed Everything
My initial MCP setup was simple. I connected my agent directly to a set of MCP servers and let the model decide which tools to call. For early experiments, this worked surprisingly well. The agent could browse files, query APIs, and chain actions together with minimal effort on my part.
The problems only started showing up when I treated the agent like real infrastructure.
As I added more tools and ran the agent more frequently, the cracks became impossible to ignore. Nothing was technically broken, but everything felt fragile. I realized that MCP made it easy to expose tools but it didn’t give me much control over how those tools were used once they were exposed.
That gap became the central challenge.
What Broke at Scale
The first issue I noticed was lack of isolation. Every tool I exposed to the agent was effectively available all the time. Read operations, write operations, destructive commands they all lived side by side. If the model made a bad decision, there was nothing in between to stop it.
Then came observability, or rather the lack of it. When something went wrong, it was difficult to reconstruct what actually happened. Which tools were called? In what order? With what inputs? Across multiple reasoning steps, the trail went cold very quickly.
Performance and latency followed close behind. As the tool list grew, the model had to reason over more context every time. That extra reasoning time added up, especially in multi-step agent loops.
Finally, there was token cost. Every additional tool description increased prompt size. Even when a tool wasn’t used, I was paying for the model to consider it. At small scale this is easy to ignore. At production scale, it becomes a real cost center.
Individually, these were annoyances. Together, they were a sign that something fundamental was missing.
Realizing MCP Needed a Control Plane
At some point, it clicked that I had seen this problem before just not in the AI world.
Early REST APIs were often wired together directly too. That worked until teams needed authentication, rate limiting, monitoring, and traffic control. The solution wasn’t rewriting the APIs themselves; it was introducing API gateways.
What I needed for MCP was the same idea: a control plane that sits between the agent and the tools.
That’s when the concept of an MCP gateway started to make sense.
Finding the Solution: MCP Gateways
An MCP gateway doesn’t replace MCP servers. It sits in front of them and handles everything MCP intentionally leaves out. Once I started thinking in those terms, the architecture became much cleaner.
A gateway allows you to:
- Authenticate and authorize tool access
- Filter which tools are exposed per request or agent
- Control execution behavior (manual vs auto-execute)
- Enforce rate limits and safety policies
- Collect logs, metrics, and traces in one place
Instead of the agent talking directly to every MCP server, it talks to a single control layer. That one change resolves an entire class of problems.
In 2024, this pattern existed more as an idea than a product. By 2025, that started to change.
Bifrost as a Reference Implementation
I began using Bifrost as MCP gateway capabilities started to solidify. Early versions focused on MCP server integrations, but over time Bifrost evolved into something more complete a production-grade gateway that reflected the exact lessons I had learned building agents the hard way.
What made Bifrost useful wasn’t that it added “more features.” It formalized the control-plane model MCP setups were missing.
Hands-On: Adding an MCP Client
After I started using Bifrost as a production-grade MCP gateway, I wanted to see the control plane in action. Setting up a client highlighted just how much easier managing tools became compared to my old direct-server approach.
Step 1: Navigate to the MCP Gateway
In the Bifrost sidebar, I clicked MCP Gateway. A table appeared showing all registered MCP servers, giving me a clear overview of my environment. This centralized view immediately felt more organized than connecting tools individually.
Step 2: Add a New MCP Server
Click New MCP Server, which opened a creation form. Key details to provide:
- Name: Unique identifier (ASCII only, no spaces or hyphens)
- Connection Type: STDIO, HTTP, or SSE
- For STDIO, enter the command, arguments, and environment variables
- For HTTP/SSE, enter the connection URL
After filling it out, click Create, and the client connectes instantly.
Step 3: Viewing and Managing Connected Tools
Clicking on a client row opened the configuration sheet. Here, you can:
- See all discovered tools with descriptions and parameters
- Enable or disable tools with toggle switches
- Configure auto-execution for trusted tools
- Edit custom headers for HTTP/SSE connections
- View the full connection configuration as JSON
Step 4: Why This Matters
Before Bifrost, there was no easy way to:
- Control which tools the agent could call
- Track tool usage and inputs across multiple steps
- Safely auto-execute only trusted operations
Now, everything was centralized, observable, and controllable. This reinforced the lesson: production-grade MCP isn’t just exposing tools it’s about managing them safely and efficiently. You can find the full guide here.
Security Through Explicit Execution
One of the most important changes was explicit execution by default. Tools don’t just run because the model suggests them. Execution can require approval, and access can be filtered at a granular level.
This immediately reduced risk. Destructive operations stopped being accidental possibilities and became deliberate actions.
Code Mode: Fewer Tokens, Faster Execution
One of the biggest performance improvements came from Code Mode. Instead of having the model reason through tool orchestration in natural language every time, I could let it generate TypeScript to manage workflows.
The impact was measurable:
- Around 50% reduction in token usage
- Roughly 40% faster execution times
The agent spent less time “thinking” and more time doing.
Agent Mode for Trusted Tools
Not every tool needs human approval. With Agent Mode, trusted tools can auto-execute while sensitive ones remain gated. This made the agent feel responsive without sacrificing safety.
Read operations could flow freely. Write and delete operations stayed controlled.
Performance That Scales
A gateway only works if it stays out of the way. In practice, the added overhead stayed under 3ms, even at around 5,000 requests per second. That made the architecture viable for real workloads, not just controlled demos.
Observability You Can Actually Use
With a gateway in place, observability stopped being an afterthought. Every tool call generated audit logs. Metrics flowed into Prometheus. Distributed traces made it possible to follow an agent’s behavior across steps.
For the first time, I could answer basic operational questions confidently:
- What did the agent do?
- Why did it do it?
- How long did it take?
- Where did it fail?
What This Taught Me About MCP
MCP is a powerful foundation. It standardizes tool access in a way the ecosystem desperately needed. But building production agents taught me that protocols alone don’t make systems reliable.
Once agents move beyond experimentation, they need the same things every other piece of infrastructure needs:
- Control
- Visibility
- Safety
- Predictable performance
That’s what MCP gateways provide.
Bifrost didn’t invent this need but it shows what’s possible when the control plane is treated as a first-class concern instead of an afterthought.
Final Thoughts
If you’re experimenting with MCP today, it’s tempting to wire servers directly into your agent and move fast. That works until it doesn’t.
I learned that the hard way.
MCP is the beginning. But production-grade MCP requires a gateway. And gateways like Bifrost are quietly defining what that next layer should look like when it’s built correctly from the start.
Top comments (2)
This mirrors my experience pretty closely. MCP is great for demos, but once you start running agents continuously, you really feel the lack of control. The gateway comparison to API gateways is spot on.
Have you looked at doing something similar with LiteLLM or a custom proxy? Curious how you landed on Bifrost specifically.