Speakeasy vs Cloudflare MCP Server Portals: Which MCP gateway fits your stack?

Cloudflare MCP Server Portals puts many Model Context Protocol (MCP) servers behind one URL and gates that URL with Cloudflare Access. If your company already runs Cloudflare One, it's the shortest path to a governed MCP endpoint: your identity provider, Access policies, Gateway data loss prevention (DLP), and Cloudflare Tunnel all apply on day one. Speakeasy's AI Control Plane is a managed MCP gateway built around a different question. It decides which person, which AI client, and which upstream credential reaches each individual tool, with all three tied to your directory.

Choose Cloudflare MCP Server Portals to put MCP traffic inside the Zero Trust perimeter you already operate. Choose Speakeasy when permissions need to follow your directory down to single tools, and when you need to decide which AI clients may connect at all. Below, we compare the two on identity, per-tool policy, client admission and shadow AI, upstream credentials, audit, and deployment. Every claim about Cloudflare links to its own documentation.

Speakeasy vs Cloudflare MCP Server Portals comparison

What does Cloudflare MCP Server Portals do well?

Cloudflare's portal is strongest where Cloudflare One is already the network control point. A portal is an Access application, so the same Access policies that protect internal web apps decide who reaches MCP, including selectors for email, group, country, and device posture. The MCP Server Portals documentation lists a set of capabilities that hold up well against dedicated MCP gateways:

• One endpoint for many servers. Each portal serves its upstream servers at /mcp, namespaces tools by server ID to avoid collisions, and supports both the stateless 2026-07-28 protocol and earlier Streamable HTTP clients without configuration.
• Tool curation and aliases. Admins can hide individual tools, switch a server to an allowlist through the API, and rename tools and rewrite descriptions without changing the upstream server.
• Context controls. Code Mode collapses every upstream tool into a search tool and an execute tool that run agent-written JavaScript in an isolated Worker, and admins can make it opt-in, default, or enforced. The optimize_context options strip or hide tool definitions for clients that need a smaller context.
• DLP in both directions. With Gateway routing turned on, tool requests and responses pass through Cloudflare Gateway, where DLP profiles can block a matching payload. Outbound calls also leave from your dedicated egress IPs, which helps when upstream servers allowlist source addresses.
• Private upstream servers. A portal can reach an MCP server on your private network through Cloudflare Tunnel or another Cloudflare One connector.
• Infrastructure as code. Portals and servers are managed through the API and the cloudflare_zero_trust_access_mcp_server_portal Terraform resource.

For a security team that already writes Access and Gateway policies, none of this is new configuration to learn. Few MCP gateways can match that integration with an existing Zero Trust deployment, and if your requirements stop at "authenticate the person, curate the tools, scan the payloads", the portal meets them.

How does sign-in and identity compare?

On Cloudflare, a user logs in to the portal through Access, then authenticates separately to each server that requires OAuth. Cloudflare softens this by batching new-server prompts into one authorization flow. Two documented limits matter for regulated teams. First, Access policies on an MCP server control visibility in the portal, not access to the server: "Blocked users can still connect to the server (and bypass your Access policies) by using its direct URL" unless Access is configured as that server's OAuth provider. Second, independent MFA, purpose justification, and temporary authentication are not enforced for servers authorized through a portal. MFA that your identity provider runs at portal login still applies, as do group, country, and device posture selectors; what's missing is the extra Access prompt when a user authorizes each server.

Speakeasy signs people in through federated SSO, where the identity provider runs its own MFA, device trust, and conditional access on every sign-in. With Directory Sync (SCIM) on, members are provisioned from the directory and roles come from identity provider group mappings. Role rows in the dashboard turn read-only behind a Managed by directory sync notice. Removing or suspending a person in the identity provider ends their membership and role assignments right away.

For Okta customers, Enterprise Managed Auth removes the per-service prompt. A person signs in once with Okta and reaches every MCP server set up for them. On each tool call, Speakeasy exchanges the person's Okta identity for an access token at the downstream service through Cross App Access (XAA). The Okta API service app that Speakeasy uses holds read-only scopes (okta.apps.read, okta.users.read, okta.groups.read), so Speakeasy never writes to your Okta org. Cross App Access is set up separately in Okta. Enterprise Managed Auth supports Okta today and works only with downstream services whose authorization servers support XAA; other servers keep the ordinary connect flow. The Okta identity gateway use case walks through the setup.

Can you restrict a single tool for a single team?

Cloudflare's tool controls belong to the portal. Turning a tool off removes it for every user of that portal, and Access policies decide who can see each server or connect to each portal. If finance needs a billing server's read tools and support needs its refund tool, the documented path is two portals with different tool selections and different Access policies.

Plan around two sync behaviors. New upstream tools are enabled automatically by default after the next sync, roughly every two hours for DCR servers. The allowlist pattern that hides new tools until someone approves them is set through the API with default_disabled. And if the upstream server renames a tool, its alias is removed on the next sync.

Speakeasy puts the tool decision in the role. In the role editor, each MCP permission narrows to All servers, Specific projects, Specific servers, or Specific tools. Finance and support can share one server and one gateway URL while holding different tools. Each scope has a blocking counterpart, such as mcp:blocked_connect, which withdraws access for matching resources even when another role grants it. The same rules appear on each server's Team Access tab, and tool filtering curates what a server exposes in the first place.

The organization gateway is the closest match to a portal. It's one MCP URL for the whole org, and the servers each person sees follow their own access. Remote and tunneled servers can be permissioned by tool name once their tool list has been recorded. A remote server whose tools have never been recorded has nothing to pick from until someone connects to it on the Inspect tab. When a request is denied, the Authorization Challenges tab records who asked, for what, and which scope was missing, and an admin can resolve it by assigning a role that covers the request. Roles can also be assigned to registered agent identities, whose grants are filtered against an agent runtime scope allowlist so a role can't hand an agent a scope it could not hold directly.

Which MCP clients get in, and what about shadow AI?

A Cloudflare portal identifies the downstream client with an X-Forwarded-User-Agent header, taken from the client's clientInfo.name or HTTP User-Agent. Cloudflare's own guidance is to use it for logs and diagnostics, not authentication or authorization, "because the MCP client controls the value."

For MCP traffic that bypasses the portal, Cloudflare publishes a tutorial on detecting MCP traffic in Gateway logs. You query the GraphQL Analytics API for hostnames and paths that look like MCP, then create a custom DLP profile that matches JSON-RPC methods such as tools/call. It works with infrastructure Cloudflare customers already run, and it can block at the network. It's also a project you build and maintain. The detection relies on hostname and path patterns plus DLP, which scans only the first 1,024 bytes of POST bodies, and it sees only traffic that Gateway proxies.

Speakeasy treats the client as something to decide on. Shadow AI, generally available under Guardrails for every org, inventories the coding harnesses, assistants, and local models that enrolled devices report. An admin marks each MCP-speaking tool Approved or Blocked, with a recorded rationale. A Blocked tool is refused when it authenticates, on every MCP server in the org. The gateway recognizes the tool by its client ID metadata document, a URL the client's publisher hosts, rather than by a name the client reports (CIMD vs DCR explains the mechanism).

Speakeasy's documentation lists the limits. Decisions for tools that ship no MCP client of their own are recorded but not enforced. A tool without a client ID metadata document can't receive a decision at all. A device that isn't enrolled in the device agent doesn't appear in the inventory. For servers rather than clients, Shadow MCP lists the MCP servers observed in agent traffic that Speakeasy doesn't host, and a blocking policy can deny every server not on an allowlist.

Whose credential reaches the upstream API?

Both products support the two standard patterns, which are a token per user and one shared credential. On Cloudflare, Require user auth prompts each user for their own upstream login; with it off, every portal user reaches the server through the admin credential of whoever connected it. Servers can also use a static bearer token or custom headers. Service tokens cover machine-to-machine access, and they always use the admin credential because they can't complete per-user OAuth.

Cloudflare documents an operational gap with that admin credential. Per the known limitations, "Admin OAuth tokens can expire silently." When the token expires, the server moves to Error or Sync Required, it disappears from the portal for end users, and "Admins are not notified when this happens."

Speakeasy's upstream credentials offer per-user OAuth through an attached authorization server, with tokens encrypted at rest and refreshed when needed. A remote server can instead hold one shared Service Account credential: a static bearer, basic, or manual header, or an OAuth client credentials token the platform obtains for itself. The static credential guide covers the simplest case. When the authorization server stops accepting a service account client, the server's Identity section shows the failure and its date. Callers get an error that names a misconfigured upstream credential instead of a reauthorization prompt they can't complete. With Enterprise Managed Auth, Okta supplies each person's upstream token, and removing a person or resource connection in Okta stops new access to every server that uses it.

The same caution applies on both sides. A shared credential acts upstream with the app's permissions, not the caller's. Narrow who can reach that server, whichever gateway you use.

What does each one record for an audit?

Cloudflare's dashboard portal logs show time, status, server, capability, and duration for each request. Logpush export is available on Enterprise plans, and its MCP portal dataset adds fields such as UserEmail, ToolCallName, ClientIP, and SessionID for your SIEM. With Gateway routing on, portal traffic also appears in Gateway HTTP logs next to the rest of your organization's HTTP traffic. If Cloudflare is already your logging pipeline, that's a short path to MCP coverage.

Speakeasy keeps two records. The org-wide Audit Logs feed covers administrative activity. Each entry has a resource:action badge, the actor, an expandable diff, and the surface the change came from (dashboard, API key, Platform MCP, or Project assistant). Filters and an Audit Log Insights assistant help answer questions such as "what changed recently?" MCP session revocations and transcript opens are audit-logged too. Reading other people's session transcripts requires the chat:read scope, which is in no default role, including Admin. For tool traffic, Tool Logs records each call with the server, tool, user, and client, and OpenTelemetry export sends events to your own collector.

Managed, private, or self-hosted?

Both products are managed services. Neither one is software you install in your own data center, so if self-hosting is a hard requirement, neither fits, and the private MCP gateway guide explains what self-hosting does and doesn't buy you.

The difference is in how each one handles private networks. Cloudflare reaches private MCP servers through Cloudflare Tunnel with Gateway routing turned on. The MCP server URL and DCR endpoint can be private, but the OAuth authorization and token endpoints must be reachable on the public internet. The portal itself runs on a custom hostname that must be an active Cloudflare zone, and that's no obstacle for existing customers.

Speakeasy splits private networking into two separate controls. Tunneled MCP servers reach a server inside your network through an outbound WebSocket from a small tunnel agent, with no inbound firewall rule. Tailscale private access controls the client side. It puts a server's or gateway's MCP URL on your tailnet, and each server is set to Public only, Public and private, or Private only.

Tailscale private access requires an Enterprise org, and Tailscale is currently the only private network provider. If your network team standardizes on another overlay or on a cloud private endpoint, plan for that before you evaluate. Private only also has no automatic public fallback. If the tailnet or ingress goes down, those servers stay unreachable until private access returns or an admin switches them back. Hosted clients such as ChatGPT and Claude remote connectors can't reach a private-only URL, because the vendor's infrastructure isn't on your tailnet. The private MCP gateway guide covers these trade-offs and the rollout pattern of running both routes side by side before closing the public one.

When to choose Cloudflare MCP Server Portals

Cloudflare MCP Server Portals is the better fit when:

• Cloudflare One is already your Zero Trust platform. Access policies, device posture checks, Gateway DLP, Tunnel, and Logpush carry over to MCP without a second vendor or a second policy language.
• Payload inspection at the network is the priority. Gateway DLP profiles block matching tool requests and responses, and egress policies give upstream servers a predictable source IP.
• Your agents need smaller tool contexts. Code Mode and the optimize_context options are portal settings, not something each client has to implement.
• Team-level tool curation is enough. If a portal per audience is a workable unit of access, per-portal tool toggles and aliases cover the need.

When to choose Speakeasy

Speakeasy is the better fit when:

• Tool access has to follow your directory. Roles come from identity provider group mappings, narrow to specific tools, and end when the person is deprovisioned. One organization gateway URL serves each person their own tool set.
• You need to decide which AI clients may connect. Shadow AI records an Approved or Blocked decision per client and enforces it at authentication, across every MCP server in the org.
• You use Okta and want to remove per-service OAuth prompts. Enterprise Managed Auth and Cross App Access let Okta issue upstream tokens under policies you manage in Okta.
• Your audit needs to answer who changed access. The audit log records the diff and surface of every administrative change, and tool logs record the user and client behind every call.

The two can also run side by side. Teams that keep Cloudflare for network inspection can still put Speakeasy in front of MCP servers whose access needs to follow the directory. If you're deciding where per-tool, per-person policy should live, we'd like to hear how you're approaching it.