Sume MCP OAuth opens a consent page on mcp.sume.com, not app.sume.com

When you connect a client to https://mcp.sume.com/mcp with OAuth, the browser lands on a consent page that lives on the MCP host: https://mcp.sume.com/oauth/consent. It is not on app.sume.com, and the protected-resource metadata does not advertise www.sume.com. The page shows a Permissions section where Read is locked on and Write is a toggle that starts off. Continue posts your choice to POST /oauth/consent/decision.

If your connector, proxy or allow-list assumes that sign-in happens on the app domain, that assumption is the reason the flow stops.

That is the whole reason this page exists: the client, the proxy and the person all need to agree on one origin for the sign-in.

The path from connect to token

The documented sequence has six steps. The one that matters here is the third: the authorize URL redirects to the first-party consent page on the MCP host, which loads Clerk's browser script from that origin for sign-in.

Notice that the second step names the MCP origin as the authorization server. Many clients cache that value after the first connect. If you ever changed a client configuration by hand, delete the cached entry and let the client discover it again.

• The client connects to https://mcp.sume.com/mcp and receives an OAuth challenge with protected-resource metadata.
• The metadata names the MCP origin as the authorization server.
• The client sends the user to https://mcp.sume.com/oauth/authorize, which redirects to GET /oauth/consent.
• The user signs in, then reviews Permissions: Read on, Write off by default.
• The client exchanges the code with PKCE for an access token.
• The client calls https://mcp.sume.com/mcp with that bearer token.

What goes wrong when the origin is assumed

Several real setups break on the origin. A corporate proxy that only allows the app domain blocks the consent page. A browser profile with strict cookie rules for third-party scripts can fail to load the sign-in widget. A client that was configured by hand with an old authorization-server URL will send the user to a surface that the docs call secondary and deprecated.

The fix is to let the whole MCP origin through for the browser step, and to let the client discover the endpoints itself from the two public metadata documents instead of hard-coding them.

Also check the basics: the browser that opens must be able to reach the host, pop-up and redirect handling must be allowed for the callback, and a headless machine needs the client's device or copy-the-URL mode if it has one, because the consent page needs a real browser session to sign in.

The metadata documents to trust

One host for the whole flow

Development uses the same layout on its own host, which is for Sume engineering and not for customers. Production clients should never need to know about it.

After a successful sign-in the page returns the browser to the redirect URI that the client registered, with the authorization code. If the browser shows an error after Continue, read the address bar: an error and error_description query pair from the server is far more useful than the page text.

What to choose on the page

On the consent page, leave Write off for an agent that only reads. Read-only sessions can use tools such as jobs_list, assets_get, catalog_list and crawl_scrape. Turn Write on when the agent must create assets, cancel jobs or submit paid generation, and expect those calls to need an idempotency_key.

Per the docs, a client that gets only mcp:read and calls a write tool gets insufficient_scope. To change the grant, run the client's login again and flip the toggle. The steps for each client are in the MCP quickstart, and the scope rules are on MCP OAuth and API keys.

Write is off by default on purpose. A person who connects a client to look around does not hand it the ability to spend money, and a person who wants a hands-off agent has to take a deliberate action to allow it. Revisit the choice by signing in again, since the scope is part of the token and not a setting that you can change later on the server side.