Model Context Protocol en 2025: del anuncio al ecosistema

Actualizado: 2026-05-03

Hace diez meses, cuando Anthropic anunció Model Context Protocol el 25 de noviembre de 2024, muchos lo recibimos con el escepticismo habitual ante una propuesta de estándar empujada por un solo proveedor. En septiembre de 2025, con cientos de servidores publicados, un registro oficial activo y soporte incorporado en clientes que no son de Anthropic, conviene volver a mirar MCP con ojos nuevos y separar lo que ha funcionado de lo que sigue siendo promesa.

Puntos clave

• MCP ha pasado de anuncio a infraestructura: Cursor, VS Code, Zed, Claude Desktop, OpenAI Agents SDK, Gemini CLI y VS Code Copilot de Microsoft ya lo implementan de forma nativa.
• La adopción cruzada entre proveedores — OpenAI, Google, Microsoft — es lo que distingue un estándar real de un intento de estándar.
• MCP es un protocolo de sesión (estado, recursos, notificaciones, permisos), no solo una interfaz de function calling sin estado — esta diferencia estructural es lo que ha permitido el ecosistema.
• Las cuatro categorías con mayor impacto: integraciones de código (GitHub, Gitea, GitLab), sistemas de archivos y ejecución local, bases de datos y búsqueda, y servicios SaaS del usuario (Slack, Notion, Linear).
• Los tres puntos débiles todavía en 2025: seguridad (modelo de permisos incompleto), documentación desigual, y rendimiento en sesiones largas (memory leaks en procesos auxiliares).

De anuncio a infraestructura real

El primer dato relevante es que MCP ha pasado de ser un anuncio a ser infraestructura. Entre las tres grandes categorías de clientes que han incorporado soporte destacan:

• Editores de código: Cursor, VS Code con su extensión oficial y Zed.
• Aplicaciones tipo asistente: Claude Desktop y Claude Code.
• Plataformas de agentes: Cline, Continue.

Cada uno ha implementado MCP no como un anexo, sino como mecanismo primario de conexión a herramientas externas.

Lo más interesante es que la adopción ha cruzado líneas de proveedor. OpenAI, históricamente reacio a estándares que no controla, anunció soporte para MCP en el SDK de Agents en marzo de 2025. Google ha integrado MCP en Gemini CLI y otros componentes durante el verano. Microsoft tiene soporte nativo en VS Code Copilot y en Azure AI Foundry. Esta adopción cruzada es lo que distingue un estándar real de un intento de estándar: cuando tus competidores lo adoptan sin forzar, ya no es propuesta sino realidad.

El otro hito fue la apertura del registro público de servidores MCP, que permite descubrir servidores por categoría, verlos auditados por la comunidad y asegurar cierta calidad mínima. En septiembre de 2025 hay varios cientos de servidores listados, desde integraciones con GitHub, Gitea y Jira hasta puentes a bases de datos, sistemas de archivos, APIs de pago y asistentes de navegador.

Lo que MCP resuelve que function calling no resolvía

En este momento ya hay suficiente perspectiva para entender por qué MCP ha despegado donde function calling tradicional no había generado un ecosistema similar.

Function calling es una interfaz: le pasas al modelo una lista de funciones con sus esquemas y el modelo elige cuál llamar. Eso funciona bien cuando las funciones son pocas y estables, y cuando el contexto del usuario se ajusta al sistema que las provee.

MCP es un protocolo de sesión, no solo una interfaz. Un servidor MCP no es un endpoint sin estado que devuelve JSON: es un proceso que mantiene conexión con el cliente, que puede exponer herramientas, recursos y prompts, y que puede emitir notificaciones y gestionar permisos de forma explícita. Esa diferencia estructural permite cosas que function calling hacía con dificultad:

• Servidores que descubren capacidades dinámicamente
• Herramientas que consumen recursos del sistema del usuario con permiso explícito
• Flujos con autenticación delegada

El otro elemento clave es la separación entre cliente y servidor. Con function calling, el proveedor del modelo define la interfaz y los usuarios adaptan sus herramientas. Con MCP, el usuario puede instalar servidores independientes del proveedor del modelo. Esta independencia es lo que ha permitido que un desarrollador con Claude Desktop pueda instalar un servidor MCP creado para Cursor y que funcione.

Los servidores que han marcado tendencia

Repasando el registro y lo que veo usar en la comunidad, hay cuatro categorías donde MCP ha tenido el mayor impacto:

Integraciones con sistemas de código: los servidores para GitHub, Gitea y GitLab permiten a un agente crear pull requests, revisar código, aprobar cambios y navegar issues, todo dentro de la sesión de un editor. En mi propio día a día, el servidor MCP de Gitea que mantengo conectado me permite cerrar issues desde un agente sin salir del contexto.

Sistemas de archivos y ejecución local: hay servidores para filesystem, shell, Docker y Kubernetes que dan a los agentes acceso controlado a recursos del usuario con permisos explícitos. El patrón de aceptar ejecuciones de comandos una a una desde el cliente, con posibilidad de aprobar por lote o por patrón, ha demostrado ser una interfaz de seguridad razonable — aunque no perfecta.

Bases de datos y búsqueda: servidores para PostgreSQL, SQLite, Elasticsearch y varios vectoriales permiten que un agente consulte datos específicos del usuario sin tener que entrenarse con ellos. Esto es clave para casos RAG ligeros donde no vale la pena montar una infraestructura dedicada — complementando lo que Redis 8.2 ofrece nativamente.

Integraciones con servicios SaaS del usuario: servidores para Slack, Notion, Linear, Jira o Calendar permiten delegar tareas de gestión a un agente directamente desde el editor o la aplicación del asistente.

Lo que sigue flojo

No todo ha madurado al mismo ritmo. Hay tres áreas donde MCP todavía arrastra debilidades:

Seguridad: el modelo de permisos de MCP es mejor que el de function calling improvisado, pero sigue siendo responsabilidad del cliente implementarlo bien. Ya ha habido varios incidentes públicos de servidores MCP que ejecutaban código con más privilegios de los que el usuario entendía. La especificación ha ido endureciéndose, pero el ecosistema de servidores públicos todavía tiene calidad dispar y la auditoría es insuficiente.

Documentación y descubribilidad de capacidades: muchos servidores públicos son pequeños proyectos con documentación sumaria. Un usuario que quiere conectar un servidor MCP nuevo con frecuencia acaba probando y depurando, no leyendo documentación limpia.

Rendimiento en sesiones largas: MCP mantiene estado entre llamadas, lo que es útil pero también abre la puerta a fugas de memoria o crecimiento descontrolado de contextos en sesiones de horas. En sesiones maratonianas de depuración con múltiples servidores activos, he visto caídas por agotamiento de recursos que no tenían que ver con el modelo sino con los procesos auxiliares.

Cuándo no usarlo

Dicho todo lo bueno, MCP no es la respuesta para todo:

• Si tu caso de uso es sintético y aislado, como un agente de un solo paso que consulta una API pública, un simple function calling sigue siendo más ligero y más fácil de mantener.
• Si tu entorno es embebido o de baja latencia, la sobrecarga de un protocolo de sesión puede no compensar.
• Si tu equipo valora independencia del proveedor como prioridad máxima, hay que verificar que la implementación del cliente MCP que elijas no introduce dependencias indirectas.

También hay casos donde los agentes aún no son la solución: flujos críticos con cambios frecuentes de regulación, escenarios donde la trazabilidad legal importa más que la flexibilidad. Para esos casos, un flujo scriptado tradicional con integraciones concretas sigue siendo más defendible que un agente con cien servidores MCP conectados. La Ley de IA europea añade un punto más: los flujos con agentes deben poder reconstruirse en caso de incidencia, y MCP con sesiones de estado complejo puede dificultar ese audit trail.

Mi lectura

Model Context Protocol ha superado la fase de curiosidad y está en plena fase de consolidación. Para cualquiera que esté construyendo agentes o integrando LLMs con herramientas externas, hoy es más sensato apoyarse en MCP que inventar su propia capa de integración. El coste de entrada es bajo, la comunidad acompaña y el ecosistema premia a quien se suma pronto.

La lectura más interesante es que MCP ha cambiado la forma en que pensamos la integración de modelos con el mundo. Hace un año hablábamos de function calling como la frontera. Hoy hablamos de ecosistemas de servidores intercambiables entre proveedores. Ese es un salto arquitectónico, no una mejora incremental, y conviene reconocerlo como tal.

Mi predicción razonada es que los próximos doce meses verán consolidación de capacidades más que cambios radicales de diseño. Versión 2 de la especificación, si llega, será probablemente refinamiento de seguridad, descubribilidad y rendimiento, no replanteamiento. MCP ya es parte del paisaje.