Cursor mcp.json ${env:NAME} for Sume's API key: no secret in the repo

A project-level MCP file is easy to commit by accident, and a literal API key in it is a leak. The Cursor MCP docs show a remote server entry with url and headers, and support ${env:NAME} interpolation, read 2026-10-03. That lets a repo carry the connection to Sume's hosted MCP server without the key.

{
  "mcpServers": {
    "sume": {
      "url": "https://mcp.sume.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SUME_API_KEY}"
      }
    }
  }
}

One credential header

The Sume MCP overview says an API key goes in Authorization: Bearer or x-api-key. The REST SDK docs say the API rejects both at once with a 401 "Send only one API key credential." Choose one header, and do not repeat it in a second layer such as a proxy. If Cursor cannot see the variable, the header would be sent with an empty value; set the variable in the environment that launches Cursor and restart it.

Cursor's OAuth options

Cursor also supports a static OAuth block: auth with CLIENT_ID, optional CLIENT_SECRET and scopes. For redirects it lists http://localhost:8787/callback for the desktop app and https://www.cursor.com/agents/mcp/oauth/callback for cloud agents. Sume's OAuth page describes consent with PKCE and the scopes mcp:read (required) and mcp:write (opt-in), but the docs do not say whether a pre-registered client ID is available, so this post does not recommend the static block for Sume.

Approval and spend

Cursor's page says tool approval is on by default; leave it on for create tools. Sume adds its own gates: idempotency_key on every paid and write tool, max_spend_usd when you provide it, and previews through dry_run. A client timeout is not a job outcome, and jobs_wait can be re-issued with the same ids after wait_slice_expired.

• Commit the file, not the key.
• Send exactly one credential header.
• Keep tool approval on for create tools.
• Check balance before long batches with balance_get.