An MCP gateway is a single, governed entry point between your AI agents and the business systems they use. Without one, every agent connects to every MCP server on its own terms. With one, everything passes through one layer that checks who is asking, decides what they may reach, curates the tools the model sees, logs every call and keeps the model replaceable. Most businesses do not need one yet. If you run three or more internal systems, more than one AI tool, a regulator who will ask for evidence, or a distribution model where partners' agents will come looking for you, you will benefit significantly from building and operating one. The benefit grows with every agent you add.
This guide is written by Fifty One Degrees, a UK and US AI consultancy for mid-market businesses. Our delivery model is Embed Over Advise: senior practitioners sit inside client teams and ship production systems rather than writing reports about them. I founded Fluro and scaled it to 4 million credit applications per year before a private equity exit. One lesson from that build applies directly here: a control point built early costs a fraction of one retrofitted after an incident. If MCP itself is new to you, start with our plain-English explainer on MCP servers.
The Short Answer
An MCP gateway is one governed door between every AI agent and every business system. Businesses with several systems, several agents, regulatory duties or agent-led distribution should build and operate one. Fifty One Degrees recommends buying the plumbing and owning the curated tool layer, because that layer is your business logic.
What is an MCP gateway?
An MCP server connects an AI application to one system: your CRM, your warehouse, your document store. An MCP gateway sits in front of all of them. To an agent, the gateway looks like a single MCP server. To your systems, it acts as one well-behaved client. Between the two, it handles identity, permissions, the catalogue of tools each user can see, logging and spend.
In our Claude implementation work we call the MCP server layer The MCP Bridge. It is Layer 3, Systems and Integration, of The Claude Readiness Stack, the three-layer sequence Fifty One Degrees uses to implement Claude. One bridge to one system is simple to govern. A gateway is what the bridge becomes when you have six bridges, four agents and an auditor.
| MCP server | MCP gateway | |
|---|---|---|
| Connects | One AI client to one system | Every agent to every approved server |
| Authentication | Per server, often a static key | Once, against your identity provider |
| Permissions | Set separately on each server | One policy across all systems |
| Audit trail | Separate logs, if any | One log of every prompt and tool call |
| Tools shown to the model | Everything the server exposes | A curated set per role and task |
| Model dependency | Configured per client | Any model behind one interface |
Why connecting agents directly stops working at scale
The first MCP connection feels like magic. The fifth creates a governance problem. According to Gartner, 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. Every one of those agents wants access to something.
MCP solved the N×M integration problem. At scale, it comes back as a governance problem. Set your own numbers below.
- Connections to govern
- 24
- Separate audit logs
- 6
- Places to set permissions
- 6
| Agents | Systems | Connected directly | Through a gateway |
|---|---|---|---|
| 2 | 3 | 6 | 5 |
| 4 | 6 | 24 | 10 |
| 8 | 12 | 96 | 20 |
Across Fifty One Degrees engagements, point-to-point MCP fails in three predictable ways:
- Nobody can answer the audit question. "Who asked what, with which data, and what came back?" When each server keeps its own logs, or none, there is no answer.
- The same question gets two answers. An agent pointed at raw tables keeps searching until it finds something plausible. Ask on Tuesday and again on Thursday, and you may get different numbers, both delivered with confidence.
- Context and cost bloat. Every tool definition a model sees costs tokens on every call. As reported by Tyk, Perplexity's CTO said in March 2026 that MCP tool definitions were consuming 72% of the company's context window. The updated MCP roadmap published in August 2026 introduces progressive discovery for the same reason: servers with hundreds of tools overwhelm the model and hurt tool selection.
Security makes the case sharper. The OWASP MCP Top 10, currently in beta, lists tool poisoning (MCP03) and shadow MCP servers (MCP09) among its critical risks. Tool poisoning hides instructions in tool descriptions that a model reads and a person rarely does. Shadow servers are the MCP version of shadow IT. Both are risks of servers nobody governs.
The protocol is catching up, but slowly. The official 2026 MCP roadmap names audit trails, SSO-integrated authentication, gateway behaviour and configuration portability as enterprise gaps, and calls enterprise readiness the least defined of its priorities. The July 2026 specification made enterprise-managed authorisation stable. The rest is still yours to solve. Your agents are running now, not when the standard is finished.
The five jobs an MCP gateway does
Here's one real question, followed from the moment it's asked to the moment it's answered.
A relationship manager asks: "Which of my clients have renewals due this quarter, and what changed on their accounts last month?"
- IdentityWith a gatewayThe gateway confirms who she is through the company's identity provider. Claude can see only the clients in her book.Without a gatewayThe agent uses a shared service key that can see every client in the firm.
- PolicyWith a gatewayThe request touches personal data, so those fields are masked and access is read-only.Without a gatewayWhatever the server returns goes straight to the model.
- CurationWith a gatewayClaude is offered two curated tools, "renewals due" and "account changes", each backed by a tested query.Without a gatewayClaude is shown every table the server exposes and explores until something looks plausible.
- Model and budgetWith a gatewayThe summary runs on the cheapest model that clears the quality bar, within her team's budget.Without a gatewayEvery call runs on the most expensive model, and nobody sees the cost per task.
- LoggingWith a gatewayOne record: who asked, which tools ran, what data was touched, what came back and what it cost.Without a gatewayFragments of logs across several servers, if any were kept.
- AnswerWith a gatewayShe gets the same answer she would get tomorrow, with the sources it used.Without a gatewayShe gets an answer. Ask again on Thursday and the numbers may differ.
1. Identity: one sign-in, user-scoped access
The gateway authenticates once against your identity provider, such as Microsoft Entra ID or Okta. Every agent then acts as the signed-in user. An agent should never see more than the person who asked, and when someone leaves, their AI access goes the same day as everything else.
2. Policy: data rules enforced, not just documented
Your data classification decides what can reach which model. The gateway enforces it: personal data guarded, read access before write access, write actions behind an approval step. In our AI operating model, the rules live in the operational layer. The gateway is where the tool layer is forced to obey them.
3. Curation: business concepts, not raw tables
This is the job most gateways skip and the one that matters most. Instead of exposing tables, expose documented endpoints for the concepts your business runs on: a customer, a case, a renewal, an alert. For the questions people ask every week, store a tested SQL recipe so the answer is the same tomorrow as it is today. It is the same principle as wrapping a core system rather than replacing it: you put a clean, stable interface in front of something messy.
Curation is also a cost lever. Fewer, better tools mean fewer tokens and fewer wasted calls. Most production AI systems pay two to five times more than they need to, and our guide to reducing AI token costs explains where the waste hides.
4. Observability: one log that feeds the loop
Every prompt, tool call and response is logged in one place and streamed into your security tooling. That gives you the audit trail. It also gives you the material for the feedback loop, the fifth layer of the AI operating model: which questions fail, which tools nobody uses, which teams need training.
5. Independence: models and vendors you can swap
Agents talk to the gateway, not to Salesforce, NetSuite or a single model provider directly. Change a model or a vendor and nothing else needs rebuilding. Fifty One Degrees calls the compounding cost of single-vendor dependency the Lock-In Tax. A gateway is one of the most practical ways to avoid paying it, and the natural place to set token budgets per user and per agent.
Which businesses benefit most from building one?
The return depends on five signals. Answer yes or no to each signal for your business.
You are regulated and will be asked for evidence. The FCA's approach to AI relies on existing frameworks such as the Consumer Duty and the Senior Managers and Certification Regime. Regulators will ask what your AI did, under whose authority. The gateway log is the evidence.
Your agents need three or more systems. CRM, ERP, warehouse and document store each have their own access model. Governing them one by one does not scale.
You run more than one AI tool or agent. Claude for colleagues, a custom agent for operations, ChatGPT in one team: without a gateway, each gets its own configuration of the same systems.
Your partners' and customers' agents will come looking for you. This is the outward-facing gateway, and the most underrated reason to build one. Brokers, platforms and comparison services will increasingly send agents rather than people. In lending, the lenders whose criteria and case status an agent can query will win the flow. The same logic applies to any business whose data is part of its product.
Your AI bill moves and you cannot explain why. If cost per task is invisible, the gateway is where you make it visible.
How the score works
How to read your score
- 0Switch on what you already haveUse the native connectors in your AI platform. A gateway would cost more to run than it saves today. Revisit when you add a third system or a second AI tool.Plain-English explainer on MCP servers
- 1Design for a gateway, start with one domainBuild your next MCP connection so it can sit behind a gateway later: identity through your identity provider, read-only by default, logs kept in one place.Vendor-agnostic AI enablement
- 2 to 5Build and operate oneStart read-only on one domain, wire identity first and curate the top 20 questions. The 90-day plan below shows the order.Book a call with Fifty One Degrees
- 4: YesPlan an outward-facing MCP server for partners' agents alongside the internal gateway.
- 1: YesPut logging and user-scoped access in the first release, not the second.
Two or more signals: build one. One signal: design for it and start with a single domain. None: switch on the off-the-shelf connectors your AI platform already offers. For a 40-person firm with one CRM, building a gateway is architecture theatre.
Case study: a gateway inside an FCA-regulated investment bank
The Situation: An FCA-regulated investment bank on the Microsoft stack was rolling out Claude firm-wide. It had strict information barriers between teams and a security function that would not accept agents querying raw databases.
The Approach: Fifty One Degrees embedded engineers alongside the bank's own team and ran two tracks in parallel. One delivered wins users could see quickly. The other built the foundations underneath them.
The Solution: A read-only MCP gateway inside the bank's own Microsoft environment, federated with Entra ID so every query runs as the signed-in user. Domain-specific MCP servers expose business concepts rather than tables, starting with the CRM. Information barriers are enforced at the gateway rather than left to each tool.
- Entra ID federation
- Every query runs as the signed-in user, so Claude sees what that person can see and nothing more.
- Information barriers
- Enforced once at the gateway, rather than relying on each tool to remember them.
- Read-only by default
- Agents can query but not change records. Writes come later, behind approval.
- One log
- Every prompt, tool call and response is recorded in one place for audit.
- Domain servers
- The CRM is exposed as business concepts, not raw tables. New domains reuse the same identity, policy and logging.
The Outcome: CRM data is live through Claude for a test group. Every connection to internal data passes through one governed door and one log. Each new domain plugs into the same identity, policy and logging rather than starting from scratch.
Build, buy or switch on?
| Option | Best for | What you own | Watch out for |
|---|---|---|---|
| Native connectors, switched on | One or two mainstream systems, such as Microsoft 365 | Configuration | Gaps in coverage; logs split by vendor |
| A commercial or open-source gateway product | Standard controls, fast | Policy settings | Generic tool exposure; one more vendor dependency |
| A gateway you build and operate, usually on open-source components | Regulated, multi-system or agent-led businesses | The curated tool layer, policy and logs | Needs a named owner and an operating rhythm |
Here is our view. The proxy is a commodity: Kong, Cloudflare, Docker, IBM's ContextForge and a crowd of open-source projects all route MCP traffic competently. The curated tool layer is not a commodity. Which endpoints exist, which recipes answer which questions, which roles see what: that is your business logic, written for machines. Buy the plumbing if it helps. Own the curation.
And note the word "operate". A gateway is a product, not a project. It needs an owner, a backlog and a monthly review of what the logs are telling you.
How to build an MCP gateway: the first 90 days
1. Inventory every AI connection you already have
List every MCP server, personal connector and API key in a script. You will find shadow servers. Bring them in or switch them off.
2. Pick one domain and start read-only
The CRM is usually the right first domain: high demand, well understood data, low risk when read-only.
3. Wire identity before you build tools
Federate with your identity provider on day one, so user-scoped access is built in rather than bolted on.
4. Curate the top 20 questions
Find the questions people actually ask and build documented endpoints and SQL recipes for them. Measure answer consistency and tokens per task before and after.
5. Log everything and review it monthly
Stream logs to your security tooling and hold a monthly review with a named owner. Route what you learn into training, tools and policy.
6. Add the next domain, and allow writes only behind approval
Each new domain reuses the same identity, policy and logging. Write actions arrive only with an approval step and an evaluation set.
At Fifty One Degrees, engagements follow a PoC → Beta → Release method, with a working proof of concept typically in 2 to 4 weeks. In our experience the engineering is the short part. Governance sign-off is the long pole, so start it on the first day, not the last.
Build the door before the crowd arrives
AI agents are moving from pilots to production, and each one wants access to your systems. Without a gateway, every connection is a separate risk, a separate log and a separate bill. With one, you get one door, one record and the freedom to change models. If two or more of the signals above apply to you, book a call with Fifty One Degrees or see how our vendor-agnostic AI enablement and Claude implementation work puts it into practice.