One of the most common questions we hear is some version of this:
We have two MCP servers. They both call the same downstream API. Do we need two Gateways just because each server needs different scopes?
Usually, no.
If those servers share the same downstream auth boundary, one Emcy Gateway can sit in front of both of them.
The key is understanding what is actually shared, and what is allowed to vary.
The right boundary
The clean product boundary is:
- build however you want
@emcy/openapi-to-mcp- FastMCP
- raw MCP SDKs
- put Emcy Gateway in front of it
- public MCP URL
- OAuth discovery
- DCR, CIMD, or preregistered client handling
- grant brokering and refresh
- logs, budgets, and policies
- use Embed on top when you want the agent inside your product
That means Gateway should be reused whenever the auth boundary is the same.
What a shared Gateway actually means
When multiple MCP servers share one Gateway, the shared pieces are:
- authorization server
- downstream client ID
- downstream resource or audience
- identity resolution rules
What does not need to be identical is the exact scope request on every authorization flow.
The working pattern is:
- Configure the Gateway with the full allowed scope set.
- Attach that same Gateway to multiple MCP servers.
- Let each server or client flow request only the subset it actually needs.
So yes, two MCP servers can share one Gateway and still ask for different scopes.
The important nuance is that those requested scopes must still be subsets of the Gateway's allowed scope set.
A concrete example
Assume one SaaS product API exposes both support and operations capabilities.
You decide to publish two MCP servers:
support-assistantops-console
Both call the same downstream API and both use the same OAuth provider.
Your shared Gateway might allow:
tickets.read tickets.write accounts.read admin.read
Then the actual authorization requests can stay narrower:
support-assistantasks fortickets.read accounts.readops-consoleasks fortickets.write admin.read
That gives you:
- one public auth edge to manage
- one discovery surface
- one grant-brokering layer
- one place for logs and policy
- less duplicated config
without forcing both servers to always request the same scope list.
[PLACEHOLDER - TODO - image caption: Shared Emcy Gateway attached to two MCP servers, each with a different requested scope subset.]
Why this matters
Without this model, teams tend to do one of two bad things:
Bad option 1: duplicate Gateways unnecessarily
They create nearly identical Gateways just because one server is read-only and the other is admin-capable.
That creates more config drift, more mental overhead, and more places to debug auth.
Bad option 2: request every scope everywhere
They keep one shared auth surface, but every MCP server ends up asking for the full union of scopes every time.
That technically works, but it is worse product design and worse security hygiene.
The better pattern is one shared Gateway with minimal scope requests per surface.
When you should create a second Gateway
Do not force multiple servers through one Gateway if the auth boundary is genuinely different.
Create another Gateway when you need a different:
- client ID
- resource or audience
- authorization server
- identity mapping strategy
Those are not just scope differences. They are different auth profiles.
How this fits Emcy's model
This is exactly why we separate Host from Gateway.
Host is about where the runtime runs.
Gateway is about the public auth and policy edge in front of that runtime.
So you can:
- run one server on Emcy Host
- run another with FastMCP on your own infra
- attach both to the same Gateway
as long as they share the same auth boundary.
The practical rule of thumb
Use one Gateway when you are saying:
These MCP servers are different surfaces on the same authenticated system.
Use two Gateways when you are saying:
These servers cross different auth boundaries and should be treated separately.