Cloudflare MCP portals GA: where Sume hosted MCP fits

A Cloudflare MCP server portal is one endpoint that fronts the MCP servers your organization has approved, and Cloudflare Access logs the tool, prompt, and resource activity that passes through it (read 2026-10-03). Sume's hosted MCP server is one remote HTTP URL, https://mcp.sume.com/mcp, so on paper it is the kind of upstream a portal can list. Sume's docs do not describe a portal setup, so treat the steps below as checks to run, not a promised integration.

Cloudflare announced general availability on 2026-09-24 in its portal GA changelog. The Sume side comes from MCP OAuth and API keys and MCP tools and gates.

What GA added since the open beta

Cloudflare lists six additions since open beta (read 2026-10-03). Two of them matter most when the upstream is a paid-generation server: how the portal authenticates to the upstream, and what it records.

What the Sume upstream looks like

Sume accepts either an OAuth access token or a Sume API key on the same URL. Under OAuth, mcp:read is required and read-only; the user can switch Write on at consent to also grant mcp:write. There is no mcp:paid scope. An API key (sent as Authorization: Bearer or x-api-key) sees the full tool set.

That split decides what the portal's users can do. A portal that forwards each person's own OAuth grant keeps the default read-only posture: mutating and paid calls answer insufficient_scope until that person turns Write on. A portal that holds one shared API key gives every portal user the paid tools, with spend drawn from the wallet behind that key.

• Per-user OAuth: each person consents on the MCP host and chooses read-only or read plus write.
• Shared API key: one credential, full tool set, one wallet; rotate it if it appears in logs.
• Paid submits need an idempotency_key either way; dry_run and max_spend_usd are optional per call.

Three checks before you list it

First, confirm the OAuth discovery documents answer from outside your network, because the portal has to read them. Sume publishes both at documented paths.

Second, decide who may reach paid tools and write that into the portal policy as a rule about people, not tools. Third, send one read-only call through the portal (mcp_health reports the auth source) before anyone tries a paid one.

# discovery documents the portal must be able to read
curl -s https://mcp.sume.com/.well-known/oauth-protected-resource/mcp
curl -s https://mcp.sume.com/.well-known/oauth-authorization-server

# after the portal lists the server, ask a client to call:
#   mcp_health   -> confirms authenticated.auth_source
#   tools_list   -> shows only what this session may call

If the portal reports a different tool list than a direct connection, trust tools_list from inside the session: Sume documents it as the live contract and says not to assume HTTP API parity. For how a managed client treats the same URL, see the managed allowlist post.

What this means for a small team

Most teams that read a portal announcement are asking one thing: does adding a gateway in front of our agent tools slow down the people who just want to generate a clip? The honest answer is that it depends on the credential you put behind it. If each person signs in with their own OAuth grant, nothing about their workflow changes except where the connector URL points, and the default stays read-only until they flip Write on at consent.

If the team shares one key, the portal becomes the only gate between a prompt and the wallet, so the policy you write there carries real weight. A reasonable middle path is to keep the shared key for a small automation group and leave the rest on per-user OAuth, then compare the two in the logs after a week.

Whichever you choose, write down who owns the key, where it lives, and how it is rotated. Sume says to rotate any key that shows up in logs or chat history, and a portal adds one more place where that could happen. Spend visibility is the other half: balance_get and usage_get are read tools, so a weekly check costs nothing and tells you whether the arrangement is behaving.