Claude Code mcp add --client-id: Sume's OAuth needs no client ID

You do not need --client-id or --client-secret to connect Claude Code to Sume. Sume's quickstart is two commands, claude mcp add --transport http sume https://mcp.sume.com/mcp and claude mcp login sume, and the client discovers the rest from Sume's protected-resource metadata.

Claude Code's MCP docs (read 2026-10-02) list --client-id, --client-secret and --callback-port as options of claude mcp add for servers that need a pre-configured OAuth app. Sume's side comes from the MCP quickstart and OAuth and API keys.

What are those flags for?

Some MCP servers do not let clients register themselves. The vendor gives you an OAuth application with a client ID and sometimes a secret, and the client must present them. Claude Code covers that case with --client-id ID and --client-secret, where the secret flag prompts for input rather than taking it on the command line. claude mcp add-json accepts --client-secret too, and --callback-port PORT fixes the local port for the redirect.

None of that is about Sume. If you paste a client ID someone gave you for a different service into a Sume entry, you are likely to turn a working flow into a failing one.

What does Sume's flow look like instead?

From the docs: the client connects to https://mcp.sume.com/mcp, Sume returns an OAuth challenge and protected-resource metadata whose authorization_servers entry is the MCP origin, and the client sends you to https://mcp.sume.com/oauth/authorize. That redirects to the first-party consent page on the MCP host, where Read is locked on and Write is an opt-in toggle that defaults to off. The client then exchanges the authorization code using PKCE and calls the endpoint with the bearer token.

The docs do not ask you to register anything beforehand, which is why the quickstart has no client ID step. The page does not describe the registration mechanism, so this post does not either; a related post covers Codex and client registration.

claude mcp add --transport http sume https://mcp.sume.com/mcp
claude mcp login sume
# Sign in on the MCP host, leave Write off unless you need it
claude mcp get sume

When would I still pass a flag?

Two cases. If your browser cannot reach a random local port, --callback-port on claude mcp login lets you choose one that your setup allows; there is a longer walk-through in the callback port post. And over SSH with no browser, claude mcp login sume --no-browser is documented on the same page.

Neither is a client-ID question. If a login fails for a reason that looks like registration, read the error before adding a flag, and check the URL first; a wrong or misspelled endpoint is the common cause.

What if I want a key instead of OAuth?

Sume also accepts an API key on hosted MCP, sent as Authorization: Bearer or x-api-key. That path sees the full tool set, so paid tools are visible immediately and idempotency_key plus wallet admission are the only gates. The Sume docs call OAuth the preferred path for interactive clients and the key path available for existing automation. An OAuth token is not an API key, and the docs warn against minting keys for OAuth clients as a workaround.

A key goes in with --header, not with the client ID flags. Keep it out of the command history by reading it from an environment variable, and rotate it if it ever shows up in logs or chat. Create keys in the dashboard.

One last note on scopes, because it is what people actually hit after a clean login. The consent page shows Read locked on and a Write toggle that defaults to off. If you signed in without Write and then ask Claude to run generate_image, you get insufficient_scope, and the answer is not a different client ID. Run claude mcp login sume again and turn Write on, or switch to the key path. Sume's docs give the same advice for both clients: use dry_run first, then submit with a fresh idempotency_key, and keep max_spend_usd on calls where a cap matters.