Hace diez meses, cuando Anthropic anuncio Model Context Protocol el 25 de noviembre de 2024, muchos lo recibimos con el escepticismo habitual ante una propuesta de estandar empujada por un solo proveedor. Lo he comentado antes: los estandares de facto se consolidan mas por adopcion que por elegancia de diseno. 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.
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 categorias de clientes que han incorporado soporte, destacan los editores de codigo como Cursor, VS Code con su extension oficial y Zed, las aplicaciones tipo asistente como Claude Desktop y Claude Code, y las plataformas de agentes como Cline o Continue. Cada uno ha implementado MCP no como un anexo, sino como mecanismo primario de conexion a herramientas externas.
Lo mas interesante es que la adopcion ha cruzado lineas de proveedor. OpenAI, historicamente reacio a estandares que no controla, anuncio soporte para MCP en el SDK de Agents en marzo de 2025 y desde entonces la compatibilidad ha ido creciendo. 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 adopcion cruzada es lo que distingue un estandar real de un intento de estandar: cuando tus competidores lo adoptan sin forzar, ya no es propuesta sino realidad.
El otro hito fue la apertura del registro publico de servidores MCP, que permite descubrir servidores por categoria, verlos auditados por la comunidad y asegurar cierta calidad minima. 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. El registro no es exhaustivo ni perfecto, pero reduce enormemente el coste de descubrimiento frente a la caza manual por GitHub.
Lo que MCP resuelve que function calling no resolvia
En este momento ya hay suficiente perspectiva para entender por que MCP ha despegado donde function calling tradicional no habia generado un ecosistema similar. Function calling es una interfaz: tu le pasas al modelo una lista de funciones con sus esquemas y el modelo elige cual 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 sesion, no solo una interfaz. Un servidor MCP no es un endpoint sin estado que devuelve JSON: es un proceso que mantiene conexion con el cliente, que puede exponer herramientas, recursos y prompts, y que puede emitir notificaciones y gestionar permisos de forma explicita. Esa diferencia estructural permite cosas que function calling hacia con dificultad: servidores que descubren capacidades dinamicamente, herramientas que consumen recursos del sistema del usuario con permiso explicito, flujos con autenticacion delegada.
El otro elemento clave es la separacion 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, o que un script escrito pensando en OpenAI pueda funcionar con Gemini sin modificaciones.
Los servidores que han marcado tendencia
Repasando el registro y lo que veo usar en la comunidad, hay cuatro categorias donde MCP ha tenido el mayor impacto. La primera es la de integraciones con sistemas de codigo. Los servidores para GitHub, Gitea y GitLab permiten a un agente crear pull requests, revisar codigo, aprobar cambios y navegar issues, todo dentro de la sesion de un editor. En mi propio dia a dia, el servidor MCP de Gitea que mantengo conectado me permite cerrar issues desde un agente sin salir del contexto.
La segunda es la de sistemas de archivos y ejecucion local. Hay servidores para filesystem, shell, Docker y Kubernetes que dan a los agentes acceso controlado a recursos del usuario con permisos explicitos. El patron de aceptar ejecuciones de comandos una a una desde el cliente, con posibilidad de aprobar por lote o por patron, ha demostrado ser una interfaz de seguridad razonable, aunque no perfecta.
La tercera es la de bases de datos y busqueda. Servidores para PostgreSQL, SQLite, Elasticsearch y varios vectoriales permiten que un agente consulte datos especificos del usuario sin tener que entrenarse con ellos. Esto es clave para casos RAG ligeros donde no vale la pena montar una infraestructura dedicada.
La cuarta, menos obvia pero muy usada, es la de integraciones con servicios SaaS del usuario. Servidores para Slack, Notion, Linear, Jira o Calendar permiten delegar tareas de gestion a un agente, como resumir hilos, crear tickets o cerrar reuniones, directamente desde el editor o la aplicacion del asistente.
Lo que sigue flojo
No todo ha madurado al mismo ritmo. Hay tres areas donde MCP todavia arrastra debilidades. La primera es la 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 publicos de servidores MCP que ejecutaban codigo con mas privilegios de los que el usuario entendia. La especificacion ha ido endureciendose, pero el ecosistema de servidores publicos todavia tiene calidad dispar y la auditoria es insuficiente.
La segunda es la documentacion y descubribilidad de capacidades. Muchos servidores publicos son pequenios proyectos con documentacion sumaria, lo que dificulta saber exactamente que hacen sin leer el codigo. El registro ha ayudado, pero la calidad editorial sigue siendo desigual. Un usuario que quiere conectar un servidor MCP nuevo con frecuencia acaba probando y depurando, no leyendo documentacion limpia.
La tercera es el rendimiento en sesiones largas. MCP mantiene estado entre llamadas, lo que es util pero tambien abre la puerta a fugas de memoria o crecimiento descontrolado de contextos en sesiones de horas. Algunos clientes gestionan esto bien, otros no. En sesiones maratonianas de depuracion con multiples servidores activos, he visto caidas por agotamiento de recursos que no tenian que ver con el modelo sino con los procesos auxiliares.
Cuando no usarlo
Dicho todo lo bueno, MCP no es la respuesta para todo. Si tu caso de uso es sintetico y aislado, como un agente de un solo paso que consulta una API publica, un simple function calling sigue siendo mas ligero y mas facil de mantener. Si tu entorno es embebido o de baja latencia, la sobrecarga de un protocolo de sesion puede no compensar. Si tu equipo valora independencia del proveedor como prioridad maxima, toca verificar que la implementacion del cliente MCP que elijas no introduce dependencias indirectas.
Tambien hay casos donde los agentes aun no son la solucion: flujos criticos con cambios frecuentes de regulacion, escenarios donde la trazabilidad legal importa mas que la flexibilidad. En esos casos, un flujo scriptado tradicional con integraciones concretas sigue siendo mas defendible que un agente con cien servidores MCP conectados.
Mi lectura
Model Context Protocol ha superado la fase de curiosidad y esta en plena fase de consolidacion. Para cualquiera que este construyendo agentes o integrando LLMs con herramientas externas, hoy es mas sensato apoyarse en MCP que inventar su propia capa de integracion. El coste de entrada es bajo, la comunidad acompanya y el ecosistema premia a quien se suma pronto.
La lectura mas interesante es que MCP ha cambiado la forma en que pensamos la integracion de modelos con el mundo. Hace un anio hablabamos de function calling como la frontera. Hoy hablamos de ecosistemas de servidores intercambiables entre proveedores. Ese es un salto arquitectonico, no una mejora incremental, y conviene reconocerlo como tal.
Mi prediccion razonada es que los proximos doce meses veran consolidacion de capacidades mas que cambios radicales de diseno. Version 2 de la especificacion, si llega, sera probablemente refinamiento de seguridad, descubribilidad y rendimiento, no replanteamiento. MCP ya es parte del paisaje.
{:es}Preguntas frecuentes{:}{:en}Frequently asked questions{:}
{:es}¿Qué es el Model Context Protocol (MCP)?{:}{:en}What is the Model Context Protocol (MCP)?{:}
{:es}MCP es un protocolo abierto de Anthropic que estandariza cómo los modelos de IA acceden a herramientas y fuentes de datos externas. Define una interfaz común servidor-cliente que cualquier LLM o editor puede implementar para conectar el modelo con sistemas reales.{:}{:en}MCP is an open protocol from Anthropic that standardizes how AI models access external tools and data sources. It defines a common server-client interface that any LLM or editor can implement to connect the model with real systems.{:}
{:es}¿MCP reemplaza a la llamada de funciones (function calling)?{:}{:en}Does MCP replace function calling?{:}
{:es}No, son capas complementarias. Function calling es el mecanismo por el que un modelo indica que quiere usar una herramienta. MCP es el protocolo de transporte y descubrimiento que describe qué herramientas están disponibles de forma estandarizada entre clientes y servidores.{:}{:en}No, they are complementary layers. Function calling is the mechanism by which a model indicates it wants to use a tool. MCP is the transport and discovery protocol that describes what tools are available in a standardized way across clients and servers.{:}
{:es}¿Puedo crear mi propio servidor MCP?{:}{:en}Can I create my own MCP server?{:}
{:es}Sí. Anthropic publica SDKs oficiales para Python y TypeScript. Un servidor mínimo se crea en pocas decenas de líneas, exponiendo funciones que el modelo puede descubrir y llamar. La comunidad tiene ya cientos de servidores open source.{:}{:en}Yes. Anthropic publishes official SDKs for Python and TypeScript. A minimal server can be created in a few dozen lines, exposing functions the model can discover and call. The community already has hundreds of open source servers.{:}
