Is mcp.dev.sume.com a staging URL I can use? No, use mcp.sume.com

No. https://mcp.dev.sume.com/mcp is for Sume's own development environments. Sume's docs say public docs and customer configs must use https://mcp.sume.com/mcp. If your client config points at the dev host, fix it before you debug anything else.

The two hosts

The OAuth pages describe the same shape on both hosts: a protected-resource metadata document, an authorization server on the MCP origin, and dynamic client registration. The dev host just has a different origin.

Why a wrong host breaks quietly

An OAuth token is issued for one resource audience. Sume's token exchange checks that the client id, redirect URI and resource match the ones the authorization code was issued for, so a token or a code from one host is not a token for the other. A client that was registered or signed in against the wrong host can look connected and then fail on the first call.

An API key is a separate matter: do not paste a production key into a dev config just to see if it works.

• Some tools exist only on the dev host: Sume's tools page lists a dest-only group that is never available in production, so a tutorial that names one will not work against mcp.sume.com.
• Check the URL in your client config first, character by character.
• Run mcp_health after connecting; it reports the endpoint, the auth source and the safety posture.
• If a client cached metadata from the wrong host, remove the server and add it again.

What to do if you are already on the dev host

Remove the server entry, add https://mcp.sume.com/mcp, and sign in again so the client registers against the production authorization server. Do not carry over the old tokens, and do not copy a tool name from a dev-only note into a production prompt. Any jobs you started against another environment live there, not in your production workspace.

The tradeoff is small: a one-time reconnect. Staying on the wrong host risks confusing results about which environment holds your jobs and your balance.