Which AI Coding Tools Actually Support MCP?

"Which AI coding tools actually support MCP?" is worth answering carefully, because "support" gets used loosely — some tools built MCP in from the start, some added it as a feature update, and some third-party ecosystem tools support it unofficially through plugins. The gap between "mentioned MCP in a changelog once" and "you can add a server in settings right now and the agent will actually call its tools" is bigger than most comparisons admit. Here's what's actually true for the tools developers use most, plus what that means practically when you're picking a server to install.

What "MCP client" means, exactly

An MCP client is the application on your side of the connection — the thing that reads an mcpServers config, launches or connects to a server, and lets an AI model call that server's tools mid-conversation. It's not the AI model itself; Claude, GPT, and Gemini don't "support MCP" as models — the client application wrapped around them does, by implementing the protocol's connection and tool-calling handshake. That distinction matters because it means MCP support is a feature of your editor or desktop app, not a property of which AI model you happen to be using inside it.

Claude Desktop and Claude Code

Claude Desktop is where MCP originated — Anthropic built and open-sourced the protocol, and Claude Desktop was the first reference client. Support is native: add a server to claude_desktop_config.json and it's available in every conversation, no extension or plugin required. Claude Code, Anthropic's terminal-based coding agent, has the same native support built directly into the CLI, configured the same way.

Cursor

Cursor added native MCP support directly in its settings — no extension needed. You add a server either through a project-level .cursor/mcp.json file or globally in Cursor's settings UI, and its tools become available to the agent inside the editor. Because Cursor is a fork of VS Code, its MCP implementation is separate from VS Code's own, but the config shape is close enough that most servers' setup instructions transfer with minimal changes.

VS Code

VS Code's MCP support is native to the editor itself, not bolted on through GitHub Copilot as a separate product — it's built into Copilot's agent mode, which has been rolling out to all VS Code users through 2026. You add a server through a workspace or user mcp.json, and Copilot's agent mode can call it directly while working through a task, including running terminal commands and self-correcting from errors. Because this lives at the editor level, any extension that hooks into Copilot's agent mode benefits from the same MCP connections without separate configuration.

Windsurf

Windsurf (from Codeium) also has native MCP support, added directly into its Cascade agent — servers are configured the same general way, through a JSON config listing commands or URLs, and become available as tools the agent can call while working in your codebase.

Where each client actually keeps its config

The concept is the same everywhere — a JSON object listing servers, each either a local command or a remote URL — but the file location and exact key names differ enough to trip people up when adapting a config from one client to another.

Claude Desktop:  claude_desktop_config.json  →  "mcpServers": { ... }
Claude Code:     .claude/settings.json (or CLI flag)  →  "mcpServers": { ... }
Cursor:          .cursor/mcp.json (project) or Settings UI (global)
VS Code:         .vscode/mcp.json (workspace) or user settings
Windsurf:        Cascade settings → MCP servers panel, backed by its own config file

The shared shape across all of them is a command (for a local, stdio-launched server) or a url (for a remote server), plus any args or env values the server needs. That similarity is exactly why a config written for one client usually only needs the file location and top-level key changed to work in another — the actual server definition rarely needs to change at all.

The rest of the ecosystem

MCP adoption has moved well beyond these four. Cline and Continue, both open-source AI coding extensions, added MCP support early and are commonly cited alongside the major clients. Zed, the Rust-based editor, added MCP-compliant support for connecting external tools. JetBrains has also been rolling MCP support into its AI Assistant across its IDE lineup. The pattern across nearly all of them is the same: a JSON config file listing servers by command (for local/stdio servers) or URL (for remote servers), read by the client at startup or on demand.

How to tell if a tool actually supports MCP — not just says it does

Two checks, in order of reliability. First, look for an actual settings surface for adding a server — a dedicated MCP section in settings, or documentation for an mcp.json / mcpServers config file. If a tool only advertises "plugin support" or "custom tools" without ever mentioning MCP by name or showing a config file format, it's not an MCP client yet, whatever else it can do. Second, check whether the tool can call a server's tools mid-task without you manually invoking them — real MCP support means the model decides when to call a connected tool based on the conversation, not just running a command you triggered by hand.

What this actually means when you're installing a server from DReview

Every server listed on DReview includes a working Claude Desktop config — that's the one constant across every one of the 37 tools currently listed. Coverage for the other three clients is real but not universal yet: as of this writing, only a couple of listings include ready-made Cursor, VS Code, and Windsurf configs alongside Claude Desktop. That's not a limitation of MCP itself — the protocol's config shape is close enough across clients that a Claude Desktop config usually adapts with minor changes — it's just that not every listing has had that specific client's config written and verified yet.

Practically: check a tool's install tabs on its DReview listing before assuming your client is covered. If your client isn't shown, the server likely still works there — MCP's mcpServers JSON shape is close to universal across stdio-based clients — but you may need to adapt the Claude Desktop config's command and arguments to your client's own config file location and format rather than copy-pasting directly. For a local (stdio) server, that adaptation is usually just moving the same command and args values into your client's own config file under its own key name; for a remote server, it's often just the url field, unchanged, since the client's job there is simply opening a connection to it.

The bigger picture

The honest summary is that MCP client support isn't a fixed list anymore — it's the default expectation for any serious AI coding tool released or updated through 2026. Claude Desktop, Claude Code, Cursor, VS Code, and Windsurf all have it natively; Cline, Continue, Zed, and JetBrains's AI Assistant extend that further into the wider ecosystem. The real question when picking a tool isn't "does it support MCP" anymore so much as "does this specific server have a config ready for my specific client" — which is exactly what a listing's install tabs are there to answer.