Neovim mcphub.nvim: Sume hosted MCP with autoApprove for read tools

Yes, Neovim can use Sume's hosted MCP server through mcphub.nvim. The plugin lists streamable HTTP as its primary transport for remote servers and supports header-based auth, so a servers.json entry with the URL https://mcp.sume.com/mcp and an Authorization: Bearer header is enough. Its autoApprove array then lets you approve Sume's read tools silently while every paid tool still asks first.

The plugin facts come from the mcphub.nvim servers.json page and its README, read on 2026-10-11. Sume's facts come from the OAuth and API keys, tools and gates and quickstart pages. I did not run the plugin; the entry below follows the documented shapes.

What does the servers.json entry look like?

The page gives ~/.config/mcphub/servers.json as the default path and shows a remote server as a url plus optional headers. It also documents VS Code-style ${env:NAME} resolution, so the key can stay in your shell environment instead of the file.

The entry below uses only keys the page shows: url, headers, disabled_tools and autoApprove. The page does not document a timeout field, so there is nothing to set for Sume's 55-second jobs_wait hold; if a call is cut short, call jobs_wait again with the same ids instead of resubmitting.

{
  "mcpServers": {
    "sume": {
      "url": "https://mcp.sume.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SUME_API_KEY}"
      },
      "autoApprove": ["mcp_health", "tools_list", "tools_schema", "account_me", "balance_get", "jobs_status", "jobs_wait", "jobs_result"]
    }
  }
}

How do autoApprove and Sume's gates fit together?

mcphub.nvim's autoApprove can be true for all tools, an array of tool names, or omitted, in which case you confirm each call. Sume has its own gates on top. Write and paid calls must carry an idempotency_key, dry_run=true previews cost without submitting, and max_spend_usd is enforced only when you send it. The two layers do different jobs: the editor decides who presses the button, and Sume's arguments decide what a pressed button can spend.

Keep autoApprove to the names that never spend or change data. Leave generate_image, generate_video, music_create and tts_create out, so the editor asks every time. jobs_wait is safe to approve: it only reads status, and a retry of it never creates a new job.

Which Sume tools can be auto-approved?

The grouping below is taken from Sume's tool inventory, read on 2026-10-11. It is a suggested split, not a Sume or mcphub default.

Can I hide tools instead of approving them?

Yes, two ways. mcphub.nvim has disabled_tools, an array of names to exclude, so the paid tools never reach the model at all. Sume also hides them at the source when you use OAuth: a session with only mcp:read sees read-only tools, and a write or paid call returns insufficient_scope.

The page I read documents header auth and ${env:} but no OAuth fields, and the README's feature table separately lists OAuth with PKCE. If you use the OAuth route, Sume's consent page shows Read locked on and Write off by default; turning Write on exposes the tools that change data. For a Neovim session that only inspects jobs and balance, the header plus disabled_tools is the simpler setup, and the OAuth read-only scope is the stronger one.

What should I check on the first run?

Open the hub, confirm the sume server shows as connected, and call tools_list. Then call mcp_health and read the auth source it reports. If you see only read tools when you expected the full set, the session is read-only; an API key sees everything, an OAuth session sees what the consent page granted.

For the first paid call, ask for dry_run=true and read the estimate before submitting. Sume's docs recommend a dry run or generation_admission_preview before the first paid submit, and a stable idempotency_key so a retry cannot create a second job.