Cline MCP server not connecting, or no servers loading: the fixes

Edit the file Cline reads

Cline 4.0 moved MCP settings to one shared file for the VS Code extension, the CLI and JetBrains: ~/.cline/data/settings/cline_mcp_settings.json. CLINE_MCP_SETTINGS_PATH points Cline at another file, and CLINE_DATA_DIR or CLINE_DIR move the folder it sits in.

• Older extension versions kept the file in VS Code's own storage, for example ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json on macOS. Cline 4.0 copies the servers from there, and from ~/Documents/Cline/MCP/cline_mcp_settings.json, into the shared file once, and leaves the old files in place. Edits to an old file do nothing now.
• The copy skips any server whose name already exists in the shared file. If a server you fixed in the old file still fails, the shared file holds an older entry under the same name.
• The safe way in is the panel: click the MCP Servers icon, open Configure, then Configure MCP Servers. That opens the file the running Cline uses. In the CLI, cline config mcp lists the servers it loaded, with --json for the raw config.

No servers load at all

Cline validates the whole file before it starts any server, so one broken entry takes every server down with it. The extension shows "Invalid JSON in MCP settings file" for a syntax error, and an "MCP settings schema error" notice that says no servers were loaded, naming the server and field, for a wrong field. Versions before 4.0 said "Invalid MCP settings format" instead. The CLI reports the same problems as Failed to parse MCP settings JSON or Invalid MCP settings, followed by the path.

• Servers go under a top-level mcpServers object. A file copied from VS Code's mcp.json uses servers, which Cline doesn't read.
• type accepts three values: stdio, sse and streamableHttp. "type": "http", the form Claude Code and VS Code use, fails validation in Cline and so blocks every server in the file.
• Trailing commas and comments are JSON syntax errors here. Paste the file into a JSON validator if the notice doesn't say which line.
• headers and env are objects of strings. A number or a nested object in either one fails the schema check.

Remote servers need type streamableHttp

Cline picks the transport from type. For an entry with a url and no type, Cline uses the legacy SSE transport, a choice its source keeps on purpose so old configs don't break, and its docs ask you to set "type": "streamableHttp" explicitly. Many remote servers speak only Streamable HTTP, and for those an entry without type connects to nothing: the SSE client opens a GET request that a Streamable HTTP endpoint refuses, often with a 405.

{
  "mcpServers": {
    "my-remote": {
      "type": "streamableHttp",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer ${env:MY_SERVICE_TOKEN}" },
      "disabled": false,
      "timeout": 60
    },
    "my-local": {
      "command": "npx",
      "args": ["-y", "some-mcp-server"],
      "env": { "API_KEY": "your_api_key" }
    }
  }
}

• Use the server's final address. A redirect to another host drops the Authorization header.
• The CLI can write the entry for you: cline mcp add my-remote https://mcp.example.com/mcp --transport http --header "Authorization: Bearer TOKEN" --yes. It stores the same fields nested under a transport object, which the extension reads too.
• In the Remote Servers tab, Transport Type offers Streamable HTTP (recommended) and SSE (Legacy). Pick SSE only for a server that documents it.

Headers and keys that don't arrive

• The extension replaces ${env:NAME} in the file with that environment variable. A variable that isn't set stays in the header as literal text, so the server receives "Bearer ${env:NAME}" and rejects it. Cline logs a warning naming the variable.
• The variable has to exist in the environment VS Code started with. If you set it in a shell profile after opening VS Code, quit VS Code completely and start it again.
• Keep secrets out of a project's .cline/ folder if you commit it. The MCP settings file in your home folder is the place for them.
• On a 401, Cline can start an OAuth sign-in for a remote server that supports it, and the CLI wizard has an Authorize OAuth action. A server that takes an API key needs it in headers instead; a sign-in prompt from such a server points at a missing or misspelled header.

disabled, timeout and autoApprove

• "disabled": true keeps the entry and stops Cline from starting it. The server still shows in the MCP Servers list, switched off, so a server you can see but never connects is worth checking for this flag.
• timeout is in seconds per request, 60 by default, clamped between 1 and 3600. A value such as 60000, written in milliseconds by habit, becomes 3600 rather than 60 seconds. Remote servers also get a 10 second budget to connect at session start, so one unreachable server no longer stalls the start of a session.
• autoApprove is a list of tool names, and older guides tell you to fill it in. Since Cline 4.1.15, the Use MCP servers toggle in auto-approve settings approves every MCP tool call on its own, and 4.1.16 hid the per-tool checkboxes, which no longer did anything. Leave the array empty and use the toggle, or approve calls one at a time. In Cline 3.x the list still decides which tools skip approval.

Read Cline's logs

The MCP Servers panel shows the error for a server that failed to connect, and Restart Server retries it after you fix the file. The CLI writes its log to ~/.cline/data/logs/cline.log, and cline doctor log opens it. For a remote server, test the URL and header with curl first: a 401 or 403 there is a key problem, not a Cline problem.

Taskhold-specific checks

Taskhold is a remote Streamable HTTP server at https://taskhold.com/api/mcp. When the taskhold tools don't show up in Cline, check these in order:

1. The entry sits under mcpServers with "type": "streamableHttp" and url set to exactly https://taskhold.com/api/mcp. Without type, Cline tries SSE, and Taskhold answers that GET request with 405. The www host redirects and the redirect drops your header.
2. The header is Authorization: Bearer followed by a key that starts with atd_sk_. Taskhold's 401 names the cause: missing_key, bad_header, not_a_taskhold_key or unknown_key. A key written as ${env:TASKHOLD_API_KEY} with the variable unset arrives as literal text and comes back as bad_header.
3. A 402 means the key works but the trial ended or the plan was canceled. Restart the plan and the same config works again.
4. With approvals on, each progress report waits for a click. Turn on Use MCP servers in auto-approve, or the board only moves when you approve.
5. Settings in Taskhold shows Connected once the first call arrives. Ask Cline to call the taskhold list tool to check.

With the tools loaded and the rules file from the Cline page, every task Cline starts, its steps and its questions show on the live board next to your other agents. The same checks for other clients: Claude Code, OpenCode and VS Code Copilot.