Remote MCP Servers: Connecting and Securing SaaS Servers Through One Gateway

TL;DR

• Remote MCP servers are SaaS-hosted Model Context Protocol servers that AI clients reach over HTTP or Server-Sent Events, instead of spawning them as local processes over STDIO.
• Wiring every team to every remote MCP server directly produces credential sprawl, no per-team access control, no audit trail, no rate limits, and context windows overrun by hundreds of tool definitions.
• A gateway in front of all remote MCP traffic gives you one MCP tool registry, one auth surface, per-team virtual keys, budgets, rate limits, tool filtering, and immutable audit logs.
• Bifrost, the open-source AI gateway, connects to remote MCP servers over HTTP and SSE, supports six MCP authentication modes, and enforces tool allow-lists per virtual key.
• Bifrost Code Mode cuts input tokens by up to 92.8% and estimated cost by up to 92.2% at 8-16 MCP servers, by exposing four meta-tools instead of hundreds of tool definitions.

Model Context Protocol (MCP) servers moved from local subprocesses to SaaS endpoints over the past year, and most engineering teams now consume at least a handful of remote MCP servers (GitHub, Notion, Sentry, Cloudflare, Linear, and a growing catalog on PulseMCP). Bifrost, the open-source AI gateway built by Maxim AI, is the enterprise control plane for that traffic: it connects to remote MCP servers over HTTP and SSE, applies one governance model across all of them, and re-exposes the aggregated tool set to agents and coding assistants through a single endpoint. This post explains what remote MCP servers are, why direct integrations create security and cost problems at scale, and how to consolidate remote MCP traffic behind one gateway.

What Is a Remote MCP Server?

A remote MCP server is a Model Context Protocol server hosted at a network endpoint, exposing tools, resources, and prompts to AI clients over HTTP or Server-Sent Events. Unlike a local MCP server, which the client spawns as a subprocess and communicates with over STDIO, a remote MCP server runs independently, is often multi-tenant, and is reached by URL. The specification is maintained by the Model Context Protocol project.

Remote MCP is the shape the ecosystem is standardizing on for SaaS integrations. Vendors ship one hosted endpoint any MCP client can point at (Claude Desktop, Cursor, ChatGPT, coding agents like Claude Code and Codex CLI), rather than a binary each customer runs locally. Bifrost supports all three MCP connection types, so remote and local servers sit behind one governance model.

Remote vs Local MCP Servers

Both flavors implement the same Model Context Protocol, but the transport and operational model differ in ways that matter at scale.

Remote MCP wins on distribution and freshness; local MCP wins on latency and on filesystem tools. Most production agent stacks run a mix. When a team standardizes on remote MCP for SaaS tools, the question stops being "does it work on my laptop" and becomes "who gets to call which tools, with which credential, under which budget."

Transports: SSE and Streamable HTTP

Remote MCP servers speak one of two transports over the network: legacy Server-Sent Events (SSE), or the newer streamable HTTP transport that folds bidirectional messaging into a single HTTP endpoint with an optional SSE upgrade. The streamable HTTP transport is the current MCP specification recommendation and is what most new remote servers implement. Bifrost supports both and treats them identically for governance and observability, so the choice of transport does not leak into policy configuration.

Session lifetime differs materially. An SSE connection is inherently bound to its open stream and is always sticky, while streamable HTTP can either hold a persistent upstream connection (needs_session_stickiness: true) or open a fresh connection per tool call. Per-call is safer for credential rotation; sticky is faster because the TCP and TLS handshake amortizes across many calls.

The Real Problem: Direct Connections Do Not Scale

The first remote MCP server a team connects looks easy: HTTP client library, vendor endpoint, OAuth token, tools appear in the agent's context. Problems begin at the second remote server and compound at the fifth.

Every agent, coding assistant, and internal service ends up wired directly to every remote MCP server it might need. The consequences mirror the shadow MCP server problem:

• Credential sprawl. Each team stores its own copy of the OAuth client secret or bearer token for each remote server. Rotating one credential requires finding every copy.
• No per-team access control. The vendor gives you one credential, and every internal caller uses it. There is no way to say "the support team's agent can call the ticket-lookup tool but not the account-deletion tool."
• No audit trail. The MCP server logs the request under one shared identity, so which internal user or agent made the call is unrecoverable.
• No rate limits or budgets. One misbehaving agent can burn the vendor's rate limit for the whole company in a single run, with no per-team spending cap.
• Context bloat. Each server contributes its tool definitions to every request. Five servers averaging 20 tools puts 100 tool schemas in every prompt before the model does any actual work, which is the hidden cost of connecting multiple MCP servers to one agent.

Every one of these shows up inside two quarters at any company consuming remote MCP servers from more than one team.

MCP Server Authentication

Remote MCP servers require an authentication choice per server: static bearer tokens, OAuth 2.0 with authorization code flow, per-user tokens on demand, or the caller's enterprise identity provider. A gateway has to handle all of them.

Bifrost supports six MCP authentication modes and lets you pick per upstream server:

Per-user OAuth is the mode that matters most for SaaS remote MCP: an agent calling GitHub or Notion on behalf of a specific engineer, using that engineer's own permissions rather than a shared service account. Bifrost stores the per-user credential against the caller's identity (virtual key, signed-in user, or session ID) and reuses it later, with automatic token refresh and PKCE. Token Exchange covers first-party internal MCP servers by exchanging the caller's IdP token every call rather than persisting a credential.

How an MCP Gateway Solves This

An MCP gateway is a control layer between AI clients and every MCP server, remote or local, those clients might use. All clients talk to the gateway; the gateway talks to the servers. It centralizes the tool registry, enforces authentication and access control, applies budgets and rate limits, records an audit trail, and re-exposes a single MCP endpoint upstream. This is the centralized control layer between AI agents and tool servers.

With and without a gateway, the same remote MCP fleet looks like this:

The pattern is the same shape as connecting multiple MCP servers through one gateway for local servers, applied to remote SaaS. Wins compound faster because the credentials are more sensitive and vendor rate limits are usually harder.

Reference architecture

+---------------------+   +-------------------+   +--------------------------+
| Coding agents       |   | Internal services |   | Chat / desktop clients   |
| (Claude Code, Codex,|   | (backends, jobs)  |   | (Claude Desktop, Cursor) |
|  Cursor)            |   |                   |   |                          |
+----------+----------+   +---------+---------+   +--------------+-----------+
           |                        |                            |
           |        OpenAI-compatible / MCP JSON-RPC             |
           v                        v                            v
+---------------------------------------------------------------------+
|                          Bifrost gateway                            |
|  Virtual keys | Budgets | Rate limits | Tool filtering | Audit logs |
|  MCP client (to upstream servers)   |   MCP server (to clients)     |
+------+------------+-------------+---------------+---------------+---+
       |            |             |               |               |
       v            v             v               v               v
   GitHub MCP   Notion MCP   Sentry MCP    Linear MCP     Internal MCP
   (per-user    (per-user    (headers)     (OAuth)        (token_exchange)
    OAuth)       OAuth)

Clients speak MCP or the OpenAI-compatible chat completions API to Bifrost. Bifrost speaks MCP to each remote server with the right auth type. Governance runs in the middle.

Connecting Remote MCP Servers Through Bifrost

Registering a remote MCP server with Bifrost is a single API call, or one form in the web UI. The shape is:

curl -X POST <http://localhost:8080/api/mcp/client> \
  -H "Content-Type: application/json" \
  -d '{
    "name": "notion",
    "connection_type": "http",
    "connection_string": "<https://mcp.notion.com/mcp>",
    "auth_type": "per_user_oauth",
    "tools_to_execute": ["*"]
  }'

The first time a caller invokes a Notion tool, Bifrost initiates the OAuth flow for that caller and stores the resulting token against their identity. Later calls reuse the token, with automatic refresh. The same shape works for SSE ("connection_type": "sse") and for shared credentials ("auth_type": "headers" with static values, or "auth_type": "oauth" for a shared client).

Bifrost then exposes the aggregated tool set through its own MCP endpoint: POST /mcp for JSON-RPC and GET /mcp for SSE, per Bifrost as an MCP gateway. Claude Desktop, Cursor, and any other MCP-compatible client point at that one endpoint and see every remote server's tools as if they were one server. Internal code can invoke tools directly via the tool execution endpoint, which uses the same authentication as chat completions.

Governance, Rate Limits, and Audit Logs at the Gateway

Virtual keys are the primary governance entity in Bifrost. Each virtual key represents a caller (a team, an agent, a service, a customer) and carries its own model allow-list, MCP tool allow-list, budget, and rate limits. All caller-side control flows through virtual keys.

Configure an MCP tool allow-list on a virtual key and only those tools are exposed on requests using that key, even if the underlying MCP server has hundreds more, through Bifrost's MCP tool filtering. The support team's key can be scoped to ["notion_read_page", "notion_search"] while the engineering team's gets ["notion_read_page", "notion_create_page", "notion_update_page"]. The vendor sees one OAuth client; the gateway enforces the difference. For larger fleets, MCP tool groups let you define curated tool bundles and attach them across virtual keys, teams, customers, users, providers, or API keys.

Budgets and rate limits attach to virtual keys, teams, and customers in a hierarchy under Bifrost's budget and rate limit system. A per-team budget caps how much a whole team can spend across every MCP call and every model inference in a period; a per-key rate limit throttles a specific agent. When a limit is hit, the request is rejected at the gateway before the vendor's rate limit is touched.

Every administrative action, and in enterprise deployments every tool call, is written to an immutable audit log. Entries can be HMAC-signed, retained for a configurable period, filtered by action or outcome in the dashboard, and archived to S3 or GCS in time-windowed JSONL for SOC 2, GDPR, HIPAA, and ISO 27001 review. The identity on each entry is the virtual key (and for per-user auth, the end-user), so "who called which tool with which arguments" has a first-class answer.

Code Mode: Token-Efficient Remote MCP Invocation

The economics of remote MCP break at scale not because the calls are expensive, but because the tool definitions are. Bifrost Code Mode exposes four meta-tools to the model instead of the raw catalog: listToolFiles, readToolFile, getToolDocs, executeToolCode. The model uses those to write short Python (Starlark) that orchestrates the real tools in a sandbox; only the code and its results flow through the context window.

Measured across three controlled rounds with increasing MCP footprint:

Full methodology is in the MCP Gateway benchmark writeup and in the analysis of tracking per-tool costs across MCP servers. For any deployment with more than a handful of remote MCP servers, Code Mode is the difference between a workable per-request context and one dominated by tool schemas.

Coding Agents and Enterprise Deployments

Coding agents multiply the remote-MCP problem because each developer's editor is a client. Wiring Claude Code, Codex CLI, Cursor, and other CLI agents directly at every remote MCP server across an engineering org repeats the credential-sprawl and audit-gap problems at developer-per-server scale. Pointing every coding agent at Bifrost, and connecting Bifrost to the remote MCP servers, moves the problem into one place. The same architecture applies to governing MCP servers inside Claude Code and to connecting Claude Code to multiple MCP servers through one gateway.

For regulated industries, Bifrost Enterprise adds role-based access control and data access control over MCP configuration.

In-VPC deployments let remote MCP traffic egress from an isolated environment under a single network boundary, and guardrails apply content and secrets policies to MCP tool arguments and responses before they reach the model.

Frequently Asked Questions

What is a MCP remote?

A MCP remote is a Model Context Protocol server hosted at a URL and reached by MCP clients over HTTP or Server-Sent Events. It contrasts with a local MCP server, which the client spawns as a subprocess and talks to over STDIO. Remote MCP is the shape SaaS vendors ship, since one hosted endpoint can serve every customer.

What is the difference between a remote MCP server and a local MCP server?

A remote MCP server runs at a URL and is reached over HTTP or SSE; a local MCP server runs as a subprocess on the client's machine over STDIO. Remote servers are easier to distribute but require network authentication and add round-trip latency. Local servers are lower latency and can touch the user's filesystem, but must be installed on every machine.

How to make a remote MCP server?

Implement the MCP JSON-RPC methods (tools/list, tools/call, resources/list, and so on) behind an HTTP endpoint, add an authentication layer (OAuth 2.0 or bearer headers), and expose a /mcp route that accepts JSON-RPC over POST and optionally an SSE stream. The MCP specification is the source of truth for message shapes.

Can I host a MCP server?

Yes. Any HTTP-capable runtime can host one: a container behind a load balancer, a serverless function, or a long-running service. Bifrost also lets you expose all your connected MCP tools as a single MCP server, so external clients get one endpoint even when many upstream servers are aggregated behind it.

How does Bifrost handle authentication for remote MCP servers?

Bifrost supports six MCP authentication modes: none, headers for shared bearer tokens, per_user_headers for per-user keys, oauth for a shared OAuth 2.0 client with token refresh, per_user_oauth for per-user OAuth (Notion, GitHub, Sentry), and token_exchange for internal servers that trust an enterprise IdP. The auth type is picked per upstream MCP server.

Can one gateway front both remote and local MCP servers?

Yes. Bifrost treats STDIO, HTTP, and SSE as three connection types and applies the same governance to all of them. One gateway can front an internal filesystem server over STDIO, a Notion remote server over HTTP with per-user OAuth, and an internal analytics server over SSE with shared headers, and expose the union through one endpoint.

How much overhead does routing through a gateway add?

Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks. For remote MCP calls, that is negligible next to the network round-trip to the upstream server, which typically runs tens to hundreds of milliseconds.

Getting Started with Bifrost

Consolidating remote MCP servers behind one gateway turns MCP from a per-developer experiment into a platform the whole company can rely on. Bifrost registers each remote server once, picks the right authentication mode, filters tools per virtual key, applies budgets and rate limits per team, records an audit trail of every tool call, and cuts input-token costs by up to 92.8% with Code Mode at scale. Explore the MCP Gateway resource hub or book a demo with the Bifrost team.