2026-10-04

Cloudflare Workers OAuth Provider 1.0: do you need it for Sume MCP?

Cloudflare shipped Workers OAuth Provider 1.0. You do not need it to use Sume's hosted MCP, which runs its own OAuth. When you would, and what Sume handles.

4 min readSume

All posts

No, you do not need Workers OAuth Provider to use Sume's hosted MCP server, because Sume already runs the OAuth flow at https://mcp.sume.com. You would reach for the provider if you are building your own MCP server on Cloudflare and need to authorize its users.

The Cloudflare changelog lists Workers OAuth Provider 1.0, alongside AI Search going generally available with usage billing starting Nov 1, 2026, Artifacts in open beta and Basin generally available.

What the changelog lists

Entries from the Oct 1 window.

Cloudflare changelog (read 2026-10-03)
Item	What the page says
Workers OAuth Provider	1.0
AI Search	Generally available; usage billing starts Nov 1, 2026
Artifacts	Open beta
Basin (formerly Data Platform)	Generally available

Who runs the authorization server

With Sume the answer is Sume. A client connects to https://mcp.sume.com/mcp, receives an OAuth challenge and protected-resource metadata, and is sent to https://mcp.sume.com/oauth/authorize, which continues to a consent page on the same host. The client exchanges the authorization code with PKCE for an access token and calls the MCP endpoint with it.

The docs list the metadata endpoints under https://mcp.sume.com/.well-known/. The authorization server is the MCP origin, not www.sume.com or app.sume.com.

Two different jobs

It helps to name the roles before choosing a tool.

Who needs an OAuth provider
You are	OAuth provider needed?	Why
Connecting Claude, Cursor or Codex to Sume	No	Sume's MCP host handles consent and tokens
Calling the Sume HTTP API from a Worker	No	Use an API key held as a Worker secret
Building your own MCP server on Workers	Yes, possibly	Your server must authorize its own users

Scopes you get from Sume

Consent shows Permissions with Read locked on and a Write toggle that defaults off. Granting Write adds mcp:write; there is no mcp:paid scope, and paid submits are governed by wallet and admission instead. With mcp:read only, write and paid tools return insufficient_scope.

An OAuth token is not a Sume API key. Do not store it in CLI config, paste it into prompts or forward it to third parties, and do not mint API keys for OAuth clients as a workaround.

If a Worker is the client

A Worker that calls Sume on a schedule is automation, which Sume's docs route to an API key: send Authorization: Bearer or x-api-key, never both. Store the key as a Worker secret, require idempotency_key on write and paid MCP calls, and use dry_run=true before the first paid submit.

If that Worker also receives Sume webhooks, verify the sume-v1 signature on the raw body before doing any work.

Choosing between the two clients

Interactive clients such as Cursor and Claude Code are the best fit for OAuth, because a person is present to approve consent and can leave Write off. Unattended jobs are the best fit for an API key, because nobody is there to click. In both cases the same three gates apply to anything that spends: idempotency_key on the call, an optional max_spend_usd cap, and a dry run first.

Sume documents the hosted connector as separate from its in-app Studio Agent product, so do not point a client at anything other than the production MCP URL.

Verify the connection

After a client connects, ask it to call mcp_health and confirm the auth source, then tools_list to see what the session can use. If a paid tool is missing, the session is probably read-only.

claude mcp add --transport http sume https://mcp.sume.com/mcp
claude mcp login sume