Cursor mcp.json auth block: do you need CLIENT_ID for Sume?

No: Sume's entry in Cursor's mcp.json is only a url, and you complete OAuth when Cursor prompts you. The auth block with CLIENT_ID is for servers that give you a pre-registered OAuth app, and Sume's quickstart does not use it.

Cursor documents the block in its MCP docs (read 2026-10-02). Sume's entry is from the MCP quickstart.

What does Cursor's auth block contain?

For static OAuth credentials on a remote server, Cursor reads an auth object with CLIENT_ID (required), CLIENT_SECRET (optional) and scopes (optional). Remote servers otherwise use url and optional headers. Config lives in .cursor/mcp.json in the project or ~/.cursor/mcp.json globally, and values can use interpolation such as ${env:NAME}, ${userHome} and ${workspaceFolder}.

Cursor also lists static redirect URLs for callbacks: https://www.cursor.com/agents/mcp/oauth/callback for web and agents, and http://localhost:8787/callback for desktop. Those matter when a server requires you to register a redirect URL ahead of time. The Sume docs describe no pre-registration step, so they are not part of connecting to Sume.

What is the Sume entry?

The same JSON the quickstart shows. Add it in Cursor Settings, MCP, or edit the file, then accept the sign-in. Consent happens on the MCP host, not on app.sume.com, and the default grant is read-only. Turn Write on at consent only if you want mutating and paid tools. After connecting, call tools_list once to verify the session.

The Sume docs list a few useful first calls: mcp_health for endpoint and auth source, tools_list for the tools visible to this session, tools_schema for one tool contract, and account_me for the workspace account.

{
  "mcpServers": {
    "sume": {
      "url": "https://mcp.sume.com/mcp"
    }
  }
}

When would I use headers instead?

If you want an API key rather than OAuth, Sume accepts Authorization: Bearer <key> or x-api-key. In Cursor that goes in the headers object, and the interpolation syntax lets you keep the value in an environment variable instead of the file, written as ${env:SUME_API_KEY}. The key path sees the full tool set, so paid tools are visible straight away; they still need an idempotency_key and wallet admission.

Do not combine the two. An OAuth token is not an API key, and Sume's docs warn against minting keys for OAuth clients as a workaround. Pick one path per entry.

What should I check if the sign-in does not start?

Check the URL first; the endpoint is exactly https://mcp.sume.com/mcp. Then check whether another entry with the same name exists in the global file and the project file. If the sign-in opens but you cannot call a paid tool, the cause is almost always scope: a read-only session returns insufficient_scope for paid and mutating tools, and the fix is to sign in again with Write on, not to change the file.

Cursor asks for approval before using MCP tools by default, per its docs, and MCP tools follow the same run modes as terminal commands. That is a client-side prompt on top of Sume's own gates. For the redirect details see Cursor's OAuth redirect URL post.

If you work in a team that shares one repository, keep the project file to the URL and let each person sign in. Because OAuth consent happens when each person signs in, each teammate's consent decides whether Write is on for their session. After the first sign-in, calling account_me confirms which workspace account the session belongs to, which is worth doing before anyone runs a paid call.

A final check after any change to the file: restart Cursor or reload the MCP server list, confirm the Sume server shows its tools, and ask the agent to describe one tool with tools_schema before it submits anything. Sume's playbook for this is to inspect one tool, preview the cost with dry_run or generation_admission_preview, and only then submit with a fresh idempotency_key. The sign-in and the file cover access; the preview and the key cover spend.