Mistral connectors: confirm Sume's paid tools before they run

Add Sume to Mistral as a Custom MCP connector pointing at https://mcp.sume.com/mcp, then pass it to a conversation as {"type": "connector", "connector_id": ...} with a tool_configuration that lists the tools you want in include and sets requires_confirmation to true. Mistral's docs describe that confirmation flag as useful for sensitive actions, and a paid image or video job is exactly that.

Mistral has two doors into the same connector: the Le Chat connectors page and the API. The setup below happens once and the gating happens per request.

How do you add Sume as a custom connector?

Per Mistral's MCP Connectors page, read on 2026-10-02: open the Connectors page, click Add Connector, choose the Custom MCP Connector tab, and fill in a connector name (unique, no spaces or special characters) and the server URL. Click Connect, and the platform detects the authentication method. The page lists three: none, an HTTP Bearer token or Basic auth, and OAuth 2.1 with dynamic client registration.

Two caveats from that page. Adding a custom connector is administrator-only, and on Free, Pro and Student plans the account owner is the administrator by default. And Mistral states that connectors are not Mistral products and that you should connect only to servers you trust.

• Name: something short such as sume, because the same name is your connector_id later.
• URL: https://mcp.sume.com/mcp. Sume's docs say to use that production URL in remote MCP clients.
• Auth: Sume serves OAuth metadata from the MCP host and also accepts a bearer API key. Which one Mistral picks during detection is not stated on the pages read here, so check the screen you land on.

What changes with OAuth versus an API key?

Sume's hosted MCP treats the two credentials differently, and Mistral's confirmation flag does not change that. With OAuth the default grant is mcp:read, so only read-only tools are visible and a paid call returns insufficient_scope. Write is a toggle on Sume's consent page and turns on mcp:write, which exposes mutating and paid tools. With an API key the full hosted tool set is visible from the first call (OAuth and API keys).

How do include and requires_confirmation work?

From Mistral's conversations page: tool_configuration takes either include (an allowlist) or exclude (a blocklist), "but not both at the same time", and an optional requires_confirmation. The page does not say whether confirmation can be set for one tool inside an entry, so treat it as applying to the whole entry, and read Mistral's human-in-the-loop page for how an approval is returned before you build a UI around it.

For Sume that suggests two requests rather than one. A research turn includes only the read tools and no confirmation. A generation turn includes the admission preview, the one paid create, and the job reads, with confirmation on, so a person sees each call before it spends credits.

tools = [
    {
        "type": "connector",
        "connector_id": "sume",
        "tool_configuration": {
            "include": [
                "generation_admission_preview",
                "generate_image",
                "jobs_wait",
                "jobs_result",
            ],
            "requires_confirmation": True,
        },
    },
]

What still protects you after someone clicks approve?

Approval answers "should this run", not "how much" or "what if it runs twice". Sume's gates cover those. Every write and paid tool needs an idempotency_key, which dedups a replay but is not human approval. dry_run=true previews cost without submitting. max_spend_usd caps a call, but only when it is passed. Put those three in your system message so the model supplies them in the call a person is about to approve.

Long jobs need a second habit. One jobs_wait call holds for at most 55 seconds and returns wait_slice_expired when the slice ends; call it again with the same ids rather than resubmitting the paid create (Jobs and results). If every one of those calls triggers a prompt in your setup, keep job reads in a second request without confirmation, since they are read-only and cannot spend.