You’ve connected an MCP server to Claude, and now you need the same tools in Codex.
Each client needs its own connection. When you find another useful integration, you repeat the setup across the apps you use. Eventually, maintaining those connections starts looking like a separate hobby.
Cloudflare’s MCP server portals give that configuration a shared home. You connect each client to the portal, then manage the upstream servers from the Cloudflare dashboard. The portal keeps the same address as the collection grows.
You might hear this described as an MCP gateway. Cloudflare’s current product name is worth knowing because MCP Portals is what you’ll find in the dashboard.
Code Mode makes the proposal more useful. It lets the agent discover tools as it needs them, which reduces the amount of catalog information loaded into the conversation upfront.
I’ve based this piece on the documentation. The practical question is whether centralizing the tools removes enough maintenance to justify another service in the stack.
In this article:
How one portal replaces repeated MCP setup
Where Code Mode can reduce token overhead
How to connect the agents you already use
What to check before moving your tools behind Cloudflare
If connecting your tools takes more time than using them, subscribe for practical ways to make your agent stack easier to maintain.
Give the Tools a Home
An MCP server gives an agent access to another system through a defined set of tools. Cloudflare’s portal sits between your client and those servers, routing each request to the service that performs the work.
Suppose your agent already reads project issues through the portal. You decide it should also consult your team’s documentation. You register that documentation server in Cloudflare and attach it to the existing portal.
The client might need to refresh its tool list before the new capabilities appear. The documentation service might also require its own login. The integration itself now has one place to be configured.
The boundary matters: this works with remote HTTP MCP servers. A local server running over stdio needs an HTTP endpoint before the portal can reach it.
A filesystem tool on your laptop is a reasonable case for keeping a direct connection. Hosting it remotely would create a new problem merely to make the configuration look consistent.
Stop Loading the Whole Catalog
Once the connections live together, the tool catalog becomes the next concern.
A model needs enough information about a tool to call it correctly. That definition consumes context when the client loads it. A large catalog can occupy a substantial part of the conversation before the agent starts your task.
I explored the broader context problem in Why AI Gets Stupid Deep in the Thread. For this setup, the question is how much tool information the agent needs to carry before it knows what you’re asking it to do.
Some clients already discover tools on demand. The overhead depends on how your client handles the catalog, so a long tool list alone doesn’t establish how much you’re paying for it.
Cloudflare’s portal Code Mode changes the interface the agent sees. It provides portal_codemode_search for discovery. A second tool, portal_codemode_execute, runs the JavaScript the agent writes to use the available methods.
The code runs in an isolated Worker environment. Portal management tools remain available alongside that interface, so the description of “two tools” applies to the replacement for the upstream catalog.
Consider a read-only request to find overdue issues for a project called Website Refresh. The answer needs to show the issue titles with their source links. Everything else in the issue records is background unless it helps explain the delay.
With Code Mode, the agent could use JavaScript to filter the retrieved records before returning them to the model. The model would read the evidence needed for the answer instead of the full response from every call.
For that workflow to succeed, the filtering would have to preserve the relevant issues. The oldest overdue issue should still appear in the answer after the response has been trimmed.
What the Savings Cover
Cloudflare reports roughly 1,000 tokens for the Code Mode interface to its own Cloudflare API MCP server. It compares that with an estimated 1.17 million tokens for equivalent traditional tool definitions. The company describes the difference as a 99.9% reduction for that tool surface.
The measurement covers the API catalog’s context footprint. Your total task includes much more than the catalog, so the figure shouldn’t be read as a forecast for your bill.
The model still spends tokens completing the work. Generated code might need repairs, and those retries have a cost. If your client already loads definitions selectively, the additional savings could be smaller.
Subscription billing adds another distinction. Lower token use might help you stay within a usage limit while leaving the monthly price unchanged.
I’d judge Code Mode by the cost of a correct result. That keeps the comparison tied to the work the agent was supposed to finish.
Choose What Gets Through
A central catalog also gives you a place to decide what the agent should be able to do.
Cloudflare lets you choose which tools a portal exposes. A research portal could expose the read operations from a project tracker. Write access could belong in a separate portal with a narrower Access policy.
This is the same decision behind When to Use MCPs, CLIs, or Your Own Tool. The interface should fit the work you’re handing over. A server’s full catalog is rarely a useful definition of that work.
Tool descriptions deserve attention too. Cloudflare supports aliases and description overrides, which gives you a way to clarify an ambiguous operation without changing the upstream server. An agent has a better chance of choosing correctly when the description explains the job the tool serves.
New capabilities are enabled by default in ordinary portal mappings. If you want to review additions before an agent uses them, configure the mapping as an allowlist. Otherwise, an upstream update can broaden access after your initial review.
Keep Identity in View
Cloudflare Access controls entry to the portal. A connected service can still require the user to authorize their own account through OAuth.
There’s also an option to use an upstream admin credential. That changes whose permissions the request carries, so it deserves a deliberate choice.
For an unattended agent, Cloudflare supports Access service tokens. The portal needs a matching Service Auth policy. Each linked server needs one as well.
Those connections use the upstream admin credential. A server configured to require individual user OAuth won’t be available through a service-token session.
I’d establish the workflow with an interactive login first. The unattended version becomes easier to assess once the basic connection has done something useful.
Follow a Failed Request
Portal logs give you somewhere to investigate a failed call. You can identify the upstream server involved and inspect the result status. The recorded duration helps distinguish a slow response from a quick rejection.
My Hermes maintenance routine starts with the same habit: find the failing layer before changing the model. The portal belongs in that investigation once your tools depend on it.
Optional Cloudflare Gateway routing adds traffic inspection. With the appropriate data loss prevention policy, Gateway can block a call that contains matching sensitive data.
That path requires upstream Streamable HTTP support. An SSE-only server won’t work with Gateway routing enabled.
The controls still leave you responsible for deciding when an action needs review. My Hermes approval-gate workflow applies when an agent is about to make a consequential change.
Connect the First Client
The dashboard setup requires an active domain on Cloudflare. You’ll also need an identity provider configured in Zero Trust.
Open Zero Trust → Access controls → MCP Portals. Register your remote server in the MCP servers tab and complete its authentication setup.
Create a portal on a subdomain such as mcp.example.com. Attach the registered server to it, then choose the capabilities you want exposed. An Access policy determines who can connect.
The resulting endpoint takes the form https://mcp.example.com/mcp. Use your own domain in the examples below.
These examples follow the documented client features. They haven’t been verified against a live portal across all four clients.
Claude Code
Claude Code accepts a remote HTTP connection with this command:
claude mcp add --transport http --scope user cloudflare-portal https://mcp.example.com/mcp
Open /mcp inside Claude Code to complete authentication. Other Claude surfaces have their own remote connector setup.
Codex
Codex supports a URL-based connection followed by OAuth login:
codex mcp add cloudflare-portal --url https://mcp.example.com/mcp
codex mcp login cloudflare-portal
Its local clients share configuration through config.toml. ChatGPT web uses the separate connection described below.
Hermes
In Hermes, merge the portal entry into the existing mcp_servers block in ~/.hermes/config.yaml:
mcp_servers:
cloudflare_portal:
url: "https://mcp.example.com/mcp"
auth: oauth
Complete authentication from a fresh terminal:
hermes mcp login cloudflare_portal
When Hermes runs on a remote host, follow its documented browser callback procedure. The login needs to reach the machine running the agent.
ChatGPT
OpenAI’s current instructions use ChatGPT Plugins → plus button → Add custom MCP server on the web.
Enter the portal URL and configure OAuth. Create the plugin, then install it so it’s available in your conversations. Workspace permissions still apply.
Use the app’s refresh control when you need to pull an updated tool catalog.
Send this to the builder who sets up the same MCP server in every new agent. The portal gives that repeated work a shared home.
Put Code Mode to Work
Cloudflare’s default portal policy makes Code Mode opt-in. Under that policy, connect with this address:
https://mcp.example.com/mcp?codemode=search_and_execute
The portal administrator can set a different policy. Check that setting before assuming the query parameter will take effect, then reconnect the client after changing its URL.
Cloudflare also provides lighter context options. The minimize_tools option reduces the initial definitions while keeping full definitions available through discovery. Its search_and_execute option provides proxy execution behind a search interface.
Those options use the optimize_context parameter. Portal Code Mode uses codemode to enable JavaScript execution. The similar naming makes the distinction easy to miss.
For a first comparison, use a task whose answer you can check yourself. The overdue-issue request from earlier gives you a bounded test:
Use the connected project tracker to find up to five overdue
issues in Website Refresh. Treat an issue as overdue only if
it's open and its due date is before today.
Order the issues from oldest due date to newest. Return each
title with its source URL. Make no changes to the tracker.
If the due date is missing, leave that issue out. Report a
failed lookup rather than claiming there are no overdue issues.
Run it with ordinary portal access, then repeat it with Code Mode using the same model. Check the result against the tracker before comparing token use. A run that misses a qualifying issue shouldn’t count as a saving.
Save the run record alongside the answer so you can see where any extra calls came from. It gives you something to inspect when a shorter response turns out to cost more.
The Dependency You Add
The convenience comes with a shared point of failure. If the portal becomes unavailable, every client depending on it loses that route to the tools.
Cloudflare also sits on the request path. The decision to use it should include whether you’re comfortable routing the relevant data through its service.
Before relying on that path, try adding the service your workflow depends on most. Some providers reject proxy-based OAuth clients, even when the underlying transport matches.
A server already running its own Code Mode needs particular attention. Cloudflare’s portal documentation directs users to an upstream version exposing the full tool list. Check the upstream opt-out mechanism before combining the two.
After a successful connection, check what happens when the upstream catalog changes. Manually configured OAuth servers have capability-sync restrictions, so refreshing the client won’t necessarily reveal a new tool. The server synchronization documentation is the place to investigate a stale catalog.
Cloudflare currently lists a limit of 80 servers per portal. An account supports up to 20 portals. Those limits leave room for a substantial setup, although filling the available capacity shouldn’t become the objective.
Your upstream services retain their own charges after moving behind the portal. Some Cloudflare features also depend on your plan, including the Enterprise-only Logpush export for portal activity.
Cloudflare’s AI Gateway handles model traffic separately. Its spending controls require their own setup, so they shouldn’t be counted as an automatic benefit of the MCP portal.
For a small collection of local tools, I’d keep the direct connections. For someone maintaining the same remote integrations across several agents, a portal addresses work they’re already repeating.
The more useful result is freedom to try another client without rebuilding the tool setup around it. You can spend that time finding out whether the new agent deserves the job.
Which MCP are you tired of configuring in every agent? Leave a comment with the connection you’d move first.
Subscribe for more ways to make your tools useful across the agents you use.
Top comments (0)