Skip to main content
External servers are available on Developer and Enterprise.
External servers connect MCP servers that run outside FastMCP Gateway through its serving gateway. You keep the remote server in the runtime, network, and release process it already uses. FastMCP Gateway gives that server a managed entry, a protected MCP endpoint, access policies, request logs, and a place in the same catalog as hosted servers. Use an external server when the server already exists, already has an owner, or must stay where it runs today, but clients and administrators still need the benefits of a shared FastMCP Gateway access layer. The remote endpoint must accept HTTPS connections initiated by FastMCP Gateway. If it uses an IP allowlist, see Networking. FastMCP Gateway maintains global connectors for supported provider-hosted MCP servers. Select one to use its preconfigured remote endpoint, or create an organization connector for another endpoint.

Adopt without redeploying

Register an existing MCP endpoint instead of moving its code into a FastMCP Gateway hosted server first.

Give clients one front door

Let clients call a FastMCP Gateway endpoint while FastMCP Gateway handles access checks and forwards accepted traffic to the remote server.

Keep remote credentials private

When the remote endpoint requires authentication, store its credentials in FastMCP Gateway so clients do not need direct access to them.

Make remote traffic visible

Use FastMCP Gateway request logs, clients, and users to understand how the external server is used through FastMCP Gateway.

​
When to use an external server

Choose an external server when the runtime should stay outside FastMCP Gateway, but MCP access should be managed through FastMCP Gateway. If you want FastMCP Gateway to build and run the server code, use a hosted server. If you want one endpoint made from selected capabilities across multiple servers, use a remix server.

​
User-visible contract

To clients, an external server behaves like a FastMCP Gateway MCP server. The client connects to the FastMCP Gateway endpoint, authenticates to FastMCP Gateway when required, and discovers the capabilities that FastMCP Gateway has learned from the remote server. FastMCP Gateway does not change the remote server’s tool behavior. It governs the path to the server, records gateway activity, and forwards accepted MCP requests to the remote endpoint you configured.
If a request is rejected before it reaches the remote server, start with FastMCP Gateway request logs. If the remote server receives the request and fails, debug the remote runtime where that server is operated.

​
Ownership boundary

External servers intentionally split platform responsibility from remote runtime responsibility. This boundary is the main reason to choose an external server: FastMCP Gateway becomes the access and observability layer for MCP traffic without taking ownership of the remote server’s runtime.

​
Request flow

1

Client calls the FastMCP Gateway endpoint

The MCP client uses the FastMCP Gateway server URL. If the server is protected, the client authenticates to FastMCP Gateway.
2

FastMCP Gateway checks access

The gateway identifies the caller and applies the external server’s access settings, including capability policies when they are configured.
3

FastMCP Gateway forwards to the remote server

FastMCP Gateway sends the MCP request to the configured remote endpoint. It injects the configured OAuth token or API-key headers. When no authentication is selected, it removes the caller’s Authorization header.
4

The remote server handles the MCP call

The remote server executes the tool, resource, prompt, or template request and returns the MCP response.
5

FastMCP Gateway returns the response

FastMCP Gateway returns the remote response to the client and records gateway observability for the request.

​
Authentication model

The MCP client signs in to the FastMCP Gateway endpoint first. FastMCP Gateway then presents a separate OAuth token or API key to the remote MCP server, unless the remote server accepts anonymous requests. The external server’s Connection page shows the current remote credential status. For a public remote server, it shows that no authentication is required. Users can authorize OAuth, add or revoke personal header credentials, and repair an expired credential there. Server administrators can manage shared header credentials and their injection formats. When the remote provider requires a pre-registered OAuth client, register FastMCP Gateway’s callback URL exactly as https://horizon.prefect.io/oauth/external/callback. Providers that support Dynamic Client Registration receive the same callback URL during registration. For OAuth discovery, Dynamic Client Registration, manual client fields, API-key header formatting, and the complete setup flow, see External authentication.

​
Register an external server

1

Choose external server

In FastMCP Gateway, create a server and choose the external server type.
2

Enter the remote MCP URL

Provide the HTTP endpoint FastMCP Gateway should call when clients use the server. The endpoint must be reachable by FastMCP Gateway and speak a supported MCP HTTP transport.
3

Configure remote authentication

Choose no authentication, OAuth, or API-key authentication for the remote server. For API-key authentication, add each required header and enter its literal or encrypted value in the same form. Select no authentication only when the endpoint accepts anonymous requests.
4

Inspect capabilities

FastMCP Gateway connects to the server, performs MCP discovery, and stores the metadata it will show in the dashboard and use for access policy setup.
5

Grant access

Configure server access and capability policies for the users and service accounts that should use the external server.

​
How discovery works

When you register or refresh an external server, FastMCP Gateway captures a snapshot of the remote server’s MCP metadata. FastMCP Gateway initializes an MCP session with the remote endpoint, then asks for tools, prompts, and resources. Those list requests run independently, so one failed list method does not automatically discard metadata returned by the others. FastMCP Gateway stores that snapshot with the external server metadata. The snapshot is used for the dashboard, client setup surfaces, remix composition, and capability policy setup. If initialization fails, metadata capture fails. If every list response is empty or unavailable, metadata capture fails because FastMCP Gateway cannot tell whether the server has no useful capabilities or discovery did not work. If at least one list response succeeds, FastMCP Gateway can store the metadata it received and leave the missing capability types empty. To refresh metadata, open the external server’s Connection page and select Sync capabilities. Each attempt appears in Sync history. When a sync fails, its row shows the sync error, and the previous metadata stays in place. Runtime traffic still goes to the remote server. When a client calls tools/list, prompts/list, or resources/list through the FastMCP Gateway endpoint, FastMCP Gateway asks the remote server for the current list and applies access filtering before returning the response. Playground, ChatMCP, and external clients still depend on the runtime endpoint being able to reach the remote server.
If capability policy does not filter it, a newly added remote tool can appear in a runtime tools/list response before the dashboard snapshot has been refreshed. If capability policy is configured, refresh the external server metadata and update policy before expecting the new tool to appear.

​
Metadata and policy lifecycle

Treat remote metadata changes as compatibility changes. If the remote server adds, removes, renames, or changes a capability schema, refresh discovery and review policies before relying on the new shape in production clients.

​
List and call failure behavior

An external server has one remote backend, so list behavior depends on that backend’s response.

​
Before clients use the server

An external server is ready for client use when FastMCP Gateway can discover it, use the expected remote authentication mode, and enforce the access boundary you expect. Check the server from FastMCP Gateway before updating client configuration:
  • Discovery shows the tools, resources, and prompts clients should see.
  • Playground can call representative capabilities through the FastMCP Gateway endpoint.
  • A caller without access receives a gateway denial instead of reaching the remote server.
  • Request logs show forwarded calls with the expected client and user metadata.
  • The team that owns the remote server can debug runtime errors outside FastMCP Gateway.
These checks matter because there are two systems in the request path. FastMCP Gateway can prove the gateway accepted, denied, or forwarded a request. The remote owner still needs enough runtime visibility to explain what happened after forwarding.

​
Troubleshooting

Start with where the request stopped. FastMCP Gateway request logs show whether the gateway denied, forwarded, or received an error from the remote server. If forwarding succeeded, debug the remote runtime.
Confirm the remote URL is reachable from FastMCP Gateway, uses a supported MCP HTTP transport, initializes successfully, and returns at least one non-empty capability list during discovery. If the remote endpoint requires authentication, confirm the remote credential configured in FastMCP Gateway is current. A failed sync shows its error in Sync history on the Connection page.
The client did not authenticate to FastMCP Gateway successfully. Check the client credential and the external server’s FastMCP Gateway access mode.
The caller authenticated to FastMCP Gateway, but server access or capability policy does not allow the requested operation. Review Authorization.
Allow popups for FastMCP Gateway, then retry Authorize with OAuth. If the popup opens but returns an error, restart the OAuth flow so FastMCP Gateway can create a fresh authorization request.
The provider accepted the sign-in but rejected FastMCP Gateway’s token request. The error page names the likely cause. A server administrator verifies the OAuth client ID, client secret, token endpoint authentication method, registered callback URL, and scopes. See External authentication.
The client-to-FastMCP Gateway credential is valid, but the FastMCP Gateway-to-remote credential is missing, expired, revoked, or invalid. Reauthorize with OAuth or update the stored header credentials for the external server.
Check the remote credential configured in FastMCP Gateway, then inspect the remote server’s runtime logs. FastMCP Gateway can show that forwarding occurred, but the remote server owns the application response.
Confirm Playground is connected to the intended target, then refresh its live capability list. Refresh external server metadata separately when the dashboard or capability policy setup is stale.
Gateway forwarding succeeded. Inspect the remote server’s application logs and the systems that remote server calls while handling the request.

Gateway

Learn how FastMCP Gateway routes and protects MCP traffic.

External authentication

Configure whether the remote server needs a downstream credential and how FastMCP Gateway supplies it.

Remix servers

Aggregate selected capabilities from multiple MCP backends behind one server.

Networking

Configure reachability and source-address allowlisting for remote endpoints.