Flowise Custom MCP: connect Sume over Streamable HTTP

In Flowise, add a Custom MCP tool to an Agent node, paste a JSON config with url set to https://mcp.sume.com/mcp and an Authorization header that reads a Flowise variable, then refresh Available Actions to pull in the tools. Flowise's docs recommend Streamable HTTP for remote servers, which is what Sume's hosted endpoint speaks.

The three steps are short. The decisions that matter are which key you store, which of Sume's tools you leave enabled, and how an agent node should treat a paid tool.

What are the exact Flowise steps?

Per the Flowise Tools & MCP page, read on 2026-10-02: first create a variable holding your token, which you reference as {{$vars.variableName}}; then add a Custom MCP tool to an Agent node using a JSON config with a url and a headers object; then refresh Available Actions, and Flowise pulls in every action the server exposes. The page notes this approach needs nothing installed locally and that updates on a remote server apply automatically.

For Sume the variable holds an API key from the dashboard, and the config is:

{
  "url": "https://mcp.sume.com/mcp",
  "headers": {
    "Authorization": "Bearer {{$vars.sumeApiKey}}"
  }
}

Why a variable and not an inline key?

A flow definition gets exported, shared and committed. An inline key travels with it. A Flowise variable keeps the secret out of the exported JSON, and the reference syntax is the same one the docs use for a GitHub token. Rotate the key in one place if it ever appears in a log or chat; Sume's docs advise rotating an API key that shows up in either (OAuth and API keys).

The other credential type, OAuth, needs an interactive sign-in on Sume's MCP consent page. A Flowise server running a chatflow has no browser for that, so the static header is the practical choice, with the trade-off that an API-key session sees the full tool set including paid tools.

What shows up after Refresh Available Actions?

Whatever the session can see. Sume returns a scope-filtered list, so with an API key you get the full hosted registry: generation, assets, jobs, crawl, avatars, timeline and inspect tools. tools_list includes safety metadata, and tools_schema returns one tool's contract by name (MCP tools and gates).

• Keep: generation_admission_preview, generate_image, jobs_wait, jobs_result, balance_get.
• Consider removing: jobs_cancel, assets_create and any tool the chatflow's purpose does not need.
• Expect video_analyze and video_segment to be absent; the docs list them as dev-only.

How should an agent node call a paid tool?

Write the rules into the agent's system message because the node will not enforce them. Every paid or write call needs an idempotency_key; the docs describe it as transport and dedup, not human approval. Ask for a generation_admission_preview or dry_run=true first, and pass max_spend_usd, which Sume enforces only when it is present.

For waits, jobs_wait holds up to 55 seconds and may return wait_slice_expired. The agent should call it again with the same ids and must not resubmit the create (Jobs and results). Flowise's page does not state a tool-call timeout for MCP, so test a slow job once before you ship the flow.

What should you test before shipping the flow?

Run three checks in the Flowise preview before you expose the chatflow. They cost nothing, because none of them submits a paid job.

• Ask the agent to call mcp_health and read back the auth source and safety posture. It confirms the key reached Sume and that the session is what you think it is.
• Ask for a generation_admission_preview of one image. It returns an estimate and balance behaviour without submitting.
• Ask it to call jobs_list. An empty list on a new account is fine; the point is that a read tool round-trips through the variable-based header.
• If a tool is missing after you refresh Available Actions, compare against tools_list from a direct call, because Sume's list depends on the session's credential and scope, not on the client.