2026-10-02

Cline MCP remote not connecting: set type streamableHttp for Sume

Cline treats a remote server with no type as legacy SSE. Sume's hosted MCP is streamable HTTP and answers GET /mcp with 405, so set type to streamableHttp.

5 min readSume

All posts

A Cline remote MCP entry with no type field is treated as the legacy SSE transport, so Sume's hosted MCP server will not connect. Add "type": "streamableHttp" next to the url, and Cline will use the streamable HTTP transport that Sume speaks.

Cline's documentation, Configuring MCP servers, read on 2026-10-02, says the transport defaults to SSE when type is not set. Sume's endpoint and auth come from the MCP overview and OAuth and API keys.

Why does a missing type break the connection?

Cline's page lists two remote transports: Streamable HTTP, which it recommends, and SSE, which it calls legacy. It says that without a type the system defaults to SSE. An SSE client opens the endpoint with a GET and waits for an event stream. Sume's remote endpoint takes its messages as HTTP POSTs, and a GET to /mcp answers 405 with Allow: POST, so an SSE-style client sees a refusal instead of a stream.

The symptom in Cline is a server that shows an error or never leaves the connecting state. The cause is the transport mismatch, not your key, so rotating the key will not help.

Cline remote transport settings (read 2026-10-02)
type value	Transport	Works with Sume
omitted	Legacy SSE (default)	No: Sume does not offer a GET event stream
sse	Legacy SSE	No
streamableHttp	Streamable HTTP	Yes

What does the working entry look like?

Cline's fields for a hosted endpoint are url, optional headers, and type. For Sume with an API key, send exactly one of the two headers Sume accepts: Authorization: Bearer ... or x-api-key. Sume's authentication page says a request carrying both is rejected with 401 unauthorized. For the CLI the file is ~/.cline/mcp.json; in an IDE extension you manage servers through its UI, and the same fields apply.

Keep autoApprove empty for paid tools. Cline's page says that array limits which tools skip the approval prompt, so leaving generate_image and avatars_create out means you see each paid call first.

{
  "mcpServers": {
    "sume": {
      "type": "streamableHttp",
      "url": "https://mcp.sume.com/mcp",
      "headers": { "x-api-key": "YOUR_SUME_API_KEY" },
      "autoApprove": ["tools_list", "mcp_health"]
    }
  }
}

How do I confirm it worked?

Ask Cline to call mcp_health, which Sume documents as the call that confirms the endpoint, the auth source and the safety posture. Then tools_list shows the tools this session can see. An API key sees the full hosted set. If you would rather sign in than paste a key, Cline's page does not describe OAuth in the part I read, so use a key for Cline and keep it out of chat; Sume says to rotate any key that appears in logs.

Which Sume tools belong in autoApprove?

Cline's autoApprove array limits which tools skip the approval prompt. Put only read tools in it. Sume says its read tools are free to call; paid tools need an idempotency_key and spend from your wallet, so you want to see each of those before it runs.

Suggested autoApprove split for Sume's tools (read 2026-10-02)
Tool	Kind	autoApprove?
tools_list, tools_schema, mcp_health	Discovery, read-only	Yes
jobs_status, jobs_wait, jobs_result	Job reads	Yes
generate_image, generate_video, tts_create	Paid, needs idempotency_key	No
jobs_cancel, assets_create	Write, needs idempotency_key	No

What if it still fails?

Check the URL first: it is https://mcp.sume.com/mcp with no trailing path. Then check that you did not send both auth headers. Then check the type spelling, which Cline documents as streamableHttp. If a long video job seems to hang, that is a separate matter: a wait on a job returns within 55 seconds, and you repeat it.

What does this not cover?

Cline's transport defaults are Cline's to change; re-read its page if a new release changes them. Sume does not offer an SSE endpoint, so there is no Sume-side setting to make an SSE entry work.