VS Code MCP: Setup, Servers, and the 2026 Stack

VS Code without MCP is the editor most developers already live in. Fast. Familiar. Knows your repo because you opened it.

VS Code with MCP is the same editor, except Copilot can also read your live database, the GitHub issues you opened this week, the contents of a folder outside the workspace, and the stack of saved threads you swore you would re-read. The gap between those two setups is one JSON file, one mode switch, and a restart.

This is the practical guide for 2026. What MCP looks like inside VS Code now that Agent mode is generally available, where the mcp.json file actually lives, the servers worth wiring up, and the small mistakes that quietly burn an hour.

What MCP actually is in VS Code

The Model Context Protocol is an open standard released by Anthropic in late 2024 that defines how an AI client talks to tools and data sources outside its own runtime.

In VS Code, the AI client is GitHub Copilot Chat. MCP servers are separate processes (or remote URLs) that expose tools Copilot can call when it is in Agent mode. When you start a new chat, Copilot reads the list of available tools from each connected server. When it decides it needs one, it calls the tool, gets the result, and folds the result back into its reasoning.

Without MCP, Copilot knows whatever was true at training time plus whatever sits in the open editor. With MCP, it queries live systems. The difference between “the API probably looks like this” and “I just hit the actual endpoint and the API looks like this” is the difference between guessing and knowing.

VS Code’s MCP support went generally available in v1.102 in July 2025, around the same time Agent mode rolled out to every user, per the Visual Studio team’s announcement. The implementation is the most enterprise-ready MCP client shipping today, with built-in sandboxing, OAuth support, Settings Sync across devices, and a curated MCP gallery in the Extensions panel. The official VS Code docs are decent but spread across half a dozen pages. The setup itself is shorter than the docs.

How to add an MCP server to VS Code (the actual steps)

There are four places you can wire one up. Pick whichever annoys you least.

The MCP gallery in Extensions. Open the Extensions panel (Cmd-Shift-X on macOS), type @mcp in the search box, browse the curated server list, hit Install. VS Code wires the JSON for you and saves the server to your user config. Best for popular servers like GitHub, Notion, Sentry, Postgres.

The MCP commands. Open the Command Palette (Cmd-Shift-P), search for MCP: and you get a menu. MCP: Add Server walks you through the config interactively. MCP: Open User Configuration and MCP: Open Workspace Folder Configuration jump you straight into the file.

Edit .vscode/mcp.json by hand. The file lives at the root of your workspace under .vscode/mcp.json. Open it, paste, save. Best when you want a known-good template, want to commit team-wide servers to source control, or want to manage your stack as code.

Edit the user config by hand. Same file structure, lives in your user profile. The fastest path is the MCP: Open User Configuration command. This config syncs across machines via VS Code Settings Sync, which is exactly where you want servers that hold your personal API keys.

The structure is the same in every case.

{
  "servers": {
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
      }
    },
    "contextbolt-bookmarks": {
      "type": "http",
      "url": "https://api.contextbolt.app/mcp/your-token-here"
    }
  }
}

Two transport types matter in 2026.

Stdio servers run locally. VS Code spawns the process and talks to it through standard input and output. Most local tools (Filesystem, Postgres, SQLite, Git, Playwright) use stdio. They get command, args, and optional env.

HTTP servers run remotely. VS Code talks to a URL over the network. Hosted services and personal endpoints (such as the ContextBolt MCP) use this transport. They get url and an optional headers block.

Two VS Code-specific touches you will not find in the other IDEs. The config file supports an inputs array for prompted secrets, so when Copilot first uses the server it asks you for the value and stores it securely instead of sitting in plaintext in the JSON. The schema also requires an explicit type field on every server (stdio, http, or sse), which is the opposite of Claude Desktop and Cursor, where the type is inferred from which keys are present. This trips up almost every copy-paste from another IDE’s docs.

Once the file is saved, switch Copilot Chat to Agent mode. Open the chat, click the mode dropdown in the chat box, and pick Agent instead of Ask. MCP tools do not run in Ask mode. This is the single most common reason a fresh server “does not work” in VS Code.

The mistakes that eat an hour

I have hit enough of these to make a list. Six things that fail silently or noisily in unhelpful ways.

Using mcpServers instead of servers as the root key. Every other MCP client uses mcpServers. VS Code uses plain servers. Copy a config block from the Claude Desktop or Cursor docs and VS Code will silently load nothing. Check the root key first.

Forgetting the type field. VS Code does not infer the transport from the keys you set. A server block without "type": "stdio" or "type": "http" is invalid. Copilot logs a warning to the MCP output channel, which most people never look at, and the tool simply does not appear.

Sitting in Ask mode. This is the big one. Copilot Chat defaults to Ask. MCP tools only fire in Agent mode. If you cannot see your server’s tools in the tools picker, the mode dropdown is the first thing to check, every time, before you go diving into the JSON.

Skipping -y on npx commands. Without the -y flag, npx waits for an interactive “should I install this package” prompt. VS Code cannot answer it, the process hangs, and the server never registers. Always include -y when you launch a server through npx.

Cramming in 25 servers. Copilot has a hard ceiling of 128 tools per request. Past that, the chat returns an error telling you to deselect tools. There is a github.copilot.chat.virtualTools.threshold setting that auto-groups large server tool sets behind expandable categories, but the cleaner answer is to keep your real stack to three to six servers. Anything you have not used in two weeks is dead weight.

Pointing the Filesystem server at your home directory. The Filesystem server gives Copilot read and write access inside the directories you allow. If you allow ~/, you have just given the agent read-write to every file you own. Restrict it to a project folder or a dedicated scratch directory. The same rule applies to the Postgres server: use a read-only user unless you specifically want the agent to write data.

The 2026 starter stack

Most “best VS Code MCP servers” lists give you 15. That is not a stack, that is an npm install ceremony. Here is the smaller version, picked by friction not hype.

That stack covers code (GitHub + Filesystem), data (Postgres), docs (Context7), browser (Playwright), and your knowledge layer (ContextBolt). Six servers, well under the 128-tool ceiling, and every one of them earns its keep in a normal week. If you want a longer reasoned list of MCP servers, the 7 best MCP servers for knowledge workers post goes deeper on the non-coding side of the stack.

Workspace config vs user config: where to put what

VS Code is the only IDE that gives you both a workspace and a user config out of the box, which is genuinely useful once you know the rule.

Put shared team servers in .vscode/mcp.json and commit the file. Context7, Playwright, the project’s database. Anyone who clones the repo gets the same MCP stack on code .. VS Code prompts before starting a workspace server for the first time, so a malicious commit cannot silently spawn a process on your machine.

Put personal servers in your user config. ContextBolt, your Linear or Notion endpoint, anything that holds your personal API keys. Settings Sync moves these to every machine where you sign in to VS Code. You will never re-paste your GITHUB_PERSONAL_ACCESS_TOKEN again.

The trap to avoid: putting a personal API key in a workspace config you then commit. The inputs field exists exactly for this. Reference ${input:my_secret} in your workspace mcp.json and Copilot prompts the user once, stores the value securely, and never serializes the actual secret to disk in the project.

Adding your knowledge layer to Copilot

Most MCP setup guides stop at “install GitHub and Filesystem, you are done.” That misses the highest-leverage piece. The thing your AI editor knows least about is your own brain: the threads you saved when you were skimming X, the Reddit comments that changed how you think about a problem, the LinkedIn posts you bookmarked because the framing was good. None of that is in your repo.

ContextBolt is a Chrome extension that captures your X, Reddit, and LinkedIn bookmarks into a searchable AI knowledge base. The free tier ($0, 150 bookmarks) gives you AI tagging, topic clustering, and semantic search inside the extension. Pro ($6 a month) adds unlimited bookmarks, encrypted cloud sync, and a personal MCP endpoint that any MCP client (VS Code, Claude Desktop, Cursor, Windsurf, Claude Code) can call.

Wiring it into VS Code is two minutes.

{
  "servers": {
    "contextbolt-bookmarks": {
      "type": "http",
      "url": "https://api.contextbolt.app/mcp/your-token-here"
    }
  }
}

Switch Copilot Chat to Agent mode and ask “what did I bookmark about Drizzle migrations.” Copilot calls search_bookmarks against your collection, ranks results by semantic match, and you get the three things you actually saved instead of a generic answer pasted from training data. The endpoint also exposes list_clusters, get_cluster_bookmarks, get_recent_bookmarks, and save_bookmark, so Copilot can browse your topic clusters or save a new bookmark mid-chat.

This is the gap most 2026 MCP setup guides miss. Live docs and live code matter, but the difference between a competent agent and a personal one is whether it can read your saved context. For more on that argument, see Personal AI Context Stack for Claude.

VS Code MCP vs Cursor MCP vs Windsurf MCP

If you bounce between editors, the fair question is “do I have to redo this everywhere.” The honest answer is: the servers travel, the config files do not.

VS Code has the highest tool ceiling, the only built-in cross-device sync, and the most enterprise-friendly config split (workspace vs user). It is also the only one that requires a mode switch and the only one that uses servers instead of mcpServers as the root key. If you also use Windsurf or Cursor, the Windsurf MCP setup guide and the Cursor MCP setup guide walk through the parallel flow with the same six-server stack.

The one opinion worth holding

You will read a lot of “install these 25 MCP servers” posts in 2026. Almost all of them are wrong.

The ceiling is real. Copilot caps at 128 tools, and the practical cliff is well before that. Cursor degrades earlier. Windsurf is hard-capped at 100. Claude Code is faster but still loses focus when there is too much surface area to choose from. The agent stops being smart when there are too many doors.

Pick servers the way you pick browser extensions. Three to six. Each one earns its slot or it gets uninstalled fast. Anything you have not used in two weeks is dead weight, no matter how cool the demo was.

The other thing nobody says out loud: the stack that matters most is not the one your AI vendor sells you. The marketplace is biased toward what is easy to integrate, not what makes you smarter. Your knowledge layer (notes, bookmarks, journal, whatever you are actually reading) is almost never on the front page. That is the slot that will move the needle for personal use, and it is the slot you have to wire up yourself.

What to wire up next

If you have just installed Agent mode and the editor itself feels new, start small. Install Context7. Use it for a week. Notice how often Copilot stops fabricating function names. Then add GitHub. Then a database server pointed at your dev DB.

Once those three feel routine, add your knowledge layer. ContextBolt’s MCP endpoint is two lines of JSON and one mode switch. Stack with Notion, Linear, or Obsidian if your work lives there. That is the full setup most solo builders need.

The full VS Code MCP docs are at code.visualstudio.com/docs/copilot/customization/mcp-servers. The MCP spec is at modelcontextprotocol.io. The starter stack above takes about ten minutes to wire up if you already have the tokens, and roughly twenty if you do not.

That is twenty minutes you spend once. The agent gets sharper every day after.