Dify MCP client: connect Sume's hosted MCP server

Dify works as an MCP client: in Integrations > Tools you connect a remote MCP server by its URL, a name, and a unique server identifier, and Dify imports the server's tools so Workflow, Chatflow, and Agent apps can call them. Dify supports only servers with HTTP transport. For Sume's hosted MCP server, the URL is https://mcp.sume.com/mcp, and you authenticate with OAuth through Dynamic Client Registration or with a custom Authorization: Bearer header that carries a Sume API key.

Dify's side comes from its Dify Tools page; Sume's side comes from MCP OAuth and API keys, MCP quickstart, MCP tools and gates, and Jobs and results, all read on 2026-09-28. Sume has no official Dify integration: Dify connects to Sume's remote MCP server like any other, and Sume's basics page says hosted MCP still works but is not part of the primary path today. To call Sume's REST API from Dify instead, see Dify custom tool from OpenAPI.

How do I add an MCP server in Dify?

Open Integrations > Tools, connect an MCP server, and fill in the fields below. Dify connects, authorizes if needed, and imports the server's tools. Pick the identifier once: apps reference a server by it, so changing it later stops the server's tools in apps that used the old one, and exported apps need servers with matching identifiers in the other workspace.

Should Dify use OAuth or an API key for Sume?

OAuth if you want a read-only start; an API key if the app has to keep running unattended. Dynamic Client Registration lets Dify obtain OAuth credentials from a server automatically, and Sume's current server advertises a registration endpoint. Consent happens on Sume's MCP host with Read locked on and the Write toggle off by default. With Write off, the session sees only read-only tools, and paid tools such as generate_image return insufficient_scope. Two limits come from Sume's current code: an access token lasts one hour, and Sume issues no refresh token, so expect to authorize again after an hour.

If registration fails, Dify's alternative is to turn it off and enter an existing OAuth app's Client ID and Client Secret. Sume's current server registers only public clients, with token endpoint auth method none, so there is no secret to enter: use a key header instead.

An API key avoids the hourly sign-in. A key session sees Sume's full hosted tool set, paid tools included, and spend resolves to the key's Sume workspace, so every Dify app that uses this server spends from that workspace.

• Dify can fill a header per run: {{request.headers.X-Custom-Auth}} is replaced with that header from the HTTP request that triggered the run, such as a Service API call. A missing header resolves to an empty value, and with no originating request the placeholder text is sent unchanged; either way, that run won't authenticate to Sume.
• Keep the key out of prompts and app inputs, and rotate it if it appears in logs or chat history.

Which Sume tools does a Dify app get?

Whatever the session can see when Dify imports the list, so add only the tools an app needs to its Tool node or agent. Start with mcp_health, which confirms the endpoint, auth source, and safety posture, and tools_list. Dify can update the tool list later to pull the server's latest tools, but that can break an app if a tool it uses was removed or changed.

Every paid Sume tool needs an idempotency_key; dry_run=true previews admission and cost without submitting the job, and max_spend_usd caps a call only when it is sent. In an agent, the model writes those arguments, so instruct it to run dry_run first. Sume MCP tools list groups the hosted tools by read, write, and paid.

What timeout does Dify need for Sume?

More than 55 seconds for job waits. Sume's jobs_wait holds one call for at most 55 seconds, or 50 when timeout_seconds is omitted. Dify's page gives no default for its request timeout and says to change it only if you hit timeout errors, so if jobs_wait calls time out, raise it above 55 seconds.

A client-side timeout does not cancel the job: it keeps running and still bills. On wait_slice_expired, the app should call jobs_wait again with the same ids and never resubmit the paid create. MCP tool call timeouts on long-running video jobs covers the pattern.