MCP clients in editors: AI integrates where you already work

Actualizado: 2026-05-03

The quiet shift of recent months in the code editor ecosystem is that MCP has stopped being something consumed from a separate chat application and has started being embedded in the editor itself. VS Code, Zed, Cursor, and several Neovim forks already have native MCP client support, which means the agent receives project context without the developer having to copy files to another window. This post gathers what I’ve tried, which servers I keep active stably, which I disable immediately, and what practical problems have appeared along the way.

For the MCP protocol context and how it fits into broader agentic flows, the analysis of CI with AI agents describes how the same agents are used in pipelines. The post on LLM agent security covers the risk considerations that apply directly to MCP servers. Agent integration patterns with development tools are covered in AI-assisted code review.

Key takeaways

• MCP integration in the editor eliminates the cycle of copying code to another window: the agent works with full project view.
• VS Code offers the most mature MCP client; Cursor lowers the entry curve; Zed prioritizes speed; Neovim requires community plugins.
• The three servers worth enabling stably: filesystem scoped to workspace, git read-only, project internal documentation.
• Permission control within MCP is rudimentary; trust in each server depends on author reputation, not real client sandboxing.
• MCP will consolidate as the standard for agent integration in editors the same way LSP became standard for language servers.

Why editor integration changes things

Until early 2025, most serious agent use happened in separate applications: Claude Desktop, web interfaces, dedicated terminals. The editor remained classic autocompleter territory, with shallow AI integrations that basically copied the current file to the model and returned suggestions. Integrated MCP changes this: the agent can read files, run bounded commands, query repository state, and return results in the same environment where the developer already works.

The practical advantage is huge. The cycle of copying code to another window, explaining context, receiving an answer, and going back to the editor disappears. Everything happens on the same surface. The less obvious consequence is that the agent no longer works with isolated fragments but with a full project view, which noticeably improves answer quality for structural questions.

VS Code as reference

VS Code arrives with the most mature MCP client implementation I’ve tried. Support has been native since mid-June and configuration lives in a workspace file the editor re-reads on startup. Each server is defined with its launch command and permissions; the editor spawns them as child processes and manages communication transparently.

What has positively surprised me is that the integration isn’t intrusive. Active servers appear in a dedicated sidebar, can be temporarily disabled without editing files, and each agent invocation clearly shows which server responded. This traceability turns MCP into something observable instead of black magic.

The limitation that has bothered me most is that the editor still lacks a good way to limit the agent to certain servers by context. If a filesystem server has access to the entire project, there’s no way to tell the agent “only read inside this folder” without editing global config. For projects with a monorepo and sensitive parts, this forces more restrictive configurations than ideal.

Zed and functional minimalism

Zed has taken another path, more minimalist. MCP support is in the editor but the interface is austere: configured by file, an agent panel is enabled, and servers respond with the same speed philosophy that characterizes the editor. In large projects that speed shows: latency between asking the agent something and receiving an answer is lower than in VS Code.

Zed’s drawback is that the extension ecosystem is smaller and popular MCP servers take longer to appear with first-class integration. For those who live in Zed and like its philosophy, it’s a good option; for those needing broad server support, VS Code still wins.

Cursor and the integrated bet

Cursor integrated MCP earlier than anyone and invested in making the experience smooth from first launch. Configuration comes with sensible defaults, filesystem and git servers are enabled, and the agent has project context without being asked. For those coming from another editor without MCP experience, Cursor notably lowers the learning curve.

The cost of that deep integration is that Cursor has opinions on how the agent is used. The workflow is more closed than in VS Code, and certain patterns easy in other editors are more tedious. It’s the classic tradeoff between ease and flexibility, and Cursor chose ease.

Neovim and community forks

The Neovim world arrives later via community plugins. There’s no official MCP support in upstream, but there are at least three active plugins implementing MCP client with varying integration levels. The one that has worked best integrates MCP with Neovim’s own command system instead of creating a parallel interface.

Neovim’s advantage is that configuration is plain text, versionable and portable. The disadvantage is that MCP servers assume certain client conventions that some plugins don’t yet support well. For advanced Neovim users, the experience is good; for those entering MCP from scratch, better to start with VS Code or Cursor.

Which servers I keep active stably

Regardless of editor, there’s a set of MCP servers I keep active in almost every project:

1. Filesystem scoped to workspace: read and write access limited to the project directory. It’s the basic server that enables almost everything else.
2. Git, read-only: so the agent can check repository state, diffs, and history without running commands that modify anything. The rule is clear: the agent can read, writes happen through the developer after reviewing the proposal.
3. Project-specific documentation: in several repos I keep a directory with architecture notes, conventions, and decisions. Exposing it to the agent via MCP gives it access to that tacit knowledge without injecting it into each prompt. Probably the integration adding the most value, because it turns dead documentation into live context.

What I don’t enable by default

There are servers I try and end up disabling:

• Shell with free access: the convenience of the agent running commands doesn’t compensate the risk. If a server proposes executing arbitrary commands, I restrict it to a sandbox or remove it.
• General web search: adds noise, returns variable-quality results, and the agent usually interprets them without needed judgment.
• Database with production access: for development, read-only on copies, useful; for production, the risk of the agent generating an expensive or blocking query is too high.

The permissions problem

The practical question colleagues ask me most is how to control what each server can do. The honest answer is that control is more rudimentary than desirable. MCP defines a per-server capability model but granularity within each capability depends on the concrete implementation.

This means trust in each server is a matter of author reputation, not real client sandboxing. My practice: official servers or servers from known authors are used as-is; community servers are at least skimmed before installing, especially if they request sensitive capabilities.

How to think about the decision

If you’re starting with MCP in the editor, the recommendation is VS Code or Cursor with the three basic servers and nothing more. Add the rest only when a specific task justifies it, and remove them when the task ends. Fewer active servers means better context and less risk surface.

What I think will consolidate soon is that MCP will become the standard way to integrate agents in editors, just as LSP became standard for language servers. When that happens, editor choice and model choice will become orthogonal, and each team can combine what suits them. For now we’re in the transition phase, where clients learn the protocol and good servers separate from ephemeral experiments.