You do not need Emcy Host to use Emcy Gateway.
That point matters because a lot of teams already have a runtime they like:
- a FastMCP server in Python
- a raw MCP SDK server in TypeScript
- a custom server generated from OpenAPI
- an internal MCP service already running in production
If your goal is MCP-compliant auth, public discovery, and downstream grant brokering, moving hosting and moving auth do not need to be the same project.
You can keep your runtime where it is and put Emcy Gateway in front of it.
The clean split
The model is simple:
- your runtime stays the runtime
- Emcy Gateway becomes the public MCP edge
Gateway owns:
- the public MCP URL
- protected-resource metadata
- authorization-server metadata
- DCR, CIMD, or preregistered client flows
- consent, grant brokering, and refresh
- logs, budgets, and policies
Your runtime keeps owning:
- tool definitions
- business logic
- framework choice
- infrastructure location
That is the right boundary for teams that already know how they want to run MCP.
[PLACEHOLDER - TODO - image caption: Emcy Gateway in front of a self-hosted FastMCP or raw MCP runtime, showing Gateway as the public auth edge and the runtime as the tool execution layer.]
Why this is useful
Plenty of teams want compliant MCP auth before they want a new hosting model.
They do not want to:
- replatform a runtime
- rewrite a Python server in another language
- give up FastMCP or a raw MCP SDK
- tie generator choice to auth choice
They just want one thing:
Put a clean MCP auth edge in front of what we already have.
That is exactly what Gateway is for.
A practical example
Say you already run a FastMCP server that talks to your Todo API.
You can keep that server where it is and let Emcy Gateway handle:
- the public URL your MCP client connects to
- the OAuth discovery documents
- the authorization flow
- the stored downstream grant
- the token refresh lifecycle
The FastMCP runtime only needs to honor the Gateway worker contract at the HTTP boundary.
In the current private worker path, that means:
- accept the shared worker secret header
- accept the forwarded downstream access token header
- execute the tool call normally
That is a much smaller change than rebuilding your whole runtime around Emcy-specific hosting.
This is also why Gateway is separate from Host
If Gateway required Host, it would not be a clean control-plane boundary.
It would just be an auth add-on for one deployment model.
That is not how modern MCP teams actually work.
Real teams mix:
- Emcy Host for some runtimes
- FastMCP for others
- custom runtimes where needed
Gateway should still sit cleanly in front of all of them.
Who this is for
Gateway without Host is a good fit when:
- you already have a working runtime
- you need MCP OAuth and discovery now
- you want logs, budgets, and policy at the public edge
- you want to adopt Emcy incrementally
It is also a strong path when one team owns runtime infra and another team owns product auth, embed, and governance.
The short version
If you already have an MCP runtime, the question is not:
Do we need to move to Emcy Host to use Emcy Gateway?
The question is:
Do we want Emcy to own the public auth and policy edge?
If the answer is yes, you can keep your runtime and add Gateway now.
Learn more
- Connect a self-hosted MCP runtime to Gateway
- Attach a Gateway to an MCP server
- The repo also includes a FastMCP reference at
docs/fastmcp-with-emcy-gateway.mdandexamples/FastMCP.Sample/README.md