MCP URL mode elicitation in Claude Code vs OAuth consent

URL-mode elicitation lets an MCP server ask Claude Code to open a browser-based flow in the middle of a session. Sume's hosted server does not use it for sign-in: its browser step is the OAuth authorize and consent pages, which the client opens itself when you log in. The two look alike on screen but are triggered differently.

What did Claude Code add?

Claude Code 2.1.281 added MCP URL-mode elicitation on 2026-07-28 protocol connections, so servers can ask Claude Code to open a browser-based flow. The changelog adds that no waiting dialog is left on screen when the server has no way to confirm completion. The condition matters: it applies to connections speaking the 2026-07-28 protocol.

What is Sume's browser step, then?

Sume documents an OAuth flow. The client connects to https://mcp.sume.com/mcp, receives an OAuth challenge, and sends you to https://mcp.sume.com/oauth/authorize, which redirects to the consent page on the MCP host. That consent shows Permissions with Read locked on and a Write toggle that defaults to off. The client then exchanges the code with PKCE and calls the endpoint with the bearer token.

Will my Sume connection change with this release?

Nothing in the Sume docs describes elicitation, and the MCP 2026-07-28 spec post covers which protocol versions the hosted server negotiates. Keep using claude mcp login sume as the quickstart shows.

Where do I turn Write on?

On the consent page, not in an elicitation. The default grant is read-only, and Write is opt-in; there is no mcp:paid scope, so paid submits go through wallet and admission. Details in OAuth and API keys.

How can I tell which flow I am in?

Look at what started the browser tab. If you ran the login yourself, or the client answered an OAuth challenge from the endpoint, you are in the OAuth flow, and the tab is Sume's consent page on the MCP host with the Permissions block. If a tool call mid-session asked Claude Code to open a page, that is an elicitation, and it is the server's own flow rather than Sume's documented sign-in.

The practical difference is what you end with. The OAuth flow ends with a token that the client stores and sends as a bearer on later calls. The changelog describes elicitation only as a browser-based flow a server can ask for, so do not expect it to grant scopes on Sume.