El cambio silencioso de los ultimos meses en el ecosistema de editores de codigo es que MCP ha dejado de ser algo que se consume desde una aplicacion de chat aparte y ha empezado a estar integrado en el editor mismo. VS Code, Zed, Cursor y varios forks de Neovim tienen ya soporte nativo de cliente MCP, con lo cual el agente recibe el contexto del proyecto sin que el desarrollador tenga que copiar archivos a otra ventana. Este post recoge lo que he probado, que servidores activo de forma estable, cuales desactivo inmediatamente, y que problemas practicos han aparecido en el camino.
Por que la integracion en editor cambia la cosa
Hasta principios de 2025, la mayoria del uso serio de agentes ocurria en aplicaciones separadas: Claude Desktop, interfaces web, terminales dedicadas. El editor seguia siendo territorio del autocompletador clasico, con integraciones superficiales con IA que basicamente copiaban el archivo actual al modelo y devolvian sugerencias. MCP integrado cambia esto: el agente puede leer archivos, ejecutar comandos acotados, consultar el estado del repositorio y devolver resultados en el mismo entorno donde el desarrollador ya trabaja.
La ventaja practica es enorme. Desaparece el ciclo de copiar codigo a otra ventana, explicar el contexto, recibir la respuesta y volver al editor. Todo ocurre en la misma superficie. La consecuencia menos obvia es que el agente ya no trabaja con fragmentos aislados sino con vista completa del proyecto, lo que mejora sensiblemente la calidad de las respuestas a preguntas estructurales.
VS Code como referencia
VS Code llega con la implementacion de cliente MCP mas madura que he probado hasta ahora. El soporte es nativo desde mediados de junio y la configuracion vive en un archivo del workspace que el editor relee al arrancar. Cada servidor se define con su comando de arranque y sus permisos; el editor los lanza como procesos hijos y gestiona la comunicacion transparente al usuario.
Lo que me ha sorprendido positivamente es que la integracion no es intrusiva. Los servidores activos aparecen en una barra lateral dedicada, se pueden desactivar temporalmente sin editar archivos, y cada invocacion del agente muestra claramente que servidor respondio. Esta trazabilidad es importante porque convierte MCP en algo observable en lugar de magia negra.
La limitacion que mas me ha molestado es que el editor no tiene todavia una buena forma de limitar el agente a ciertos servidores segun el contexto. Si un servidor de filesystem tiene acceso al proyecto entero, no hay manera de decirle al agente “solo lee dentro de esta carpeta” sin editar la configuracion global. Para proyectos con monorepo y partes sensibles, esto obliga a configuraciones mas restrictivas de lo ideal.
Zed y el minimalismo funcional
Zed ha ido por otro camino, mas minimalista. El soporte de MCP esta en el editor pero la interfaz es austera: se configura por archivo, se activa un panel de agente, y los servidores responden con la misma filosofia de rapidez que caracteriza al editor. En proyectos grandes, esa rapidez se nota: la latencia entre que pides algo al agente y recibes la respuesta es menor que en VS Code, aunque la calidad del resultado depende del mismo modelo subyacente.
La pega de Zed es que el ecosistema de extensiones es mas pequenio y los servidores MCP populares tardan mas en aparecer con integracion de primera calidad. Para quien viva en Zed y le guste su filosofia, es una buena opcion; para quien necesite soporte amplio de servidores, VS Code sigue ganando.
Cursor y la apuesta integrada
Cursor ha integrado MCP mas temprano que nadie y ha invertido en hacer que la experiencia sea fluida desde el primer arranque. La configuracion viene con valores por defecto sensatos, los servidores de filesystem y git estan activados, y el agente tiene contexto del proyecto sin pedirselo. Para quien venga de otro editor sin experiencia de MCP, Cursor baja la curva de aprendizaje de forma notable.
El coste de esa integracion profunda es que Cursor opina sobre como se usa el agente. El flujo de trabajo esta mas cerrado que en VS Code, y ciertos patrones que son faciles en otros editores (pasar el contexto a otro agente con otra configuracion, por ejemplo) son mas tediosos. Es el clasico equilibrio entre facilidad y flexibilidad, y Cursor ha elegido facilidad.
Neovim y los forks comunitarios
El mundo Neovim llega mas tarde y por via de plugins de la comunidad. No hay soporte oficial de MCP en el upstream, pero hay al menos tres plugins activos que implementan cliente MCP con distintos niveles de integracion. Los he probado todos y el que mejor me ha funcionado es el que integra MCP con el sistema de comandos propios de Neovim en lugar de crear una interfaz paralela.
La ventaja de Neovim es que la configuracion es texto plano, versionable y portable. La desventaja es que los servidores MCP asumen ciertas convenciones de cliente (por ejemplo, streaming de respuestas) que algunos plugins todavia no soportan bien. Para usuarios avanzados de Neovim, la experiencia es buena; para quienes quieran entrar a MCP desde cero, mejor empezar con VS Code o Cursor y volver a Neovim cuando los patrones esten claros.
Que servidores activo de forma estable
Independientemente del editor, hay un conjunto de servidores MCP que mantengo activos en casi todos los proyectos. El primero es el de filesystem acotado al workspace, con acceso de lectura y escritura limitado al directorio del proyecto. Es el servidor basico que habilita casi todo lo demas.
El segundo es el de git, solo lectura, para que el agente pueda consultar el estado del repositorio, diffs y historial sin ejecutar comandos que modifiquen nada. La regla es clara: el agente puede leer, las escrituras las hace el desarrollador tras revisar la propuesta.
El tercero es un servidor de documentacion propia del proyecto. En varios repos mantengo un directorio con notas de arquitectura, convenciones y decisiones. Exponerlo al agente via MCP le da acceso a ese conocimiento tacito sin tener que inyectarlo en cada prompt. Es probablemente la integracion que mas valor aporta, porque convierte documentacion muerta en contexto vivo.
Lo que no activo por defecto
Hay servidores que pruebo y acabo desactivando. El de shell con acceso libre es el mas peligroso: la comodidad de que el agente ejecute comandos no compensa el riesgo. Si un servidor que proponga ejecutar comandos arbitrarios en el sistema, lo restringo a un sandbox o lo elimino.
El de busqueda web general tampoco sobrevive mucho. Anade ruido, devuelve resultados de calidad variable y el agente suele interpretarlos sin el juicio necesario. Para busquedas concretas prefiero hacerlas yo y pasar al agente los fragmentos relevantes.
El de base de datos con acceso a produccion es otro no definitivo. Para desarrollo, con solo lectura y sobre copias, es util; para produccion, el riesgo de que el agente genere una consulta cara o bloqueante es demasiado alto. He visto casos de agentes generando joins sin indice sobre tablas de millones de filas; en una base de datos de desarrollo eso es una anecdota, en produccion es un incidente.
El problema de los permisos
La pregunta practica que mas me han hecho companieros es como controlar que puede hacer cada servidor. La respuesta honesta es que el control es mas rudimentario de lo deseable. MCP define un modelo de capacidades por servidor pero la granularidad dentro de cada capacidad depende de la implementacion concreta.
Esto significa que la confianza en cada servidor es un tema de reputacion del autor, no de sandbox real del cliente. Un servidor de filesystem mal escrito podria leer fuera del directorio configurado; un servidor de shell podria ejecutar mas de lo que declara. El cliente del editor no valida estos limites, solo los declara.
Mi practica es simple: servidores oficiales o de autores conocidos se usan tal cual; servidores de la comunidad se revisan al menos por encima antes de instalarlos, especialmente si piden capacidades sensibles. Para proyectos con datos sensibles, solo servidores revisados y firmados por el equipo.
Como pensar la decision
Si estas empezando con MCP en el editor, mi recomendacion es VS Code o Cursor con los tres servidores basicos (filesystem, git, documentacion propia) y nada mas. Anade el resto solo cuando una tarea concreta lo justifique, y quitalos cuando la tarea termine. Menos servidores activos es mejor contexto y menos superficie de riesgo.
Si vives en Zed o Neovim, el camino es mas exploratorio pero viable. Zed funciona bien para uso moderado y Neovim es valido para usuarios avanzados dispuestos a tocar configuraciones. En ninguno de los dos esperaria la experiencia lisa que dan VS Code o Cursor, pero ninguno es tampoco ciudadano de segunda.
Lo que si creo que va a consolidarse pronto es que MCP se volvera la forma estandar de integrar agentes en editores, igual que LSP se volvio estandar para servidores de lenguaje. Cuando eso pase, la decision de editor y la decision de modelo se volveran ortogonales, y cada equipo podra combinar lo que le convenga. Por ahora estamos en la fase de transicion, donde los clientes aprenden el protocolo y los servidores buenos se separan de los experimentos efimeros. Merece la pena participar con cabeza fria, sin instalar todo, y dejar que el catalogo se decante.
