Getting Started

Connect a self-hosted MCP runtime to Gateway

Put Emcy Gateway in front of a self-hosted, FastMCP, or raw-SDK runtime without turning that runtime into an Emcy-specific server.

5 sections

You do not need Emcy Host to use Emcy Gateway.

If you already run your own MCP runtime, Gateway can still own the public OAuth and MCP edge while your runtime stays where it is.

The model#

Treat your runtime as a normal MCP server:

  • expose MCP over Streamable HTTP
  • keep framework-specific code inside the runtime
  • let Gateway own the public MCP URL, OAuth discovery, DCR/CIMD, grants, logs, budgets, and policies

For today's private worker path, the runtime still needs to accept the Gateway worker contract:

  • a shared worker secret header
  • a forwarded downstream access token header

The FastMCP sample shows the minimal version of that adapter.

[PLACEHOLDER - TODO - image caption: Emcy Gateway in front of a self-hosted MCP runtime, with OAuth discovery and grant brokering at the Gateway layer and tool execution staying in the runtime.]

Typical flow#

  1. Create a Gateway.
  2. Create or open the MCP server in Emcy.
  3. Attach the Gateway.
  4. Point the server runtime at your runtime URL.
  5. Configure the downstream OAuth settings on the Gateway profile.
  6. Test the public Gateway URL from Agent, Embed, or another MCP client.

When this is the right model#

Use Gateway without Host when:

  • you already run your runtime on your own infrastructure
  • you prefer FastMCP, a raw MCP SDK, or your own custom server
  • you want Emcy to own MCP auth, discovery, grant brokering, logs, budgets, and policies
  • you do not want to move runtime hosting first just to get compliant MCP auth

This is often the cleanest way to adopt Emcy incrementally.

FastMCP example#

The repo includes a FastMCP example here:

It keeps FastMCP as the runtime without requiring a separate Emcy Python SDK. The only Emcy-specific part is the small Gateway-facing worker contract at the HTTP boundary.