Cloudflare MCP Portal Guide: Combine Remote Tools, Configure Authentication, and Manage the Portal with AI

Multiple remote MCP servers can be combined into a single connection through a Cloudflare MCP portal. Clients only need the portal URL; services such as forums and website backends still run on their original servers. The portal handles forwarding, access control, and tool management.

I connected both the forum MCP, based on Discourse's built-in MCP, and my custom website system MCP to the same portal. Through this entry point, I verified the logged-in forum identity and the website's build status. Below are the configuration steps, the differences in authentication, and the workflow for managing the portal with AI. All example domains and email addresses are placeholders.

What the portal actually hosts

The portal hosts a unified access point, not the backend MCP programs.

AI 客户端
  └─ Cloudflare MCP 门户
       ├─ 论坛 MCP → 论坛
       └─ 自建官网系统 MCP → 网站内容管理

When adding a remote MCP server, enter its existing HTTP URL. The portal does not determine whether the backend runs on a VPS, in a container, or on Workers. Entering source code, a Docker image, or an npx command into the portal will not make it run automatically on Cloudflare.

If you want to move the MCP program itself to Cloudflare, you need to deploy a Workers-compatible service separately, then connect it to the portal.

Which MCP servers can be combined

Existing service	How to connect
Forum or website backend with built-in remote HTTP MCP	Enter the full MCP endpoint and configure authentication
Third-party service offering remote MCP	Check its transport, OAuth, and callback requirements before connecting
Self-hosted Streamable HTTP / SSE MCP	The service must be reachable by the portal; configure its required authentication
MCP that only supports local stdio	Cannot be added directly; convert it into a remote service first
Backend with only a REST API and no MCP	Requires an MCP adapter layer; the portal does not automatically turn REST APIs into tools
Service listening only on local localhost	Cannot be used directly as an upstream for a cloud portal

For example, a service started locally with npx @dokploy/mcp still runs the MCP process locally, even if it calls a remote Dokploy panel. This differs from a website whose backend already provides /mcp.

On the Dokploy panel I checked, both /mcp and /api/mcp returned 404. The official standalone MCP package passed local testing in HTTP mode, but it still requires a separately running service, so I did not add it to the portal. To determine whether MCP is built in, check your own version and actual endpoints rather than relying on the software's name.

Authentication has two layers

The client logs in to the portal

Users first log in to the portal through Cloudflare Access. Access can be restricted with rules based on email addresses, identity providers, and other criteria.

Desktop MCP clients use Managed OAuth to obtain access credentials. This step logs in to the portal; it does not give AI permission to manage your Cloudflare account.

Both the portal and each upstream MCP server need their own Access policies. Configuring Allow only for the portal may let you log in without seeing any upstream tools.

The portal connects to upstream servers

Upstream servers have their own authentication requirements, which cannot be skipped just because the user has logged in to the portal.

Upstream authentication	How the portal uses it
Bearer Token	Stores the Token in the server configuration and sends it with requests
Custom request headers	Configures the static authentication headers required by the service
OAuth automatic registration	Automatically registers and authorizes a client if the upstream supports DCR
OAuth manual registration	If the upstream has no DCR, uses a preregistered client with configured endpoints, Client ID, and callback
No authentication	The portal can connect, but the original upstream URL may still be directly accessible

My custom website system MCP uses a Bearer Token. The Token is configured on the portal, so I do not need to enter it again on my computer. The forum MCP uses OAuth, so forum authorization is still required after logging in to the portal.

Protecting the portal entry point with Access does not automatically protect the original backend URL. Who can connect directly to the backend is still determined by its existing authentication. Do not remove backend authentication just to make connecting to the portal easier.

Connecting the forum MCP with OAuth

The forum here runs Discourse. I connected its built-in remote MCP endpoint, not a standalone MCP package running on my computer through npx. The built-in endpoint connects directly to the forum. Available tools depend on the current Discourse version, the capabilities enabled in the admin settings, and the authorized account's permissions.

The built-in forum MCP I used did not provide a DCR registration endpoint, so Cloudflare's automatic registration flow failed. Even with the correct MCP URL, you may see “Error registering MCP server.” Check the OAuth metadata next rather than repeatedly changing the URL. Other forum services need to be checked individually for DCR support.

Use a preregistered forum client when connecting:

1. Register an OAuth client in the forum admin panel specifically for the portal.
2. Add the callback URL the portal actually uses.
3. Select manual OAuth for the Cloudflare upstream and enter the authorization endpoint, Token endpoint, Client ID, and scopes.
4. Keep Require user auth enabled so users complete forum authorization through their client.
5. After logging in, call the current-user tool to confirm which account is actually linked.

The callback used in my API configuration was:

https://mcp.example.com/servers-callback

Cloudflare also supports a shared callback, and the actual URL may differ depending on the configuration route. Read the value displayed in the dashboard or the effective redirect URI returned by the API, and register the full URL. Do not copy a callback and assume it applies to every portal.

My forum required token_endpoint_auth_method: none, and the authorization request needed the correct resource. Cloudflare's manual OAuth API also required a nonempty client_secret. I kept none in the configuration and used a random placeholder value to satisfy that field's validation, then successfully tested authorization and tool calls. This is a verified, specific combination, not a universal configuration for all OAuth services; services that genuinely require a secret must use the secret they issue.

Manual OAuth requires users to authorize the upstream service. I did not verify whether authorization is automatically reused on a different computer or client, so I cannot promise that one authorization will permanently cover all devices. Do not copy OAuth Tokens to synchronize logins either.

Add just one connection to the client

For clients that accept mcpServers JSON configuration:

{
  "mcpServers": {
    "remote-mcp": {
      "type": "http",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Example Codex configuration:

[mcp_servers.remote-mcp]
url = "https://mcp.example.com/mcp"

Then authorize through the client's OAuth login flow. The URL must include /mcp, and the client must support remote MCP and the corresponding OAuth flow.

Verify the new connection before removing the original direct connections to avoid duplicate tools. If you use a configuration manager such as CC Switch, also check its saved MCP records; changing only the client file may allow the old configuration to be synced back later.

During cleanup, I kept the archived API credentials because scheduled forum tasks and website publishing scripts may still use the REST API. Removing an MCP connection does not mean deleting credential files, revoking all authorizations, or stopping backend services.

How tools are named after merging

In standard mode, portal tools can include an upstream server prefix. Here are generic examples:

forum-mcp_discourse_current_user_get
website-mcp_build_status

The client may also add its own connection-name prefix. For example:

mcp__remote-mcp__forum-mcp_discourse_current_user_get
mcp__remote-mcp__website-mcp_build_status

Here, forum-mcp refers to the forum MCP, and website-mcp refers to my custom website system MCP. These are example names, not names every service must use.

Use the names actually loaded by your client. The portal also supports tool aliases, description changes, and enabling or disabling tools, so you can expose only the tools you need without modifying backend source code.

How to let AI modify the portal configuration

Managing the portal requires another connection: Cloudflare's official API MCP.

{
  "mcpServers": {
    "cloudflare-api": {
      "type": "http",
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

Complete the Cloudflare OAuth login in your client, selecting the account and required permissions. AI can then use the official MCP to look up API definitions, read existing resources, and call APIs to modify the configuration. The official API MCP uses a search / execute model, so there is no need to load every Cloudflare API as a separate tool.

Do not confuse the two connections:

• cloudflare-api manages Cloudflare resources and can modify configurations such as DNS and Access, depending on the permissions granted.
• Your own remote-mcp calls business tools for the forum, website, and other services.

You can give AI a task like this:

First, read the account's existing portals, DNS records, Access policies, and upstream servers. Add the forum MCP and the MCP for my self-hosted official website system to a unified portal at mcp.example.com, allowing only me@example.com. Keep the existing connections and list the scope of changes before making any modifications. Afterward, read back the configuration and verify each upstream by calling a read-only tool.

Since this involves configuration changes, the AI must check the current API schema first rather than guess field names. Before modifying an existing resource, it must read the full configuration and preserve all other fields. Login and upstream authorization must be completed by the account owner; the AI must not bypass authorization.

When creating a portal through the API, you also need to create a separate proxied DNS record:

类型：CNAME
名称：mcp.example.com
目标：gateway.agents.cloudflare.com
Proxy：开启

Do not overwrite a subdomain already in use, or temporarily set Everyone just for testing. Tests should at least cover: the authorized user can call tools, unauthenticated requests are blocked, the upstream identity is correct, and old connections can be removed once the new connections work.

Use Code Mode When You Have Many Tools

Consolidating connections does not automatically reduce the number of tool definitions. If you have many tools, you can enable Code Mode on the portal to expose upstream tools through two entry points for search and execution:

portal_codemode_search
portal_codemode_execute

The AI first searches for the tools it needs, then writes JavaScript to call them. The code runs in an isolated environment. Policies such as opt-in are supported; whether to enable it should depend on tests of client compatibility and actual model performance. For this test, I verified the forum and website in standard tool mode, so Code Mode is not a tested feature here.

Authentication for Automated Tasks

Bots that cannot easily open a browser can use an Access Service Token, but Service Auth policies must be configured for both the portal and each upstream.

A service token cannot complete upstream OAuth on a user's behalf. Upstreams that require per-user authorization cannot be used directly by these sessions. Upstreams that support this approach need to disable Require user auth and use administrator credentials. Manual OAuth upstreams require per-user authentication and should not be forced into a shared administrator mode.

Desktop user login and unattended bot calls therefore need separate designs. A single portal URL does not make them interchangeable.

Benefits and Limitations

A unified entry point reduces scattered connection configuration: when adding an upstream, you can update the portal instead of copying a set of server-side Tokens to every computer. Tool enablement, access policies, and logs can also be managed centrally.

OAuth upstreams still enforce their own account permissions. Whether users need to authorize again after switching clients must be verified through the actual workflow. Skill synchronization, connection configuration synchronization, and login state synchronization are also separate concerns.

The portal adds another layer of request forwarding, so it cannot guarantee better speed or stability in every network environment. Backend outages, expired Tokens, and invalid tool schemas do not automatically disappear just because you use a portal. Some tools can post, delete content, or modify servers; successful portal login does not mean the user has approved every write operation.

What I verified in this test: the forum MCP and the MCP for my self-hosted official website system share one portal, the forum's current-user tool returns the expected identity, and website build queries work correctly—all without deploying an extra aggregation container. I did not force local-process-only MCPs into this setup; they retain their original usage boundaries.

References

• Cloudflare MCP portals：https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/
• Managed OAuth：https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/managed-oauth/
• Cloudflare official API MCP：https://github.com/cloudflare/mcp
• Portal Service Token：https://developers.cloudflare.com/changelog/post/2026-06-26-mcp-portal-service-tokens/

The configuration steps are based on my tests and the official documentation. The examples do not include API Tokens, client secrets, or the actual email address used for access.

---

Originally published on the SunAI Forum.