How to install a local MCP server for your editor

A year and a half after Anthropic’s original proposal, the Model Context Protocol has become the standard way to wire an editor or an AI client to external tools. In April 2026 it is no longer a curiosity: VS Code supports it natively, Claude Code ships with it integrated, Cursor and Zed have mature clients, and the official server registry is past two hundred entries. Installing a local server is now an afternoon of work, but it pays to understand what you are exposing before launching the first one.

What It Solves and Why It Won

MCP exists to address a specific problem: every editor, chat client, and agent had its own incompatible plugin system, and every integration had to be rebuilt. Before MCP, connecting Claude to your database required a Claude-specific extension; doing the same in Cursor required another. The protocol abstracts integration into a stable contract, with three capability types exposed by the server: resources, prompts, and tools. The client discovers what is there, the model decides what to use, the server executes.

Adoption was fast because the protocol is deliberately simple. There are two main transports: stdio, where the client launches the server as a subprocess and communicates over stdin/stdout, and streamable HTTP, which replaced the original server-sent-events design during 2025 and is now the default for remote servers. For local servers, stdio is what you want almost always: instant startup, no ports, no extra authentication, and the editor manages the process lifecycle.

Pick an Existing Server or Write One

The official registry at github.com/modelcontextprotocol/servers lists reference implementations maintained by the community or by Anthropic: filesystem, git, github, postgres, sqlite, brave-search, memory, puppeteer, and a dozen more. A sensible start is to try a known server before writing your own. The filesystem one is particularly instructive because it exposes a clear capability, reads and writes files within an allowed directory, and forces you to think about scope from day one.

Writing your own is easier than it looks. The official SDKs in TypeScript, Python, and Rust abstract the protocol layer and let you declare tools with schemas, implement the function, and not much else. A Python implementation with mcp starts with a decorator, receives Pydantic-validated parameters, and returns a serialisable structure. For an internal server querying a corporate API or a legacy system, sixty lines of Python usually suffice.

Step-by-Step with a Reference Server

I’ll use the filesystem server as the example, because it is what most people end up needing and because it illustrates the permissions model best. First, install the binary. Official servers published on npm run via npx without global install, which is deliberate: the editor invokes the server on demand and does not pollute the system.

npx -y @modelcontextprotocol/server-filesystem /allowed/path

That command starts the server exposed only within the given folder. Reading outside returns a protocol error, not silent access. This is the critical part: scope is defined at launch and cannot be expanded hot. If you need two separate folders, you start two servers.

Wire It Into VS Code

Since VS Code 1.90 in 2025, MCP support is stable under its chat assistant. Configuration lives in .vscode/mcp.json inside the workspace, or in user settings if you want it available everywhere. The format is declarative.

{
  "servers": {
    "filesystem-project": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "${workspaceFolder}"
      ]
    },
    "git-local": {
      "type": "stdio",
      "command": "uvx",
      "args": ["mcp-server-git", "--repository", "${workspaceFolder}"]
    }
  }
}

On save, VS Code detects the servers and starts them the first time the assistant asks to use them. The first invocation shows an approval dialog describing what the model wants to do and with which parameters; you approve per action, per session, or persistently. That granular approval, added to the spec in late 2025, is the answer to the first incidents where agents accepted dangerous tools without user context.

For debugging, VS Code itself offers a view showing each server, its declared tools, the invocation log, and errors. If a server fails to start, the log view tells you exactly which command it ran and what the output was. It is, by a wide margin, the best MCP debugging experience in April 2026.

Wire It Into Other Clients

Claude Code, Cursor, Zed, and Windsurf follow the same pattern with different file names. Claude Code reads ~/.config/claude-code/mcp_servers.json, Cursor uses ~/.cursor/mcp.json, Zed keeps the config under a context_servers key in settings.json. The content is nearly identical because the protocol is the same; what changes is the client and its approval UI. If you use multiple clients, a good practice is to keep server definitions in a shared script and point each client at the same entry point to avoid duplication.

Minimum Security You Cannot Skip

An MCP server is, by definition, code running on your machine with your permissions that the model can invoke. Three minimum rules to avoid regret. First, strict scope: the filesystem server should see only the project directory, never ~ or /. Second, separation of read and write: if the server supports read-only mode, use it by default and only allow writes when you know what you are doing. Third, local auditing: turn on the invocation log and review it after long sessions, especially in the first weeks, to catch patterns you did not expect.

Prompt injection remains the primary risk. A README with malicious instructions inside the directory the server exposes can, without per-action approval, induce the model to execute tools in cascade. Granular client approval is the effective barrier; disabling it for speed is the recipe for the first incident. For servers reaching external systems, mail, production databases, or payment services, adding short-lived tokens with narrow scope is what separates a serious setup from a toy.

When It’s Worth It

MCP has, for the first time, solved the problem of plugging capabilities into an assistant without marrying a specific client. The installation side is remarkably polished today; the security side depends on the operator’s judgement, because the protocol delegates approval to the client and scope to the person running the server. For personal use, starting with reference servers, limiting scope, and treating each approval as a decision rather than noise is usually enough.

Building your own makes sense when the tool you want to expose is specific to your company and no public server covers it. For everything else, the official registry and community provide reasonable coverage, and rewriting a git or github server for your team is work without return. Better to invest that time deciding which internal tools deserve to be within reach of the model and which, however tempting, should continue to require a human in the loop.