How to install a local MCP server for your editor

Actualizado: 2026-05-03

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.

Key takeaways

• MCP solves the point-to-point integration problem between editors and tools: one stable contract, one protocol.
• Two main transports: stdio (what you want for local servers) and streamable HTTP (what you want for remote servers).
• Scope is defined at server startup and cannot be expanded hot.
• Prompt injection remains the primary risk; granular client approval is the effective barrier.
• Writing your own server in Python starts at about 60 lines with the official SDK.

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: data the model can read (files, databases, APIs).
• Prompts: reusable templates for the assistant.
• Tools: functions the model can invoke with parameters.

The client discovers what is there, the model decides what to use, the server executes. For the historical context of why MCP was adopted so quickly, see the consolidated MCP ecosystem.

Adoption was fast because the protocol is deliberately simple. Two main transports:

• stdio: the client launches the server as a subprocess and communicates over stdin/stdout. For local servers, this is what you want almost always: instant startup, no ports, no extra authentication, and the editor manages the process lifecycle.
• streamable HTTP: replaced the original server-sent-events design during 2025. Now the default for remote servers.

Pick an Existing Server or Write One

The official registry at github.com/modelcontextprotocol/servers lists reference implementations:

• filesystem — read/write files within an allowed directory.
• git — access to local repositories.
• github — access to GitHub repos and PRs.
• postgres / sqlite — database querying.
• brave-search — web search.
• memory — persistent memory across sessions.
• puppeteer — browser automation.

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 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, sixty lines of Python usually suffice.

Step-by-Step with the Filesystem Server

The filesystem server is what most people end up needing and because it illustrates the permissions model best. Official servers published on npm run via npx without global install — 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.

{
  "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.

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.

Wire It Into Other Clients

Claude Code, Cursor, Zed, and Windsurf follow the same pattern with different file names:

• Claude Code: ~/.config/claude-code/mcp_servers.json
• Cursor: ~/.cursor/mcp.json
• Zed: context_servers key in settings.json

The content is nearly identical because the protocol is the same. 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:

1. Strict scope: the filesystem server should see only the project directory, never ~ or /.
2. 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.
3. 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, payment services — adding short-lived tokens with narrow scope is what separates a serious setup from a toy.

For corporate-environment servers, the corporate proxy patterns and scope management are detailed in enterprise agent governance.

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. 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.