Hi, friends, I'm Lena. I didn't set out to spend an entire afternoon rearranging how my agent talks to the outside world. But once I started, I couldn't quite stop.
Something shifts when you realize your AI coding assistant isn't actually limited to what it knows. It can reach into your file system, query your database, fetch live docs, push a GitHub commit -- all inside the same conversation. With Cline and the right MCP servers, that shift happens pretty fast.
This is what I noticed when I started paying attention.
What Is Cline and Why MCP Matters for It
Cline is an open-source autonomous coding agent that runs as a VS Code extension. It's free -- you bring your own API key, and it connects to whatever model you want: Claude, GPT-4o, local models via Ollama. Cline charges nothing on top of provider rates, giving developers full cost control and model independence.
That's the surface layer. The deeper thing is what happens when you add MCP.
How Cline Uses MCP to Call External Tools
Model Context Protocol (MCP) is an open standard Anthropic released for connecting AI models to external tools and services through a consistent interface. Think of it as a standardized plug -- one format, works across environments.
When Cline detects a configured MCP server, it can call tools exposed by that server: read files, query databases, search the web, run scripts. The agent decides when to invoke a tool, you approve it (or enable auto-approve), and the result flows back into context.
After configuring an MCP server, Cline automatically detects available tools and resources. When you type a request in Cline's conversation window, it identifies when an MCP tool can help -- and invokes it after approval.
Why Cline Users Get More from MCP Than Standard Copilot Users
The comparison kept coming up as I looked into this. GitHub Copilot added MCP support in Agent Mode, but it remains more constrained. Cline can both use and create MCP tools with no artificial limits on how many tools you configure. Cursor supports MCP but caps at 40 tools per configuration.
For most people, 40 tools is more than enough. For developers building complex pipelines with dozens of integrations -- database, CI/CD, monitoring, docs -- Cline's uncapped approach matters. There's also something subtler: Cline surfaces detailed permissions for every action, from reading files to controlling the browser. You know exactly what's happening. That level of transparency is genuinely different.
Setting Up MCP Servers in Cline
I'll walk through how this actually works, as of early 2026. The UI has changed a few times, so I'm describing the current flow.
Installing Cline (If Not Installed)
Search for Cline in the VS Code Extensions marketplace, or navigate directly to the Cline VS Code extension page. Install, reload VS Code, and add your API key in the settings panel that opens. That's the whole installation.
Configuring MCP in Cline's Settings
Click the "MCP Servers" icon in the top navigation bar of the Cline extension. Select the "Configure" tab, then click "Configure MCP Servers" at the bottom of the pane. This opens a JSON configuration file using a mcpServers object with named server configurations.
A basic STDIO server entry looks like this:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"],
"disabled": false
}
}
}
For remote servers using SSE transport -- useful for cloud-hosted tools -- you'd swap command and args for a url field and optional headers. The format is a standard across MCP-compatible tools, not just Cline.
One thing I kept getting wrong at first: the path you pass to the filesystem server needs to be an absolute path. Relative paths don't work and fail silently, which is frustrating to debug.
Verifying a Server Is Connected
There's no "server connected" toast notification. What I do: after saving the JSON, I check the MCP Servers panel in Cline -- each server gets its own entry, with a status indicator and a list of tools it's exposing. If the tools appear, the server is live.
You can also ask Cline directly: "What MCP tools do you have access to?" It'll list them. If a tool you expected isn't there, the most common cause is either a bad path, a missing dependency (check Node.js version -- you need 18+), or a misconfigured environment variable.
The Best MCP Servers to Use with Cline
These are real, actively maintained servers. Most come from the official modelcontextprotocol/servers repository, which is the most reliable starting point for anything you want to trust in production.
File System Access
@modelcontextprotocol/server-filesystem -- the one I install first on every project. Gives Cline controlled read/write access to specified directories. You define the scope; the server enforces it. Essential for anything involving multi-file refactoring or searching through logs.
Web Search
@modelcontextprotocol/server-brave-search -- requires a Brave Search API key (free tier available). Adds real-time web search to Cline. I noticed this most on tasks involving libraries with recent API changes -- instead of hallucinating outdated syntax, Cline goes and looks it up.
Git / GitHub
@modelcontextprotocol/server-github -- authenticated via a personal access token. Lets Cline list issues, open PRs, search code across repos, and create commits. The ones I use most: "find all PRs that touched the auth module last month" and "create an issue for this bug with these reproduction steps."
Terminal Access
Cline already has built-in terminal execution. For heavier orchestration -- running test suites, triggering deploys -- a dedicated shell MCP server adds structured control. Worth looking at the community options in the awesome-mcp-servers repository, which is kept reasonably up to date.
Database Connectors
@modelcontextprotocol/server-postgres and @modelcontextprotocol/server-sqlite cover the most common cases. Both support schema inspection and read-only query safety by default -- you explicitly opt in to write operations, which feels like the right default.
Docs Fetchers
Context7 (@upstash/context7-mcp) deserves a mention here. It pulls version-specific library documentation into context on demand. Without it, Cline sometimes generates code using deprecated APIs because its training data is a snapshot. With it, that problem mostly disappears.
Cline vs. Cursor for MCP-Powered Agent Workflows
I want to be direct here, because I've gone back and forth on this.
Both tools offer comprehensive support for MCP servers, whether you use existing ones or build custom servers yourself. However, Cline's MCP support provides a superior user experience -- featuring a dedicated marketplace with filtering options to sort by most installs, date added, GitHub stars, or category.
Cursor has better tab completion and a more polished IDE feel. Its background agents -- tasks that run in cloud VMs while you do something else -- are genuinely useful for long-running jobs. The most popular hybrid setup in 2026 is Cursor as a daily driver IDE for tab completions and quick edits, with Cline inside VS Code for heavy MCP integrations, checkpoint-based workflows, and specific model selection. Since Cline is a VS Code extension and Cursor is a VS Code fork, this combination actually works.
For developers building agent pipelines where MCP depth matters more than autocomplete speed, Cline wins. For developers who want a frictionless IDE with good-enough agent support, Cursor is fine.
What MCP Doesn't Give You
Why Your Cline Agent Resets After Every Session
Here's the part that took me a while to fully register.
MCP gives Cline access to external tools. It doesn't give Cline memory between sessions. When you close and reopen VS Code, Cline doesn't remember what it learned about your project yesterday. The tools are still there. The context isn't.
There's a @modelcontextprotocol/server-memory that provides a persistent knowledge graph across sessions -- it helps. But it's a workaround: you're manually annotating what Cline should remember. It's not the same as a system where successful resolutions accumulate automatically and become reusable.
The agent executes well within a session. It doesn't accumulate capability across sessions. The mcp_settings.json file is a configuration artifact, not an experience record.
I'm not sure I've seen that gap closed cleanly anywhere yet. It's the part I keep coming back to.
FAQ
What is Cline in VS Code?
Cline is a free, open-source autonomous coding agent that runs as a VS Code extension. It supports any model provider, executes multi-step tasks, manages files and terminal commands, and integrates with external tools via MCP. Unlike Copilot, it uses a bring-your-own-key model -- you pay provider API rates directly, with no Cline markup.
How do I add MCP servers to Cline?
Open the Cline extension, click the MCP Servers icon in the top nav, go to the Configure tab, and click "Configure MCP Servers." This opens a JSON file. Add server entries under the mcpServers object, specifying command, args, and any environment variables. Save the file and check the MCP Servers panel to confirm your tools are visible. Use absolute paths with filesystem servers.
Is Cline free?
Yes. Cline itself costs nothing. You pay only for API usage with your own provider keys -- Anthropic, OpenAI, Google, or a local model. This makes costs variable and transparent, unlike subscription-capped tools. Heavy Claude usage can add up, but you control which model runs and when.
I'll keep watching how the session-persistence problem develops. It doesn't feel like a permanent ceiling -- more like the next thing on the list.
