Mistral Vibe MCP has no OAuth yet: connect Sume with an API key

To connect Mistral Vibe to Sume you must use an API key, because Vibe's MCP docs say the CLI does not yet support MCP servers that require OAuth authentication (read 2026-10-03). Add a [[mcp_servers]] table to config.toml with transport = "streamable-http", the URL https://mcp.sume.com/mcp, and the key read from an environment variable. Sume accepts a key as Authorization: Bearer <key> or as x-api-key, so either header style works.

The Vibe facts come from the Vibe MCP servers page; the Sume facts come from MCP OAuth and API keys and MCP tools and gates. Sume does not document a Vibe-specific setup, so this is a generic HTTP MCP client configuration using fields Vibe lists.

The config block

Vibe lists three transports (http, streamable-http, and stdio) and, for authentication, an environment variable name plus header name and format fields. Sume's endpoint is a remote streamable HTTP MCP server, so the streamable-http transport is the natural fit. Put the secret in your shell profile or secret manager and let Vibe read it by name, so the key never lands in a file you commit.

[[mcp_servers]]
name = "sume"
transport = "streamable-http"
url = "https://mcp.sume.com/mcp"
api_key_env = "SUME_API_KEY"
api_key_header = "Authorization"
api_key_format = "Bearer {token}"

Vibe looks for ./.vibe/config.toml first and then ~/.vibe/config.toml, so a project-level file overrides your global one. Prefer the global file for a personal key, and keep the project file free of credentials. Vibe also lists optional fields such as startup_timeout_sec and tool_timeout_sec; raise the tool timeout if you intend to call jobs_wait, which Sume holds for up to 55 seconds per call.

What an API key unlocks

An API-key session sees the full hosted tool set, including paid creates, so the credential is more powerful than the default OAuth grant, which is read-only. Every write or paid tool needs an idempotency_key; dry_run previews the cost without submitting; max_spend_usd caps a call when you pass it. There is no mcp:paid scope, so spend is governed by wallet and admission, not by a scope.

Because Vibe cannot do OAuth, you cannot pick the read-only posture by clicking through consent. You get it by controlling the tool list, which the companion post on glob permissions covers.

First calls after connecting

Ask Vibe to call mcp_health, which reports the auth source and safety posture, then tools_list, which shows what this session can call. Under an API key, authenticated.auth_source will not read as OAuth. If both calls work, you can move on to a dry_run=true preview of one generation before paying for anything.

If the server does not connect, check the basics in order: the variable is exported in the shell that launched Vibe, the value has no stray whitespace from a paste, and the header format produced Bearer followed by the key. Sume tells you to rotate any key that appears in logs, so do not debug by echoing it.

Limits worth knowing before you rely on it

Static-key access has three practical limits. First, the key is a long-lived credential, so its blast radius is the whole wallet it draws from. Create a key for this one client in the dashboard so you can revoke it without touching anything else, and keep a note of which machine holds it. Second, Vibe cannot ask you for consent per tool, so the person-level choice that OAuth gives you, read-only unless you turn Write on, is not available. Third, an environment variable is only as private as the shell that exports it, so avoid exporting the key in a shared profile on a machine others log into.

If OAuth support lands in Vibe, switch: the default grant is read-only, the token stays in the client, and nothing needs rotating when someone leaves. Until then, the static route is a fair trade for a personal terminal tool, provided the tool list is narrowed and a person confirms every paid step. A good habit is to run balance_get before and after a session, because it is a free read and gives you a spend number that does not depend on the model's own account of what it did.