Cline MCP Server Setup 2026: cline_mcp_settings.json Configuration Guide
Configure MCP servers in Cline, the open-source VS Code AI agent: the cline_mcp_settings.json schema for local stdio servers and remote Streamable HTTP/SSE servers, plus the CLI wizard and common connection errors.
How do you set up an MCP server in Cline? Open the Cline panel in VS Code, click the MCP Servers icon in the top toolbar, open the Configure tab, and select Configure MCP Servers — that opens cline_mcp_settings.json. Add an entry under the top-level mcpServers key: local servers need command and args; remote servers need type (streamableHttp or sse) and url. Save the file and restart VS Code completely — a reload window isn't always enough for Cline to pick up new servers.
Cline is the open-source autonomous coding agent for VS Code (formerly Claude Dev). Its MCP config is its own JSON file, separate from Cursor's mcp.json or Claude Desktop's claude_desktop_config.json — a config block copied from one of those won't drop in unmodified.
Quick reference
| Settings file (IDE extension) | cline_mcp_settings.json, opened via the Cline panel |
| Settings file (CLI) | ~/.cline/mcp.json |
| Local server required fields | command, args |
| Remote server required fields | type, url |
| Remote transport values | streamableHttp (recommended), sse (legacy) |
| Optional fields | env, headers, disabled, autoApprove |
| CLI wizard | cline mcp |
Prerequisites
npx, or Docker if it runs as a container.Opening the config file
From the Cline panel:
1. Click the MCP Servers icon (the stacked-server icon) in the Cline panel's top toolbar.
2. Open the Configure tab.
3. Click Configure MCP Servers — this opens cline_mcp_settings.json in the editor.
Alternatively, from VS Code's Command Palette (Cmd/Ctrl+Shift+P): Preferences: Open Settings (JSON), then locate the cline.mcpServers key if you'd rather edit through VS Code's own settings JSON.
Adding a local (stdio) server
Local servers run as a subprocess Cline starts and manages. Required fields are command and args; env, disabled, and autoApprove are optional:
{
"mcpServers": {
"filesystem": {
"command": "node",
"args": ["/path/to/server.js"],
"env": {
"API_KEY": "your_api_key"
},
"disabled": false,
"autoApprove": []
}
}
}
autoApprove takes an array of tool names Cline can call without prompting for confirmation each time — leave it empty until you trust a given tool's behavior, then add names one at a time rather than approving everything up front.
For an npx-based server, command is npx and the package (plus any flags) goes in args:
{
"mcpServers": {
"sqlite": {
"command": "uvx",
"args": ["mcp-server-sqlite", "--db-path", "/path/to/database.db"],
"disabled": false,
"autoApprove": []
}
}
}
(See SQLite MCP Server Setup for the full walkthrough on that specific server.)
Adding a remote (HTTP) server
Remote servers connect over a URL instead of running locally. Required fields are type and url:
{
"mcpServers": {
"remote-server": {
"type": "streamableHttp",
"url": "https://example.com/mcp",
"headers": {
"Authorization": "Bearer your-token"
},
"disabled": false,
"autoApprove": []
}
}
}
Set type explicitly. Omitting it defaults to the legacy sse transport for backward compatibility, not the current recommended one — if a server's docs recommend Streamable HTTP, write "type": "streamableHttp" rather than leaving the field out. Use "type": "sse" only when a server specifically documents SSE as its transport.
You can also add a remote server without touching JSON directly: open the Remote Servers tab in the same Configure panel and fill in a server name, URL, and transport type, then click Add Server — Cline writes the same JSON structure for you.
The CLI wizard
If you're on Cline's CLI rather than (or alongside) the VS Code extension, servers live at ~/.cline/mcp.json, and the interactive wizard covers the same operations without hand-editing JSON:
cline mcp
The wizard supports listing, adding, editing, enabling/disabling, and deleting servers.
Practical workflows once a server is connected
Filesystem access for local project analysis:
Read every .env.example file in this repo and tell me which variables aren't documented in the README.
A remote server behind auth:
Use the linear server to list issues assigned to me labeled "bug".
A database server for schema-aware edits:
Look at the users table schema through the sqlite server, then write a migration that adds a nullable last_login_at column.
Cline prompts for approval on tool calls not covered by autoApprove. Keep destructive or write-capable tools out of autoApprove until you've watched them run correctly a few times.
Troubleshooting
Cline doesn't recognize a newly added server. Restart VS Code completely — quit and reopen the application, not just "Reload Window." Cline's MCP client connections are established at extension activation, and a window reload doesn't always retrigger that for a server added mid-session.
JSON edits don't seem to load. Confirm you edited the file the Cline panel actually reads — cline_mcp_settings.json opened via the panel's Configure button, not a random settings file with a similar name elsewhere in your VS Code config directories. If you went through VS Code's own Settings (JSON) instead, confirm the key is exactly cline.mcpServers and nested correctly; a misplaced key is silently ignored rather than erroring.
Remote server won't connect and you didn't set type. You're on the legacy sse transport by default. If the server's own docs specify Streamable HTTP, add "type": "streamableHttp" explicitly — the default isn't always the fastest or most current option, just the backward-compatible one.
Local server exits immediately. Run the exact command and args combination directly in a terminal outside Cline. If it errors there too, the problem is the server itself (missing dependency, wrong path, missing required env var) rather than the Cline config wrapping it.
Tool calls keep asking for approval even though you added the tool name to autoApprove. Tool names in autoApprove must match exactly what the server registers, which isn't always the same as the human-readable label shown in Cline's UI — check the server's own tool list (via its docs or its startup log) for the literal tool name string.
Environment variables aren't reaching a local server. They go in the env object of that server's entry, not your shell profile — Cline spawns the process directly and doesn't inherit interactive-shell environment setup the way a terminal session would.
When not to use auto-approve broadly
Setting autoApprove to every tool a server exposes turns Cline from "asks before it acts" into "acts, then tells you." That's a reasonable trade for read-only tools like list_tables or get_issue. It's a much worse trade for anything that writes — write_query, create_pull_request, delete_file — where a wrong call executes before you'd have had a chance to catch it in a normal review. Scope auto-approval per tool, not per server.
Frequently Asked Questions
Where exactly does cline_mcp_settings.json live? It's managed through the Cline panel's Configure MCP Servers button rather than a fixed path you're expected to navigate to manually — open it from the extension's MCP Servers icon. The CLI equivalent is the fixed path ~/.cline/mcp.json.
What's the difference between Streamable HTTP and SSE for a remote server? Streamable HTTP is the current recommended transport for hosted MCP servers; SSE is the legacy option kept for backward compatibility. If you don't set type explicitly, Cline defaults to SSE — set "type": "streamableHttp" if the server you're connecting to supports it.
Does Cline support the same mcp.json format as Cursor or Claude Desktop? No, not directly. Cline's schema (mcpServers with command/args for local servers, type/url for remote ones) is close in spirit to other clients' formats but not byte-for-byte identical — check field names like type and autoApprove specifically, since those aren't universal across clients.
Can I disable a server without deleting its config? Yes — set "disabled": true on that server's entry rather than removing it. This keeps the configuration (URL, command, env vars) in place for when you want to re-enable it.