MCP Servers v2.0.0 añade soporte para protocolos modernos mientras mantiene clientes heredados
MCP Servers v2.0.0 refactoriza los servidores de referencia del proyecto para el protocolo moderno, a la vez que conserva el soporte para clientes heredados. Publicada el 19 de octubre, la actualización conecta distintas generaciones de MCP, el Model Context Protocol que vincula aplicaciones de IA con herramientas y datos. Su promesa de compatibilidad tiene un límite claro: los clientes antiguos siguen siendo compatibles, pero los servidores de TypeScript ahora requieren Node.js 24.
Esta distinción aumenta la presión sobre los desarrolladores que mantienen integraciones existentes. Un cliente puede seguir utilizando un protocolo antiguo mientras el software que sustenta sus herramientas requiere un entorno de ejecución más reciente. Por tanto, los equipos de aplicaciones deben tomar decisiones independientes sobre los paquetes de servidor, los entornos de ejecución y el comportamiento del protocolo.
La tensión central está entre modernización y continuidad. Los responsables están orientando sus ejemplos hacia una arquitectura más reciente sin exigir que todas las aplicaciones conectadas migren simultáneamente. Para los desarrolladores que usan Claude Desktop, VS Code o aplicaciones de IA personalizadas, la pregunta inmediata es qué supuestos sobreviven a esa transición. La configuración de la conexión, los permisos de archivos y la duración del estado de la aplicación merecen más atención que el número de versión por sí solo.
Qué cambia realmente MCP Servers v2.0.0
Esta versión actualiza una colección definida de implementaciones de referencia, no todos los servidores de la comunidad MCP en general.
La lista de paquetes de la versión identifica cuatro paquetes de TypeScript publicados con la versión 2.0.0. Cubren Everything, Filesystem, Memory y Sequential Thinking. TypeScript es un lenguaje de programación que añade comprobación de tipos a JavaScript.
La misma versión enumera tres paquetes de Python: Fetch, Git y Time. Estos llevan la versión basada en fecha 2026.10.19. La diferencia importa cuando los equipos inventarían dependencias, porque la etiqueta de versión del repositorio no se convierte en la versión de todos los paquetes.
Los responsables describen la actualización como un refactor que admite la especificación moderna y sigue respondiendo a clientes heredados. Se trata de una afirmación de implementación sobre los servidores incluidos. No establece compatibilidad para integraciones comunitarias no relacionadas ni para todas las aplicaciones que se conectan mediante MCP.
También intervienen sistemas de versiones independientes. La versión del repositorio usa v2.0.0, mientras que el protocolo utiliza identificadores basados en fechas. Una versión de paquete identifica software distribuido; un identificador de protocolo describe las reglas de comunicación que ese software admite.
Confundir estos identificadores puede generar expectativas de actualización engañosas. Instalar un paquete etiquetado como 2.0.0 no significa que una aplicación adopte automáticamente todas las funciones de protocolo más recientes. El cliente sigue determinando qué comportamiento de comunicación compatible utiliza.
Esto convierte la compatibilidad de servidores MCP en una relación entre componentes. Un paquete de servidor puede admitir varias revisiones del protocolo mientras una aplicación conectada sigue usando una revisión anterior. A la inversa, instalar software de servidor más reciente no puede aportar capacidades que faltan en el cliente.
Para los responsables de ingeniería, la versión crea una distinción útil entre disponibilidad y preparación. Los paquetes publicados establecen que la implementación está disponible. La preparación depende de que la aplicación circundante, el entorno de inicio, los permisos y el comportamiento esperado funcionen conjuntamente.
La importancia práctica va más allá de quienes ejecutan estos paquetes directamente. Las implementaciones de referencia ofrecen ejemplos que otros desarrolladores estudian y adaptan. Sus decisiones arquitectónicas pueden influir en integraciones personalizadas incluso cuando el paquete de referencia nunca entra en una lista de dependencias de producción.
Esta influencia merece una redacción cuidadosa. Un ejemplo puede establecer un patrón sin demostrar que dicho patrón sirve para todas las implementaciones. La versión ofrece material concreto de implementación, mientras que los responsables de aplicaciones conservan la responsabilidad de decidir qué partes encajan con sus sistemas.
Por tanto, la noticia es más específica que un anuncio general de que MCP ha cambiado. Los responsables han distribuido ejemplos actualizados que conectan un comportamiento de protocolo más reciente con una base instalada de clientes antiguos. La siguiente cuestión se refiere a la infraestructura necesaria para ejecutar esos ejemplos.
Los clientes antiguos siguen siendo compatibles, pero los entornos de ejecución antiguos no
La compatibilidad de protocolos no preserva el entorno de ejecución anterior.
El requisito de Node.js de la versión eleva la versión mínima de Node.js de los servidores TypeScript a la 24. Node.js es el entorno de ejecución que ejecuta JavaScript fuera de un navegador. El cambio se aplica a Everything, Filesystem, Memory y Sequential Thinking.
El registro de mantenimiento asociado explica por qué este requisito merece atención. Las declaraciones de paquetes, la documentación y las comprobaciones automatizadas describían anteriormente expectativas de soporte diferentes. La corrección alinea el mínimo declarado, la documentación y la configuración de validación en torno al entorno de ejecución más reciente.
Esto crea un problema concreto de migración para las aplicaciones locales de IA. Un usuario podría actualizar un paquete de servidor sin modificar el entorno de inicio de la aplicación. El protocolo del cliente sigue siendo aceptable, pero el servidor aún depende del entorno de ejecución disponible para ese proceso.
Considere una estación de trabajo de ingeniería ilustrativa con entornos separados para desarrollo y aplicaciones de escritorio. Una terminal puede informar del entorno de ejecución esperado mientras una aplicación iniciada en otro lugar hereda una configuración distinta. Una ejecución correcta en la terminal no resolvería si la aplicación de escritorio puede iniciar el mismo servidor.
Este ejemplo ilustra el razonamiento de implementación, no un defecto reportado en la versión. La implicación más amplia se deriva directamente del nuevo mínimo: los equipos necesitan evidencia sobre el entorno que realmente inicia el paquete.
La presión recae más directamente sobre los desarrolladores que distribuyen configuraciones, los administradores que mantienen estaciones de trabajo gestionadas y los equipos que empaquetan asistentes internos. Su responsabilidad incluye el software que inicia una herramienta, no solo la interfaz declarada de la herramienta.
Para esos equipos, la compatibilidad con versiones anteriores puede reducir el trabajo de coordinación sin eliminarlo. No necesariamente tienen que reescribir los clientes antiguos de inmediato. Aun así, deben tener en cuenta los requisitos del servidor más reciente.
Esta distinción también cambia cómo deben interpretarse los fallos. Un proceso que no puede iniciarse plantea un problema distinto al de un servidor en funcionamiento que rechaza una solicitud. Tratar ambos como incompatibilidad de protocolo dirige la investigación hacia el componente equivocado.
El mismo razonamiento se aplica a la documentación de soporte. Una instrucción que indique que los clientes heredados siguen siendo compatibles necesita un contexto cercano sobre los requisitos del entorno de ejecución. De lo contrario, los lectores pueden inferir razonablemente una promesa más amplia de la que los responsables realmente hacen.
La fijación de versiones de paquetes, que establece una dependencia en una versión seleccionada, se convierte en una decisión operativa con consecuencias visibles. Los equipos pueden evaluar la nueva versión de forma deliberada en lugar de combinar un cambio inesperado de paquete con un cambio de entorno.
Esto no establece un argumento universal para retrasar las actualizaciones. Establece la necesidad de distinguir los motivos para actualizar. Un equipo que busca un comportamiento de protocolo moderno tiene un objetivo inmediato diferente de otro que mantiene un flujo de trabajo existente.
La versión ofrece a ambos equipos un camino hacia adelante, pero su validación debe reflejar esos objetivos distintos. Mantener un cliente antiguo implica comprobar la continuidad del comportamiento. Adoptar un cliente más reciente también implica examinar la arquitectura que gestiona sus solicitudes.
El puente de compatibilidad cambia cómo las solicitudes transportan contexto
La arquitectura más reciente cambia dónde reside el contexto de comunicación, incluso cuando la herramienta visible sigue siendo familiar.
Según las actuales reglas de versionado del protocolo, la revisión del protocolo es 2026-07-28. Las solicitudes declaran su versión de protocolo mediante metadatos, es decir, información descriptiva que acompaña a la solicitud. Los servidores aceptan o rechazan las solicitudes individualmente según las versiones compatibles.
Los clientes pueden usar server/discover, una solicitud de descubrimiento que devuelve la identidad del servidor, las versiones compatibles y las capacidades. Las revisiones de protocolo antiguas usan en su lugar una negociación de inicialización, un intercambio de apertura que establece el contexto operativo de la conexión.
La implementación moderna del protocolo incorpora ambos enfoques a los servidores de referencia de TypeScript. Para conexiones locales, el primer mensaje selecciona la generación de protocolo. Un cliente antiguo comienza con initialize; un cliente moderno utiliza el descubrimiento o los metadatos de solicitud más recientes.
La implementación también se aleja del estado del servidor indexado por identificadores de sesión. El estado específico de la conexión reside en instancias de servidor. La información que debe sobrevivir a una solicitud moderna utiliza handles, identificadores emitidos por el servidor para hacer referencia a esa información.
Estos detalles importan porque “sin estado” puede malinterpretarse. Eliminar la dependencia de las sesiones del protocolo no significa que una aplicación olvide todo después de cada solicitud. Significa que los desarrolladores deben identificar explícitamente dónde reside la información y cómo el trabajo posterior hace referencia a ella.
Para una integración personalizada, esta distinción afecta a la revisión arquitectónica. Un desarrollador debe separar la información que pertenece a una solicitud de la que pertenece a una conexión o a datos almacenados de la aplicación. Esas duraciones no tienen por qué coincidir.
Un asistente que retiene un dato de proyecto plantea un requisito distinto al de una herramienta que conserva progreso temporal. La información persistente debe sobrevivir de acuerdo con las reglas de almacenamiento del producto. La información temporal debe permanecer disponible solo para la operación o interacción prevista.
El servidor Memory ilustra esa diferencia. Su grafo de conocimiento, una estructura que conecta entidades mediante relaciones, proporciona información persistente. Su documentación describe mecanismos de suscripción distintos para clientes modernos y heredados, mientras conserva las mismas herramientas y recursos subyacentes.
Una suscripción es una solicitud para recibir actualizaciones cuando cambia la información. La cuestión importante para el producto se refiere a si la aplicación sigue recibiendo esas actualizaciones. Una lectura inicial correcta no establece que los cambios posteriores aparezcan según lo esperado.
Sequential Thinking presenta otra distinción de duración. Su documentación describe un historial de razonamiento que dura mientras dure la conexión en cualquiera de las dos generaciones de protocolo. Ese comportamiento se refiere al contexto de trabajo de la herramienta, no a una promesa general de memoria permanente.
Everything tiene nuevamente una finalidad distinta. Prueba las capacidades del protocolo para los creadores de clientes, incluido el comportamiento de solicitudes y notificaciones modernas. Su valor proviene de exponer comportamientos de integración que una simple llamada de herramienta correcta dejaría sin examinar.
En conjunto, estos ejemplos muestran por qué la migración de servidores MCP va más allá de cambiar importaciones o nombres de paquetes. La función visible puede seguir siendo reconocible mientras cambia el modelo de comunicación circundante. Los desarrolladores que adaptan código de referencia necesitan comprender ambas capas.
Aquí también es donde el enfoque de compatibilidad adquiere importancia. El soporte para clientes antiguos da tiempo a los equipos de aplicaciones. No elimina la necesidad de comprender la arquitectura más reciente antes de adoptar su comportamiento.
El acceso al sistema de archivos hace concreta la diferencia de comportamiento
El mismo paquete de servidor puede requerir una configuración de permisos diferente según la generación del protocolo del cliente.
El servidor Filesystem ofrece el ejemplo más claro, porque su comportamiento determina a qué directorios locales puede acceder una herramienta. Una lista de permitidos es un conjunto explícito de ubicaciones autorizadas. La conexión moderna del servidor utiliza los directorios proporcionados al iniciar el proceso.
La documentación etiquetada sobre controles de acceso a directorios recomienda esos argumentos de inicio para todas las versiones del protocolo. Los clientes antiguos también pueden usar Roots, un mecanismo proporcionado por el cliente que describe ubicaciones del sistema de archivos. La conexión moderna no solicita esa información heredada.
Por lo tanto, un servidor iniciado sin directorios permitidos se comporta de forma distinta según su ruta de conexión. Para las llamadas a herramientas modernas, la documentación describe un error que explica la falta de configuración de directorios. Un proceso conectado por sí solo no establece un acceso utilizable a los archivos.
Para los clientes heredados, la documentación también describe actualizaciones y revocaciones de acceso. Las llamadas a herramientas esperan mientras hay pendiente una actualización de Roots. Una vez que las raíces proporcionadas por el cliente entran en vigor, una actualización que no contiene raíces válidas elimina el acceso hasta que vuelvan a estar disponibles raíces válidas.
La implicación para el producto es sencilla: el éxito de la conexión y el éxito de los permisos son resultados independientes. Un cliente puede encontrar el servidor y reconocer sus herramientas sin tener una ruta válida hacia los archivos previstos.
Pensemos en un asistente ilustrativo que ayuda a un ingeniero a comparar documentos locales de diseño. La solicitud del usuario suena idéntica antes y después de una actualización del cliente. Sin embargo, la aplicación puede entrar en una ruta de protocolo diferente y encontrarse con requisitos de configuración distintos.
Si la configuración anterior dependía de Roots proporcionados por el cliente, adoptar la ruta moderna exige prestar atención a los directorios de inicio. La redacción del usuario no revela esa dependencia. Tampoco la revela una lista de herramientas que indique que existen operaciones con archivos.
Por eso los permisos deben formar parte del análisis de migración, y no quedar como una nota al pie. El acceso a archivos conecta directamente el comportamiento del protocolo con las expectativas de los usuarios. Una discrepancia de configuración puede parecerle al usuario falta de conocimiento o que el asistente no entiende una solicitud.
También puede complicar la resolución de problemas. Un equipo podría investigar la calidad de recuperación, es decir, la eficacia con la que el software encuentra información relevante, cuando la herramienta subyacente no puede acceder a la ubicación prevista. La documentación de la versión ayuda a distinguir esas posibilidades.
Para los flujos de trabajo de conocimiento, los equipos deben diferenciar el límite de acceso de un conector de la calidad del sistema de información resultante. Una base de conocimiento con capacidad de búsqueda depende de que los documentos relevantes estén disponibles, organizados y se puedan recuperar. La compatibilidad con el protocolo solo aborda una parte de esa cadena.
El ejemplo también limita lo que los desarrolladores deben inferir de la compatibilidad con versiones anteriores. Que el comportamiento heredado continúe no implica una configuración de permisos idéntica para un cliente moderno. Ambas rutas pueden ser compatibles y, al mismo tiempo, depender de mecanismos diferentes.
Para las organizaciones que evalúan asistentes, esa diferencia plantea una cuestión concreta de compra. ¿Qué componente define las ubicaciones accesibles y cómo comunica la aplicación que el acceso falta o ha sido retirado? La respuesta debe describir el comportamiento real, en lugar de limitarse a enumerar estándares compatibles.
La versión facilita la investigación de esta cuestión porque la implementación de referencia documenta sus límites. Otras integraciones siguen requiriendo sus propias pruebas. Copiar la etiqueta del protocolo no demuestra que apliquen reglas de acceso equivalentes.
