Guide · Cline · VS Code

MCP server with Cline — VS Code extension MCP configuration

Cline is a VS Code extension that functions as an AI coding assistant with full MCP support. Connecting a custom MCP server to Cline lets you surface any external tool — databases, APIs, code analysis services — directly in your coding workflow. Cline manages MCP connections through its own settings panel and a JSON file that sits outside your project, making it easy to add servers without touching VS Code's native settings or any project config. This guide covers the setup, the permission model, and how to validate that your server is reliably available for Cline to call.

TL;DR

Open the Cline sidebar in VS Code, click the MCP Servers icon (plug icon), and add your server via the GUI or by directly editing cline_mcp_settings.json (accessible via the "Open MCP Settings" link in the panel). For local servers: use command + args with an absolute path. For remote servers: use url pointing to your SSE endpoint. After saving, Cline connects immediately — no VS Code restart needed. Verify by checking the server status in the MCP panel. Enable auto-approve for trusted servers to skip per-call confirmation prompts. For remote servers, add your URL to AliveMCP to monitor protocol-level health between sessions.

Finding the MCP settings file

Cline stores MCP server configuration in a file separate from VS Code's settings.json. The file location:

macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Windows: %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

The fastest way to open it is from Cline's MCP panel: click the plug icon in the Cline sidebar, then click "Open MCP Settings" at the top of the panel. This opens the file directly in VS Code's editor.

The settings file is a JSON object with a single mcpServers key — the same format used by Claude Desktop and Cursor:

{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["/path/to/dist/index.js"]
    }
  }
}

Adding a local stdio server

Stdio is the standard transport for MCP servers running locally. Cline spawns the server as a subprocess when connecting and terminates it when the connection is closed. This means your server process lifecycle is tied to the Cline session, not VS Code's lifetime.

{
  "mcpServers": {
    "code-analysis": {
      "command": "node",
      "args": ["/Users/you/projects/code-analysis-mcp/dist/index.js"],
      "env": {
        "NODE_ENV": "production",
        "DATABASE_URL": "postgresql://localhost:5432/analysis",
        "LOG_LEVEL": "warn"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Key fields:

command: Absolute path to the executable. On macOS with nvm or asdf, use the full node path (/Users/you/.nvm/versions/node/v20.11.0/bin/node) rather than node, since Cline's subprocess doesn't inherit your shell's version manager shims.
args: Array of arguments. For compiled TypeScript, point to the compiled JS output. For source-directly-run projects, use npx tsx src/index.ts.
env: Key-value pairs merged into the subprocess environment. Use this for database URLs, API keys, and feature flags your server needs at startup.
disabled: Set to true to keep the server config but temporarily prevent Cline from connecting. Useful for servers under active development.

The server must output only JSON-RPC messages to stdout — any stray console.log output to stdout breaks the protocol. Use stderr for application logging or configure your logger to write to a file.

Adding a remote SSE server

For servers deployed remotely, use the SSE transport with a url field:

{
  "mcpServers": {
    "remote-api-tools": {
      "url": "https://my-mcp-server.fly.dev/sse",
      "headers": {
        "Authorization": "Bearer your-api-key"
      },
      "disabled": false,
      "autoApprove": ["search_docs", "fetch_schema"]
    }
  }
}

Cline sends the headers with every SSE connection and subsequent POST request during the session. This is the right way to pass API keys to authenticated remote servers. Don't commit the settings file to source control if it contains real API keys — the file lives in VS Code's global storage, so it's already outside any project repository, but be careful if you back up your app data.

The url field should point to the SSE endpoint of your server (/sse by convention). Cline handles reconnection automatically if the SSE connection drops during a session.

Auto-approve: skipping per-call confirmation

By default, Cline shows a confirmation dialog before every tool call, letting you approve or reject each invocation. For trusted servers where you don't want to click through approvals, the autoApprove array lists tools that Cline calls without asking:

{
  "mcpServers": {
    "read-only-db": {
      "command": "node",
      "args": ["/path/to/db-query-server/dist/index.js"],
      "autoApprove": ["query_schema", "list_tables", "explain_query"]
    },
    "file-manager": {
      "command": "node",
      "args": ["/path/to/file-server/dist/index.js"],
      "autoApprove": []
    }
  }
}

Use autoApprove only for read-only or reversible operations — queries, lookups, schema reads. Keep mutation operations (writes, deletes, API calls that change state) out of the auto-approve list so you retain visibility and control over side effects during AI-assisted coding sessions.

You can also configure auto-approve from Cline's MCP panel UI: click on a server, expand its tools, and toggle the "Auto-approve" switch per tool without editing the JSON directly.

Enabling and disabling servers

Cline's MCP panel shows all configured servers with a toggle switch. Disabling a server stops Cline from connecting to it without removing the configuration. This is useful for:

Temporarily disabling a slow-starting server while developing a feature that doesn't need it
Keeping multiple server configs for different contexts and switching between them
Preventing Cline from repeatedly trying to reconnect to a server that's undergoing maintenance

The "disabled": true field in the JSON is the persistent form of toggling a server off. Changes to the toggle in the UI write to the JSON file immediately.

Debugging connection issues

Cline surfaces connection errors in the MCP panel's server status area. For deeper debugging:

For stdio servers: Run the server command manually in a terminal. If it starts, connects, and responds to a manual initialize probe, the issue is likely in the Cline config (wrong path, missing env vars). If it fails to start, fix the server first.

npx @modelcontextprotocol/inspector node /path/to/dist/index.js

The MCP inspector opens a browser UI where you can test the initialize handshake and call individual tools — the same sequence Cline runs when connecting.

For SSE servers: Verify the endpoint responds correctly:

curl -N -H "Authorization: Bearer your-key" \
  https://your-server/sse

The response should be a streaming text/event-stream with the MCP initialization sequence. If you see HTML or an error page, the server's SSE route is misconfigured.

Common stdio errors in Cline:

"Server disconnected" immediately after connecting: stdout contamination (console.log in startup path).
"Process exited with code 1": unhandled error during startup. Run the command manually to see the error.
"Timeout waiting for server response": the initialize handler is blocking on an async operation. Add a timeout to all async startup tasks.

See MCP server debugging for a systematic approach to tracking down these failures.

Monitoring remote servers used from Cline

Cline's MCP panel shows server status only when you have VS Code open and the Cline sidebar active. A remote server that goes down between coding sessions won't show an alert until you try to use it and get a connection failure — at which point you're mid-workflow and the failure is disruptive.

For remote MCP servers connected to Cline, add the server URL to AliveMCP. AliveMCP continuously probes the server's SSE endpoint from an external network, running the full initialize → tools/list handshake and alerting you if anything in the protocol chain fails — including TLS certificate expiry, DNS issues, and server crashes. You find out about the outage on your terms, not Cline's.

See MCP server observability for combining AliveMCP's external monitoring with server-side structured logging for complete visibility.