Slow OAuth consent and MCP timeouts: Sume's Write toggle step

Yes, a slow consent screen is now safer on Python clients: the MCP Python SDK v2.3.0 release notes (Oct 2, 2026) say interactive OAuth logins no longer count against request timeouts. With Sume's hosted MCP, the slowest step is a person on the consent page deciding whether to turn Write on.

The Sume consent flow

Sume's hosted MCP lives at https://mcp.sume.com/mcp. The docs describe six steps. The client connects and gets an OAuth challenge with protected-resource metadata, the user is sent to /oauth/authorize, which redirects to the first-party consent page on the MCP host, and after sign-in the page shows Permissions.

• Read is locked on
• Write is a toggle, default off
• Continue posts to POST /oauth/consent/decision
• The client exchanges the authorization code with PKCE for an access token
• The client calls the MCP endpoint with that bearer token

Why the timeout matters

Between the challenge and the token exchange a human is in the loop. They may need to sign in, read the toggle and think. If the client's request timeout kept running during that time, a slow user could fail the connection for reasons unrelated to Sume. The SDK change, quoted from its release notes, removes that cause on the Python side. Check your own client version; other SDKs may behave differently.

What the Write toggle changes

Plan for it

Sume documents no mcp:paid scope. Paid submits are controlled by wallet admission, and idempotency_key is required on writes and paid calls. A read-only session that tries a mutating tool gets insufficient_scope, so if your agent needs to generate, tell the user to turn Write on before they continue.

Fallback for automation

Unattended jobs cannot click a consent page. Sume also accepts an API key on hosted MCP, sent as Authorization: Bearer or x-api-key. Docs warn that an OAuth token is not an API key and that you should not mint keys as a workaround for an OAuth client.