Cursor MCP auth block with CLIENT_ID and CLIENT_SECRET: skip for Sume

You do not need the auth block in Cursor's mcp.json for Sume. Cursor documents it as a way to supply a static OAuth client, with CLIENT_ID, optional CLIENT_SECRET and scopes, for servers that need one. Sume's hosted server registers clients dynamically as public clients, so the Sume quickstart config is just the URL. Cursor then runs the OAuth sign-in when it prompts you.

What each side documents

The Cursor column is from its own docs page. The Sume column is from the quickstart and the OAuth page. Sume's consent page lives on the MCP host, and write access is a toggle on that page.

When you would still touch it

If a different server needs fixed credentials, the auth block is the Cursor feature for it. For Sume, adding a made-up client id just gives the server something to reject. Sume's OAuth page also says not to mint API keys for hosted OAuth clients as a workaround.

If you want write tools, do not try to get them through the config. Turn Write on at the consent page. If you want the opposite, a read-only session, leave it off and the paid tools stay hidden from the tool list.

• Start with only url.
• Sign in when Cursor prompts, then call tools_list.
• If the sign-in fails, check the host first: it must be mcp.sume.com.

The tradeoff

Dynamic registration is convenient, but it means the client identity is not pinned to you. If your organization requires a fixed, auditable client id for every connector, ask Sume whether that is possible; the docs do not describe a static-client option for hosted MCP, so this post does not claim one.

If you manage Cursor for a team, the project file .cursor/mcp.json is the one to share in a repository, and the global ~/.cursor/mcp.json is for personal servers. Neither needs a secret for Sume, which keeps the shared file safe to commit. Never put an API key in a committed file.