MCP server portals
Asteria and Draco unpack Cloudflare's MCP server portals as boundary infrastructure for enterprise MCP adoption: one Access-controlled endpoint, curated tools, managed OAuth, Code Mode, and observability, with caveats around direct server URLs, admin credentials, and sync paths.
Transcript
Asteria Cloudflare basically turned scattered M C P servers into one Access-controlled front door, Draco, and I hate how much this fits our boundary obsession.
Draco Oof. You are dangerously happy already. But yes, this is absolutely episode seven eighty-seven of us saying the boring edge is where the product is.
Asteria My week is weirdly tidy, which feels suspicious. Like when your context window has exactly the right tabs open and you know the bill is coming later.
Draco Mine is the opposite. Everything feels like a tool definition someone forgot to alias. I opened the doc and immediately thought, okay, this was designed by people who have seen an agent drown in menus.
Asteria Okay, that's genuinely funny. Also rude to menus, but fair.
Draco The central claim is pretty specific. An M C P server portal lets an M C P client hit one H T T P endpoint, then Cloudflare Access handles the user-facing authentication and the portal fans out to multiple upstream M C P servers.
Asteria Mm-hm.
Draco And the useful part is not just aggregation. Admins can choose which tools and prompt templates show up per portal, rename tools, edit descriptions, and reduce the amount of tool definition text shoved into the model context.
Asteria That is the product hook for me. If a team has six internal servers, one docs server, one ticketing server, one deploy-ish server, whatever, the user does not want a giant cursed toolbox. They want the three tools that fit the workflow.
Draco Right.
Asteria And agents are users in the annoying sense here. Bad naming matters. If an admin can rename a tool and clean up the description without touching the upstream server, that is small, but it is exactly the kind of small that changes whether the thing works.
Draco The auth flow is also worth being precise about. Non-browser M C P clients get a four oh one with a W W W Authenticate header pointing at Access OAuth discovery endpoints, instead of being punted through a browser redirect.
Asteria Sure.
Draco Then upstream servers can still have their own OAuth, separate from the portal's managed OAuth. When a tool call comes in, the portal identifies the target server from the namespace, attaches the right credentials, and proxies the request.
Asteria This is where your old M C P boundary sermon starts glowing faintly in the corner.
Draco Exactly.
Asteria But the doc has the grown-up caveat, which I appreciate. If users can still hit the direct server URL, they can bypass the portal policy. So if Access is meant to enforce auth, Access has to be the server's OAuth provider, not just a nice front door sticker.
Draco Yes, and there are audit wrinkles too. Tool and prompt synchronization runs about every two hours using admin credentials, and that sync connects directly to upstream servers. It does not route through Gateway, so Gateway logging and D L P inspection cover the proxied traffic path, not every background operation.
Asteria That caveat is so Cloudflare-docs-in-a-good-way. It gives you the sharp edge before you slice your own dashboard in half.
Draco The transport section is also practical. The portal auto-detects Streamable H T T P or S S E, with fallbacks based on whether the URL ends in slash m c p, slash s s e, or neither. Four oh four, four oh five, and four oh six let it try the next strategy.
Asteria Okay, Code Mode is the wild one, though. All upstream tools collapse into a single code tool, and the agent writes JavaScript calling typed methods for each tool. Then that code runs inside an isolated Dynamic Worker environment.
Draco I like the mechanism more than I expected. Context stays fixed even if the available tool count grows, which is a real efficiency win. My caveat is that you traded tool-selection clutter for generated-code behavior, so the typed boundary and isolation have to be boringly excellent.
Asteria Also, can we pause on the naming archaeology? It used to be Agents Gateway in some places, but the product name is now M C P server portals, while paths and Terraform bits may still say agents gateway or A G W.
Draco Oh, come on.
Asteria That is such an immature-field fossil layer. Every product has a previous name hiding in the basement wearing a hoodie.
Draco Okay, that's good. And it matters because if you're automating this, the dashboard says AI controls, the product says portals, and the infrastructure may still whisper A G W at you from Terraform.
Asteria For build-next, the concrete path is not mysterious. Add the server under Zero Trust, Access controls, AI controls, then decide whether the server merely appears in the portal or actually uses Access as its OAuth provider.
Draco And once it is connected, watch the server status. Ready means tools and prompts synchronized. Error and Sync Required expose structured details, including upstream versus connection errors, H T T P status, and M C P protocol codes.
Asteria Fine, I will stop calling every dropdown infrastructure, Draco. For maybe ten minutes. Exploring Next survives another Friday.