8 IDEs that natively support MCP in 2026

The Model Context Protocol (MCP) was introduced by Anthropic in late 2024 as a way to give AI models structured access to local tools, files and data. Two years in, it has become the standard.

Every editor that ships AI features now supports MCP natively, with one or two formats for the config file. Once you have an MCP server running locally — like Korva’s korva-vault — you wire it once per editor and you’re done.

This is the snapshot as of April 2026.

The eight

Behind every config file the protocol is the same. The MCP spec defines:

• A transport (stdio is universal; SSE and Streamable HTTP are emerging).
• A handshake that exchanges capabilities and allowed methods.
• A set of methods the server can expose: tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get.

The minimal config that works everywhere

For any editor that supports MCP natively, the minimal block looks like:

{
  "mcpServers": {
    "korva-vault": {
      "type": "stdio",
      "command": "korva-vault",
      "args": ["mcp"],
      "env": { "KORVA_MCP_PROFILE": "agent" }
    }
  }
}

The exact JSON path varies by editor — .mcp.json for Claude Code, ~/.cursor/mcp.json for Cursor, the user settings.json for VS Code — but the shape of the entry is identical. That’s the point of MCP.

What “first-class” actually buys you

Two years in, MCP has graduated past “we support it” into “we treat it as a first-class citizen”. Concretely:

• Tools appear in the model’s tool registry without manual prompting. The model knows it has vault_save available the same way it knows it has Read or Edit.
• The session start hook auto-loads the right context. Most modern MCP-aware editors call tools/list and a project-defined “context-loading” tool (like Korva’s vault_context) on every session.
• Errors surface in the UI. If the MCP server crashes mid-session, the editor tells you instead of silently failing.

The early-2025 era of “MCP is a beta we’re playing with” is over.

What’s still painful

Honest list:

• Multiple servers across editors. If you have five MCP servers (Korva + a custom one + GitHub + a database connector + a Slack bot), you’re maintaining five MCP entries × eight editors = 40 config blocks. The CLI tool ecosystem (like korva setup --all) helps but it’s not solved.

• Permission model. Most MCP servers expose all their tools to all clients. You want a “readonly” mode for untrusted clients and a “full agent” mode for your own. Korva’s profile system (agent / readonly / admin) is one stab at this; the spec itself is silent.

• Protocol versioning. The 2024-11-05 version is what most editors implement. Upgrading the server side without breaking older editors requires defensive coding.

• Streaming responses. MCP supports streaming results but not all client editors render them progressively. Long-running tools (vault_pattern_mine against a large vault, for example) feel laggy on some IDEs.

These are improvements, not blockers. The protocol is good enough to build on today.

Wiring all eight from one CLI

For Korva specifically, one command handles every supported IDE:

korva setup --all

It auto-detects each editor on your $PATH, writes the right config block, and is idempotent — running it twice produces the same result as running it once. Per-IDE the commands are:

korva setup claude-code
korva setup cursor
korva setup vscode
korva setup copilot
korva setup windsurf
korva setup codex
korva setup opencode
korva setup gemini

Internally each subcommand consults the integrations/ folder in the public repo, where every IDE has a manifest describing its config file path and format. Adding a new IDE is a matter of adding a manifest.

The standard’s trajectory

The interesting question is not which IDEs support MCP today — almost all of them — but where the standard goes next:

• Streamable HTTP transport is in the spec and being adopted; it removes the requirement for stdio and lets MCP work over the network natively.
• Resources subscription lets clients subscribe to changes (file changes, vault updates, pull-request events) instead of polling.
• Sampling — the inverse direction, where the server can ask the client’s model to generate text — is shipping in early implementations and unlocks server-side autonomy.

If you’re building anything in this space — your own MCP server, a plugin for Cursor, a custom tool for Copilot — the bet to make today is: MCP is the integration layer for AI editors for the next 3–5 years. The number of editors will keep growing; the protocol will get richer; the cost of switching IDEs will keep dropping.

Where to go from here

• Korva’s integrations docs — per-editor specifics for the 8 IDEs.
• The official MCP spec — bookmark this.
• korva setup --all — fastest way to wire your local MCP server into every editor on your machine.

If MCP is new to you, the easiest entry point is to install Korva, run korva vault start, and use any of the 8 IDEs above. You’ll experience MCP as the editors using a structured tool list to call into a local server. Once that mental model clicks, you’ll see why every editor is converging here.