Make MCP token in URL, header or OAuth: which one for Sume workflows

Make offers three ways to connect an AI client to its MCP server, and they are not equivalent. The Make MCP server page lists OAuth at https://mcp.make.com, a token in the URL at https://<ZONE>/mcp/u/<MCP_TOKEN>, and a token in a header at https://<ZONE>/mcp, read 2026-10-03. The transport is stateless Streamable HTTP. If your scenarios call Sume, the choice decides where credentials can leak and how long a tool call may take.

The three styles side by side

Make also notes that run tools are available on all plans and management tools on paid plans. Management tools matter little for a Sume workflow; the run tools are what execute your scenarios.

Why the URL style is the risky one

A token embedded in a URL ends up wherever the URL is stored: config files, shell history, proxy logs and screenshots. The header style keeps the same token out of the path. For a workflow that can start billed Sume generations, treat the Make token as a spending credential and prefer the header or OAuth form. This is a handling recommendation, not something Make's page states.

Keep a separate rule for the Sume side. The Sume authentication docs describe an API key sent as a bearer token or x-api-key, and the SDK docs say the API rejects both at once with a 401 "Send only one API key credential." Inside Make, store the Sume key in the connection or a scenario variable and send exactly one header from the HTTP module.

Matching scopes on the Sume side

If an AI client talks to Sume's hosted MCP server directly instead of through Make, the OAuth page applies: mcp:read is required and gives read-only tools, and mcp:write is opt-in. A write or paid tool under mcp:read returns insufficient_scope. Going through Make adds a second trust boundary, so decide which one owns the spend limits.

Sume's gates still apply inside a scenario that calls the REST API: send an Idempotency-Key on every submit.

A short decision rule

• Interactive client, human present: OAuth, accept the 25-second limit, and make scenarios submit and return.
• Unattended agent, longer scenarios: token in a header, with the token stored in the client's secret store.
• Anything shared or logged: never the URL style.
• Always: the scenario returns a Sume job id quickly, and a second scenario checks status.