Cómo instalar un servidor MCP local para tu editor

Actualizado: 2026-05-03

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.

Puntos clave

• MCP resuelve el problema de integraciones punto a punto entre editores y herramientas: un contrato estable, un protocolo.
• Dos transportes principales: stdio (lo que quieres para servidores locales) y streamable HTTP (lo que quieres para remotos).
• El alcance se define al arrancar el servidor y no se puede ampliar en caliente.
• Las inyecciones de instrucciones siguen siendo el riesgo principal; la aprobación granular del cliente es la barrera efectiva.
• Escribir tu propio servidor en Python empieza en unas 60 líneas con el SDK oficial.

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: datos que el modelo puede leer (ficheros, bases de datos, APIs).
• Prompts: plantillas reutilizables para el asistente.
• Herramientas: funciones que el modelo puede invocar con parámetros.

El cliente descubre lo que hay, el modelo decide qué usar, el servidor ejecuta. Para el contexto histórico de por qué MCP se adoptó tan rápido, ver ecosistema MCP consolidado.

La adopción fue rápida porque el protocolo es deliberadamente simple. Hay dos transportes principales:

• stdio: el cliente lanza el servidor como subproceso y habla por stdin/stdout. Para servidores locales, es lo que quieres casi siempre: arranque instantáneo, sin puertos, sin autenticación extra, y el ciclo de vida del proceso lo gestiona el editor.
• streamable HTTP: sustituyó al primer diseño basado en server-sent events a lo largo de 2025. Es ahora la opción por defecto para servidores remotos.

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 — lectura/escritura de ficheros dentro de un directorio permitido.
• git — acceso a repositorios locales.
• github — acceso a repos y PRs de GitHub.
• postgres / sqlite — consulta de bases de datos.
• brave-search — búsqueda web.
• memory — memoria persistente entre sesiones.
• puppeteer — automatización de navegador.

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 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, sesenta líneas de Python suelen bastar.

Instalación paso a paso con el servidor filesystem

El servidor de filesystem es el que más gente acaba necesitando y el que mejor ilustra el modelo de permisos. Los servidores oficiales publicados en npm se ejecutan con npx sin instalación global — el editor los invoca 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.

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

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.

Conectar otros clientes

Claude Code, Cursor, Zed y Windsurf siguen el mismo patrón con nombres de fichero distintos:

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

El contenido es prácticamente idéntico porque el protocolo es el mismo. 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:

1. Alcance estricto: el servidor de filesystem solo debe ver el directorio del proyecto, nunca ~ ni /.
2. 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.
3. 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, servicios de pago — añadir tokens con caducidad corta y alcance reducido es lo que distingue un montaje serio de un juguete.

Para servidores en entorno corporativo, los patrones de proxy corporativo y la gestión de alcance se detallan en gobernanza de agentes en empresa.

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