Cómo instalar un servidor MCP local para tu editor

Un año y medio después de la propuesta inicial de Anthropic, el Model Context Protocol se ha convertido en la forma estándar de conectar un editor o un cliente de IA con herramientas externas. En abril de 2026 ya no es una curiosidad: VS Code lo soporta nativamente, Claude Code lo trae integrado, Cursor y Zed tienen clientes maduros, y el registro oficial de servidores pasa de doscientos. Instalar uno local es hoy una tarde de trabajo, pero conviene entender qué estás exponiendo antes de lanzar el primero.

Qué resuelve y por qué se impuso

MCP nace para resolver un problema concreto: cada editor, cada cliente de chat y cada agente tenía su propio plugin system incompatible, y cada integración se rehacía. Antes de MCP, conectar Claude con tu base de datos exigía una extensión específica para Claude. Conectar lo mismo a Cursor exigía otra. El protocolo abstrae la integración en un contrato estable, con tres tipos de capacidades expuestas por el servidor: recursos, prompts y herramientas. El cliente descubre lo que hay, el modelo decide qué usar, el servidor ejecuta.

La adopción fue rápida porque el protocolo es deliberadamente simple. Hay dos transportes principales: stdio, donde el cliente lanza el servidor como subproceso y habla por stdin/stdout, y streamable HTTP, que sustituyó al primer diseño basado en server-sent events a lo largo de 2025 y es ahora la opción por defecto para servidores remotos. Para servidores locales, stdio es lo que quieres en casi todos los casos: arranque instantáneo, sin puertos, sin autenticación extra, y el ciclo de vida del proceso lo gestiona el editor.

Elegir un servidor existente o escribir uno

El registro oficial en github.com/modelcontextprotocol/servers lista los de referencia, mantenidos por la comunidad o por Anthropic: filesystem, git, github, postgres, sqlite, brave-search, memory, puppeteer y una docena más. Para empezar, lo razonable es probar con uno conocido antes de escribir el tuyo. El de filesystem es particularmente pedagógico porque expone una capacidad clara, lee y escribe ficheros dentro de un directorio permitido, y te obliga a pensar en alcance desde el primer día.

Escribir uno propio es más fácil de lo que parece. Los SDK oficiales en TypeScript, Python y Rust abstraen la capa de protocolo y dejan al programador declarar herramientas con su esquema, implementar la función y poco más. Una implementación en Python con mcp empieza con un decorador, recibe parámetros validados con Pydantic y devuelve el resultado como estructura serializable. Para un servidor interno que consulte una API corporativa o un sistema antiguo, sesenta líneas de Python suelen bastar.

Instalación paso a paso con un servidor de referencia

Voy a usar el de filesystem como ejemplo, porque es el que más gente acaba necesitando y el que mejor ilustra el modelo de permisos. Primero, instalar el binario. Los servidores oficiales publicados en npm se ejecutan con npx sin instalación global, lo cual es deliberado: el editor invoca al servidor bajo demanda y no ensucia el sistema.

npx -y @modelcontextprotocol/server-filesystem /ruta/permitida

Esa orden arranca el servidor expuesto solamente dentro de la carpeta indicada. Intentar leer fuera de ese directorio devuelve un error de protocolo, no acceso silencioso. Esta es la parte crítica: el alcance se define al arrancar y no se puede ampliar en caliente. Si necesitas dos carpetas separadas, arrancas dos servidores.

Conectar VS Code

Desde la versión 1.90 de 2025, VS Code trae soporte MCP estable bajo su asistente de chat. La configuración vive en un fichero .vscode/mcp.json dentro del workspace o en la configuración de usuario si quieres que esté disponible en cualquier proyecto. El formato es declarativo.

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

Tras guardar el fichero, VS Code detecta los servidores y los arranca la primera vez que el asistente pide usarlos. La primera invocación muestra un diálogo de aprobación describiendo qué quiere hacer el modelo y con qué parámetros; tú apruebas por acción, por sesión o de forma persistente. Esa aprobación granular, introducida en la especificación a finales de 2025, es la respuesta a los primeros incidentes donde agentes aceptaban herramientas peligrosas sin contexto del usuario.

Para depurar, el propio VS Code ofrece una vista donde ves cada servidor, sus herramientas declaradas, el log de invocaciones y los errores. Si el servidor no arranca, la vista de logs te dice exactamente qué orden ejecutó y cuál fue la salida. Es con diferencia la mejor experiencia de depuración MCP en abril de 2026.

Conectar otros clientes

Claude Code, Cursor, Zed y Windsurf siguen el mismo patrón con nombres de fichero distintos. Claude Code lee ~/.config/claude-code/mcp_servers.json, Cursor usa ~/.cursor/mcp.json, Zed mantiene la configuración en settings.json bajo una clave context_servers. El contenido es prácticamente idéntico porque el protocolo es el mismo; lo que cambia es el cliente y su interfaz de aprobación. Si vas a usar varios clientes, una buena práctica es mantener los servidores en un script compartido y apuntar cada cliente al mismo punto de entrada para no duplicar configuración.

Seguridad mínima que no es opcional

Un servidor MCP es, por definición, código que se ejecuta en tu máquina con tus permisos y que el modelo puede invocar. Tres reglas mínimas para no lamentarlo. Primera, alcance estricto: el servidor de filesystem solo debe ver el directorio del proyecto, nunca ~ ni /. Segunda, separación entre lectura y escritura: si el servidor soporta modo de solo lectura, úsalo por defecto y solo permite escritura cuando sepas qué estás haciendo. Tercera, auditoría local: activa el log de invocaciones y revísalo tras sesiones largas, sobre todo las primeras semanas, para detectar patrones que no esperabas.

Las inyecciones de instrucciones siguen siendo el riesgo principal. Un README con instrucciones maliciosas dentro del directorio que el servidor expone puede, sin aprobación por acción, inducir al modelo a ejecutar herramientas en cascada. La aprobación granular del cliente es la barrera efectiva; desactivarla para ganar velocidad es la receta para el primer incidente. Para servidores que acceden a sistemas externos, correo, base de datos de producción o servicios de pago, añadir una capa de tokens con caducidad corta y alcance reducido es lo que distingue un montaje serio de un juguete.

Mi lectura

MCP ha resuelto, por primera vez, el problema de enchufar capacidades a un asistente sin casarse con un cliente concreto. La parte instalación es sorprendentemente pulida hoy; la parte seguridad depende del criterio del que lo despliega, porque el protocolo delega en el cliente la aprobación y en el operador el alcance. Para uso personal, empezar por servidores de referencia, limitar alcance y tratar cada aprobación como una decisión, no como un diálogo de ruido, suele ser suficiente.

Cuándo compensa montar uno propio: cuando la herramienta que quieres exponer es específica de tu empresa y ningún servidor público la cubre. Para todo lo demás, el registro oficial y la comunidad ya ofrecen cobertura razonable, y reescribir un servidor de git o de github para tu equipo suele ser trabajo sin retorno. Mejor invertir ese tiempo en pensar qué herramientas internas merecen estar al alcance del modelo y cuáles, por muy tentador que parezca, deberían seguir requiriendo un humano.