Open-Source MCP Gateways: Compare Routing and Access Controls
An MCP gateway sits between AI clients and the servers they call, routing requests, enforcing access rules, and centralizing audit logs. Several open-source options exist. This guide explains what to look for, compares the main approaches, and shows where fenbs fits as the shared work record behind the gateway.
Updated 5 min read
An MCP gateway is a server that sits in front of one or more MCP tool servers. Instead of each AI client connecting directly to every tool, the client connects to the gateway, which routes the call to the right server, applies access rules, and logs what happened. An open-source gateway lets you run that routing layer on your own infrastructure, inspect the code, and adjust the rules.
Choosing a gateway is a decision that affects every AI app and every tool in the workflow. Tools like fenbs connect directly to AI apps via MCP and provide a shared work record the right gateway choices protect. Before committing to one, it is worth understanding what a gateway actually does, which open-source options exist, and what to check in each.
What an MCP gateway does
Without a gateway, each AI client connects to each tool server separately. That works at small scale, but as the number of tools and clients grows, the connections multiply and become harder to manage. A gateway centralizes the connections:
- Routing: the gateway receives a tool call and forwards it to the right server.
- Access control: the gateway can deny certain calls for certain clients, or restrict which tools a client can see.
- Authentication: instead of each server managing its own tokens, the gateway validates requests centrally.
- Audit logging: all calls pass through one point, so you have a single audit log rather than separate logs on each server.
- Rate limiting: the gateway can cap how many calls a client makes, reducing load on downstream servers.
Not every open-source gateway implements all of these. Check the feature list against what your workflow actually requires before choosing.
What to look for in an open-source MCP gateway
Open-source gateways span a wide range of maturity. Some are production-ready with active maintenance; others are proofs of concept. Use these criteria when evaluating one:
- MCP spec version: does it support the version your clients and servers use? Check the MCP specification at modelcontextprotocol.io for the current version.
- Access control model: can you restrict which tools a specific client can call, or which inputs are allowed?
- Authentication support: does it verify the caller's identity, or does it pass calls through without checking?
- Logging: does it produce structured logs you can query, or plain text only?
- Last commit date: a gateway that has not been updated in many months may have fallen behind the spec.
- Issue tracker health: are open issues being addressed? Many unresolved issues about core features are a warning sign.
- License: check that the license allows your intended use, especially for commercial deployments.
Open-source MCP gateway approaches compared
The open-source options fall into a few broad approaches. Because the space is moving quickly and specific projects change rapidly, the comparison below describes the approaches rather than named versions. Check the current repositories and their documentation before committing to any one of them.
| Approach | What it does well | What to check |
|---|---|---|
| Standalone proxy gateway | Simple request forwarding; easy to self-host; good for adding a log layer to existing servers. | Access control is usually limited to allow/deny by server; does not restrict by tool or input. |
| Framework-integrated gateway | Embedded in agent frameworks; benefits from the framework's auth and config systems. | Tied to one framework; switching the agent framework means switching the gateway. |
| Policy-engine gateway | Fine-grained rules: restrict by client, tool, input value, or time of day; structured audit logs. | More complex to configure; requires understanding a policy DSL or rule format. |
| Aggregator gateway | Merges multiple MCP servers behind one endpoint; clients see a single tool list. | Tool name collisions across servers must be managed; check how the gateway handles them. |
| fenbs | Shared work record — projects, tasks, Decisions and rules, and Where we left off — accessible to any connected AI app over MCP. | fenbs is not a gateway; it is an MCP server providing a work record. Use a gateway in front of fenbs when you need centralized access control over all your MCP connections. |
Record gateway access decisions where every assistant reads them
When you decide which tools a team's AI apps may call, record that decision in fenbs Decisions and rules. Every connected assistant reads the rules first. If a gateway blocks a call the team agreed was off-limits, the decision is already in the work record rather than in a Slack message nobody can find. Free to start.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Security considerations
An MCP gateway reduces the attack surface only if it is configured correctly. A permissive gateway that forwards all calls without checking the caller is less secure than direct connections — it adds a single point of failure without adding access control. The MCP gateway security guide covers common misconfigurations in detail.
A gateway is also not a substitute for access control on each downstream server. If a server trusts all requests from the gateway without checking the original caller's identity, a compromise of the gateway gives an attacker access to all the connected servers. Ideally the gateway forwards identity claims that each server can verify independently.
Where fenbs fits
fenbs is an MCP server, not an MCP gateway. It provides a work record — projects, tasks, decisions, and progress — to any AI app that connects. A gateway can sit in front of fenbs along with your other MCP servers, applying access control to all of them from one place.
The open-source project management guide covers the broader category of open tools for managing work alongside AI. The MCP apps guide lists the AI clients that support MCP connections.
How to do this with fenbs
- Create a free account and add the project that requires gateway-controlled AI access.
- Decide which AI apps may connect to fenbs and with what access. Write those decisions in Decisions and rules, with the person who decided them.
- Connect your chosen AI apps from Integrations using the browser sign-in flow.
- If you are adding a gateway: install and configure it to forward MCP calls to fenbs and your other servers, applying the access rules you have decided on.
- Record any changes to gateway rules in Decisions and rules so the team knows what was decided and why.