VS Code mcp.json: keep the Sume API key in a password input

To use a Sume API key with VS Code without writing it into mcp.json, declare an inputs entry of type promptString with "password": true, and reference it in the server's headers as ${input:...}. VS Code then asks for the key once, masks it, and the file holds only the input name.

That is the API-key path. For an interactive setup Sume's docs prefer OAuth, where the file needs only the URL. Pick the key path when you want a headless, repeatable setup that does not open a browser.

The config

The VS Code MCP configuration reference (read 2026-10-10) shows this shape: an inputs array with type, id, description and password, and a servers object whose http server has type, url and headers. Sume's API-key mode accepts Authorization: Bearer <SUME_API_KEY> or x-api-key, so the header below is valid for the hosted endpoint.

{
  "inputs": [
    {
      "type": "promptString",
      "id": "sume-api-key",
      "description": "Sume API key",
      "password": true
    }
  ],
  "servers": {
    "sume": {
      "type": "http",
      "url": "https://mcp.sume.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:sume-api-key}"
      }
    }
  }
}

OAuth or key: what each exposes

The two credentials are not interchangeable, and they differ in what the session can do. MCP OAuth and API keys sets out the matrix. An OAuth token is not a Sume API key, and the docs say not to mint keys for OAuth clients as a workaround.

Trust prompts and where the key lives

VS Code's MCP page (read 2026-10-10) says servers in .vscode/mcp.json inherit Workspace Trust, that a separate dialog appears for servers from other sources, and that **MCP: Reset Trust** clears those decisions. If you reset trust, the server asks again, which is a quick way to confirm the prompt works after you change the header.

Keep the file in git only if it holds the input name and no key. An input like the one above is safe to commit. If a key ever lands in chat history or a log, Sume's docs say to rotate it from the dashboard, and the API keys page is where you do that.

• Never write the literal key into the headers value.
• Use one key per machine or per automation so a revoke is narrow.
• After any rotation, run **MCP: Reset Trust**, then call mcp_health.
• Call tools_list once to confirm a key session sees write and paid tools.

First calls after connecting

Start with read-only tools: mcp_health, tools_list, account_me, balance_get. Paid tools such as generate_image and generate_video need an idempotency_key, and the docs recommend dry_run=true or generation_admission_preview before an expensive burst. The key is a transport and dedup value, not approval, so a human still has to decide to spend.

If a call hangs, remember the wait limits. Sume's jobs_wait tool holds at most 55 seconds per call on remote MCP, with 50 as the default. Retry the wait with the same ids and never submit the paid create again; a client-side timeout does not cancel a job, and the job keeps running and billing.

Common mistakes with this setup

Three mistakes come up with input-based headers. First, naming the input differently in inputs and in ${input:...}, which leaves the header empty and the server answering 401. Second, pasting the key with a trailing space, which fails the same way. Third, leaving a stale entry in user-level config that points at a different URL, so the workspace file looks right but another server wins.

The fix for all three is the same: after editing, run **MCP: Reset Trust**, reconnect, and call mcp_health. Its authenticated.auth_source field tells you which credential the endpoint actually saw. Sume's docs say it should read mcp_oauth for an OAuth session, so an unexpected value is a quick sign that the wrong entry won.