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.