Cline MCP: Setup + Use Cases (2026)

You ask Cline to fix a bug in your billing code. It reads the file, spots the logic, and writes a patch. Good. Then you ask it to check the actual failing row in your production database, and it stops. It cannot. The agent lives in your editor and knows your files, but it has no line to anything outside them. That wall is the exact thing MCP tears down.

Cline is an open-source AI coding agent that runs as a sidebar in VS Code. It has the deepest MCP support of any coding tool, and it goes one step past the rest. It can connect to MCP servers like every other client, and it can also build brand-new ones for you from a plain-language description.

This guide covers what Cline MCP actually does, the three ways to add a server, the two very different things “cline mcp” can mean, the use cases that earn their slot, and the mistakes that trip people up before they ship a single tool.

What Cline MCP actually does

The Model Context Protocol is an open standard Anthropic released in late 2024. It defines how an AI client talks to an external tool. A server exposes a set of tools, the client calls them mid-task, and the results flow straight back into the model’s reasoning. No copy-paste, no tab-switching.

Cline is the client. It is an open-source coding agent with over five million installs, running inside VS Code and also on JetBrains, Cursor, Windsurf, Neovim, and a preview CLI. When you connect an MCP server, Cline reads the list of tools that server offers and can call any of them in the middle of a coding job.

That changes what the agent can reach. Out of the box, Cline sees your open files and your terminal. Connect a Postgres MCP server and it can query your real schema. Connect a GitHub server and it can read issues and open pull requests. Connect a docs server and it can look things up while it codes. The editor stops being a sealed box and starts being a hub with wires running out to everything else you work with. The full reference lives in the Cline MCP docs.

Cline supports all three MCP transports. Local stdio servers run as a process on your machine. Remote servers talk over HTTP, either the recommended streamable HTTP or the legacy SSE. Local is right for anything tied to your machine or your credentials. Remote is right when you want one hosted endpoint you can point every tool at.

”Cline MCP” means two things

Here is the split that trips people up, and it is worth clearing up before you touch a config file.

Consuming MCP servers. Connecting Cline to servers other people built, so the agent can use their tools. Your database, your Notion, your bookmarks. This is what almost everyone searching “cline mcp” wants, and it is the bulk of this guide.

Cline building an MCP server. This is the part that is unique to Cline. You describe a tool you wish you had, and Cline writes the MCP server for it and installs it, all from the same chat. Want a tool that hits your internal pricing API? Describe it. Cline scaffolds the server, writes the code, and wires it into your config.

Most clients only do the first. Cursor, Claude Desktop, and VS Code with Copilot all consume servers well, which we cover in which AI tools support MCP, but none of them will turn a sentence into a running server for you. Cline’s take is that if the agent can write code, it should be able to write its own tools. That is a genuinely different idea, and it is the reason Cline gets called out as the most developed MCP client. Treat the built server as a first draft, not a finished product, and it is a real head start.

How to add an MCP server to Cline

The connection details differ by route, but the destination is the same list of servers Cline reads on startup. Here are the three doors in.

The fast path: the marketplace. Open the Cline panel in VS Code, click the MCP Servers icon, and open the Marketplace tab. You can browse by category or sort by most installs, newest, or GitHub stars. Click Install on a server and Cline handles the setup, prompting you for any credentials it needs. This is the lowest-friction MCP install of any client, and the Cline MCP Marketplace is a curated catalog, not a raw dump of everything.

The full-control path: the JSON. In the MCP panel, open the Configure tab and click Configure MCP Servers. That opens cline_mcp_settings.json. Add an entry under mcpServers with a command and args for a local server, or a url for a remote one. This is where you drop in a server the marketplace does not carry, or one you built yourself. The preview CLI reads from ~/.cline/mcp.json instead, and you can symlink one file across Cline, Cursor, and Claude Code if you want a single source of truth.

The hosted path: Remote Servers. For a server that lives at a URL, open the Remote Servers tab, enter a name and the full endpoint URL, and click Add Server. Set "type": "streamableHttp" explicitly, because leaving it off defaults to the legacy SSE transport for backward compatibility. This is the tab you use for a hosted bookmarks endpoint or any SaaS MCP server.

Since Cline runs inside VS Code, the same editor can also run VS Code’s own Copilot MCP support side by side. The two are separate systems in the same window, which we untangle in the VS Code MCP setup guide.

What you can actually do with it once connected

A connected agent feels abstract until you have used it for a week. Here is the short list of what people reach for.

Query real data while you code. “Why is this user’s subscription showing as expired?” With a database MCP server connected, Cline reads the actual row instead of guessing from the schema. The bug hunt that used to bounce between your editor and a SQL console happens in one place.

Open a pull request without leaving the task. Connect a GitHub server and Cline can read the open issue, write the fix, and open the PR against it, narrating each step. The agent stops being a code generator and starts being something that closes the loop.

Look things up mid-build. A docs or web-search MCP server means Cline can check the current API for a library it is using instead of hallucinating a method that was removed two versions ago. Fresh facts beat confident guesses.

Build the tool you are missing. This is the Cline-only move. Halfway through a task you realize you need a tool that does not exist. You describe it, Cline builds the MCP server, and the tool is available in the same session. Read the generated code first, then use it.

“Read the failing test, check the matching row in the staging database, and tell me why they disagree.”

That single prompt spans the editor, the test runner, and a live database. Without MCP, it is three tools and a lot of copy-paste. With it, it is one line.

Where Cline MCP still needs a human

Honest limits, because a coding agent with live tool access can do real damage if you trust it blindly.

One-click installs skip the vetting step. The marketplace makes adding a server feel like adding a browser extension. It is not the same risk. An MCP server can read data and run actions. Convenience is not the same as safety, and the fastest install is also the one where you are least likely to read what you just granted. Check what a server does before you connect it. The is MCP safe breakdown covers what to look for.

Auto-approve is a loaded gun. Cline lets you whitelist tools so they run without asking. That is great for a read-only search tool and dangerous for anything that writes or deletes. Reserve auto-approve for tools that cannot break anything. Make write actions ask every time.

A generated server is a draft, not a finished tool. Cline building a server for you is a head start, not a delivery. It can miss an edge case, over-scope a permission, or skip error handling. Read the code. You would review a junior’s pull request; review this the same way.

It answers, it does not watch. MCP is request-and-response. Cline calls a tool when you ask. It does not sit in the background and ping you when a build breaks or a metric moves. That is a job for monitoring, not for an agent in your editor.

The mistakes that break Cline MCP setups

The same handful of issues come up over and over.

Forgetting the transport type. Add a remote server without "type": "streamableHttp" and Cline falls back to the legacy SSE transport. Some servers no longer speak it, and you get a connection that silently never works. Set it explicitly.

Editing the wrong config. The VS Code extension reads cline_mcp_settings.json. The CLI reads ~/.cline/mcp.json. Edit one while running the other and nothing happens. Confirm which one your Cline is using before you paste anything in.

Pasting a secret into a shared file. API keys belong in environment variables, not committed into a settings file that ends up in a repo. Cline supports env-var references. Use them, especially on any config you sync across machines.

Running too many servers at once. Each server is a process with startup and memory cost, and every tool it exposes eats into the model’s context. Past ten servers you feel it. Three to six is the sweet spot. For picks worth the slot, see the best MCP servers for knowledge workers.

Confusing the two “cline mcp” things. People set out to connect a server, land in the build-your-own-server docs, and conclude the whole thing is hard. It is not. If you just want to plug in an existing server, ignore everything about generating one.

Why your saved research belongs next to your code

Here is the gap nobody setting up Cline MCP talks about. Your repo is only half of what you know about your own project.

The other half is everything you saved and never filed. The X thread where someone explained the exact race condition you are staring at. The Reddit post with the migration gotcha buried in the comments. The LinkedIn post from an engineer you follow about a caching bug that looks a lot like yours. That context shapes how you fix things, and none of it is in your codebase. It is trapped in a bookmarks tab across three platforms.

Cline gives the agent your files, your terminal, and whatever servers you wired up. It does not give the agent the scattered fixes you collected along the way. So you get an assistant that can read the error but has never seen the thread that solved it last time.

This is where a bookmarks MCP earns a slot next to your dev servers. ContextBolt is a Chrome extension that captures what you save on X, Reddit, and LinkedIn, tags each save by topic automatically, and exposes the whole collection through a personal MCP endpoint. The free Basic tier covers 150 bookmarks. Pro at $6 a month adds unlimited saves, encrypted cloud sync, and the MCP endpoint any client can call.

Add it through the Remote Servers tab, the same way you add any hosted server. Now Cline reads both halves in one prompt. “This function throws on null, and pull anything I saved about handling empty API responses” returns the code and the three threads you bookmarked about that exact problem. Your repo says what broke. Your bookmarks say how you fixed it before. For the bigger picture of feeding an agent your own context, see the personal AI context stack.

The one opinion worth holding

Cline building its own MCP servers is the flashy feature. It is not the one that matters most, and betting on it is a mistake.

The flashy version is the agent conjuring tools out of thin air. The useful version is quieter. Most of the tools you need already exist, built and maintained by people who care about that one integration. Reaching for the generator first means you end up maintaining a half-baked server that does 60 percent of what the official one does. Install first. Generate only when nothing covers the job. That order is the whole discipline.

The other thing worth saying plainly. The server you connect matters more than the client you connect it to. Cline, Cursor, Claude Desktop, and VS Code all read the same servers. Wiring one up pays off across every tool you touch. The same is true for the second half of your context. Connect your code, connect your bookmarks, and the agent finally knows both what broke and how you solved it before. That is the setup. Everything else is detail.