Cloudflare private MCP servers vs Sume public MCP endpoint

Cloudflare's private MCP server support is for servers you host on your own network; Sume's hosted MCP is not one of those, because it is a public HTTPS endpoint at https://mcp.sume.com/mcp that you do not run. A portal can list it as a public upstream, and the private-network feature is irrelevant to it. The feature does matter for the other half of your stack: the internal MCP servers that agents call alongside Sume.

Cloudflare's private MCP server entry says portals can now connect to MCP servers available only on a private network, reaching private hostnames and IP addresses through Gateway with Cloudflare Tunnel, Mesh, or other connectors, and that OAuth endpoints must remain internet-accessible (read 2026-10-03). The portal itself went GA on 2026-09-24.

What stays public on the Sume side

Sume's protected-resource metadata names the MCP origin as the authorization server, and consent happens on the MCP host, not on app.sume.com. The OAuth surfaces are public by design: https://mcp.sume.com/oauth/authorize, the consent page, and two well-known metadata documents.

That lines up with Cloudflare's rule that OAuth endpoints stay reachable from the internet, but the rule is about your private servers. For Sume nothing is private to hide, and there is nothing to tunnel.

What to do about egress

If your agents run on locked-down machines, the practical question is outbound access: the machine must reach mcp.sume.com over HTTPS, and the media URLs Sume returns live on media.sume.com. Sume's docs say hosted MCP cannot read files from your laptop, so uploads go through a signed upload URL: create the URL, PUT the bytes from the client, then complete the asset.

Do not allow-list by IP on guesses. Allow-list the hostnames the docs name and test with a read-only call first.

• Allow outbound HTTPS to mcp.sume.com for the MCP session.
• Allow the media host if agents download results directly.
• Keep the API key in the secret store of the machine that runs the agent, not in a shared config.

A quick reachability check

Run this from the same network the agent uses, before debugging anything in the portal.

for u in \
  https://mcp.sume.com/.well-known/oauth-protected-resource/mcp \
  https://mcp.sume.com/.well-known/oauth-authorization-server
do
  printf "%s -> " "$u"
  curl -s -o /dev/null -w "%{http_code}\n" "$u"
done

A 200 from both means the discovery step a portal or client performs can complete from that network. A timeout means egress filtering, which no portal setting will fix. For the matching secret-placement question on self-hosted agent machines, see the Cursor self-hosted post.

A mixed stack in practice

Take a team with an internal MCP server for its product catalog on a private network and Sume for generating the media. With a portal in front, the catalog server is reached through the private path and Sume is reached as a normal public upstream, and the agent sees one endpoint for both. The prompt can say: read the product description from the catalog tool, then create the image.

The security boundary is worth stating plainly. Data leaving the private network goes out in the arguments of the Sume call, such as a prompt, so decide which fields from the internal tool are allowed in a generation request. Sume tells you not to paste signed URLs, OAuth tokens, or API keys into chat logs, and the same discipline applies to anything an agent copies from a private tool into a prompt.

If that boundary is unclear, start with read-only access to Sume, let the agent plan, and let a person approve the first paid call. The dry_run flag gives an estimate without submitting the job, which is a good place for the approval to happen.