How to Add a Remote MCP Server to Cline

How do I add a remote MCP server to Cline?

Click the MCP Servers icon in Cline's top toolbar, open the Configure tab, and use the Remote Servers tab: enter a server name, the full server URL, set Transport Type to Streamable HTTP, and click Add Server. If you'd rather edit the config directly, the same tab has a Configure MCP Servers button that opens the underlying JSON file, where a remote entry needs "type": "streamableHttp" set explicitly — Cline's docs say omitting it falls back to the legacy SSE transport.

Where the setting actually lives

Cline's MCP settings are reached the same way whether you're adding a local (STDIO) tool or a hosted remote server: MCP Servers icon → Configure tab. From there, the Remote Servers tab is the form-based path for a hosted endpoint, and the Configure MCP Servers button opens the raw JSON for anyone who wants to paste a config block instead.

If you're on the Cline CLI rather than the VS Code extension, servers live in ~/.cline/mcp.json, and cline mcp opens an interactive wizard that can list, add, edit, enable/disable, and delete servers — including prompting for a URL and headers when you choose a remote transport. cline config mcp (or cline config mcp --json) lists servers non-interactively. Cline's docs describe the CLI and the IDE extension as reading "the same server definitions," so a server you add in one shows up in the other only if they share a config file on your machine — check both if a server you added seems to be missing.

The IDE extension's JSON file itself is commonly reported at ~/.cline/data/settings/cline_mcp_settings.json on current builds, with older builds keeping it under VS Code's own global storage for the Cline extension (~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json on macOS, with equivalent paths on Windows and Linux). Cline's own docs page doesn't publish an exact file path for the extension — it routes you through the Configure MCP Servers button instead — so treat the UI button as the reliable path and the file location as a fallback for scripting or version control.

The config

Cline reads remote servers from an mcpServers object, keyed by the name you give the server, with a type, a url, and — only if the server requires a static token — a headers object:

{
  "mcpServers": {
    "my-server": {
      "type": "streamableHttp",
      "url": "https://mcp.example.com/mcp",
      "disabled": false,
      "autoApprove": []
    }
  }
}

The type field is required for Streamable HTTP. Cline's docs are explicit: "The type field selects the transport. Omitting it defaults to the legacy sse transport for backward compatibility, so set type: streamableHttp explicitly for the recommended transport." Leaving it out is the single most common reason a remote server connects to nothing.

If the server issues you a static token rather than running an OAuth flow, add it under headers:

"headers": {
  "Authorization": "Bearer your-token"
}

disabled toggles the server off without deleting it, and autoApprove lists which of the server's tools run without a manual click each time — Cline's own security guidance is to limit that list to tools you'd trust to run unattended.

Worth knowing if you're moving a config between editors: type: streamableHttp is Cline's own spelling. VS Code and Visual Studio use "type": "http"; Continue and Zoo Code use "streamable-http" with a hyphen; OpenCode uses "type": "remote"; Gemini CLI and Qwen Code use httpUrl instead of a type field, treating plain url as legacy SSE; and Cursor, Zed, JetBrains, and Claude Desktop take a plain url with no type key at all. Copying a working block from one of those editors into Cline's config will save without error and then silently fall back to SSE — check that type reads exactly streamableHttp before assuming the config is wrong.

Authorization

What happens after you click Add Server depends on how the server itself is built, and Cline's documentation and its GitHub changelog describe two different mechanisms rather than one:

• Static token servers use the headers field above — you paste a Bearer token you already have, and there's no browser step.
• OAuth-capable servers open a browser tab for you to sign in and approve, without any headers entry. Cline's GitHub changelog records version 4.1.7 adding "support for pre-registered OAuth clients for remote MCP servers, for setups where dynamic client registration isn't available," and a fix in the same release to "surface OAuth authorization for SSE MCP servers on a 401 instead of failing outright." Cline's MCP docs page itself doesn't describe this flow — the changelog and the project's GitHub issue tracker are the primary source for how OAuth behaves in Cline.

If a server that previously worked starts failing with an authorization error, that's usually an expired token rather than a broken config — delete the server and re-add it to force a fresh OAuth exchange, rather than editing the JSON.

What usually goes wrong

Symptom	Cause and fix
Connects, then fails immediately	Missing or misspelled type. Without "type": "streamableHttp" (exact camelCase), Cline falls back to the legacy sse transport and a Streamable HTTP server won't answer it.
"Unauthorized" or 401 after it worked before	The OAuth token expired. Delete the server and re-add it to run a fresh authorization; Cline's 4.1.7 release specifically improved how 401s surface for MCP servers instead of failing silently.
Server added but no tools appear	Confirm the server started — Cline's docs point to checking that it's enabled (disabled: false) and that the process or endpoint is actually reachable, then restart the session, since tool lists commonly refresh only at session start.
Tool calls sit there doing nothing	Check for Cline's per-call approval prompt. Approve the call, or add the tool to autoApprove once you trust it — Cline's own guidance is to keep that list limited to safe tools.
Unresponsive server	Use the restart control in MCP settings rather than deleting and re-adding, unless you also need a fresh OAuth exchange.

A worked example

To make the above concrete, here's what it looks like with a real server. Tempreon is a hosted MCP server that gives whichever AI tool you're working in a persistent memory of how you work, and its server supports OAuth, so the example needs no headers entry:

{
  "mcpServers": {
    "tempreon": {
      "type": "streamableHttp",
      "url": "https://api.tempreon.com/functions/v1/tempreon-mcp/mcp",
      "disabled": false,
      "autoApprove": []
    }
  }
}

Add that through the Remote Servers tab (or paste it into the JSON via Configure MCP Servers), and Cline opens a browser tab to approve the connection the first time it connects — there's no token to find or paste. A full walkthrough, including what to do if re-authorization ever gets stuck, is in the Cline setup doc.

Any other MCP server that supports Streamable HTTP follows the same shape — swap the name, the URL, and add headers only if that server hands you a static token instead of running OAuth.