¿Qué es MCP y por qué de pronto todas las herramientas de IA lo hablan?
Durante casi toda la última década, conectar un modelo de IA con las herramientas de una empresa significaba una integración a medida para cada par. Model Context Protocol, el estándar abierto que Anthropic presentó en noviembre de 2024, lo reemplazó por un solo conector que entra en todas partes — y OpenAI, Google y Microsoft lo han adoptado desde entonces. Así es como funciona de verdad, y una lista de verificación real antes de conectar uno a los datos de su equipo.
Abran la aplicación de escritorio de Claude y pídanle que revise los pull requests abiertos de su equipo: simplemente puede hacerlo. No porque Anthropic haya metido una integración de GitHub dentro de Claude. Sino porque en algún lugar — su equipo de TI, un proveedor, un desarrollador en GitHub — alguien escribió un programa pequeño que habla un protocolo llamado MCP, y Claude ya sabe cómo hablar con cualquier cosa que lo hable. Lo mismo ocurre ahora con ChatGPT, Gemini de Google y Microsoft Copilot. Esa convergencia, más que el lanzamiento de cualquier función suelta, es la razón por la que MCP se convirtió en aquello para lo que casi todos los proveedores de IA pasaron el último año construyendo compatibilidad.
Qué es MCP en realidad
MCP significa Model Context Protocol. Anthropic lo diseñó y publicó la especificación en código abierto, junto con los primeros SDK, el 25 de noviembre de 2024. Su propio material de lanzamiento describió la idea con una analogía que se quedó: piensen en MCP como un puerto USB-C para aplicaciones de IA — un estándar de conector físico en lugar de un cable distinto para cada accesorio. En el lanzamiento, Anthropic nombró a quienes ya estaban metiendo compatibilidad con MCP en sus propios productos, entre ellos las empresas de software empresarial Block y Apollo, y los fabricantes de herramientas para desarrolladores Zed, Replit, Codeium y Sourcegraph. La aplicación de escritorio de Claude salió, ese mismo día, con la capacidad de ejecutar servidores MCP de forma local en la propia computadora de una persona.
El problema que resuelve: N herramientas por M fuentes de datos
El problema que resuelve MCP tiene un nombre que los ingenieros usan con naturalidad: el problema de integración N por M. Digamos que una empresa usa cinco herramientas de IA que necesitan actuar sobre los datos de la empresa — Claude, ChatGPT, GitHub Copilot, Cursor y un bot interno de soporte — y que esos datos viven en ocho lugares: Slack, GitHub, una base de datos Postgres, Salesforce, Notion, Google Drive, Jira y una API interna. Sin un protocolo compartido, conectar cada herramienta con cada fuente de una forma útil exige hasta cuarenta integraciones separadas — cinco por ocho — cada una con su propio esquema de autenticación, su propio manejo de errores y su propio costo de mantenimiento cada vez que una de esas API cambia de forma. Agreguen una sexta herramienta de IA y el número salta a cuarenta y ocho. En la práctica, nadie construyó las cuarenta. Cada proveedor de IA construyó el puñado que consideró que valía el tiempo de ingeniería, y todo lo demás se quedó manual: copiar, pegar, volver a explicar, repetir.
MCP convierte la multiplicación en suma. Una empresa que quiere que Claude lea su base de datos Postgres no construye un conector de Postgres específico para Claude. Construye — o reutiliza uno que alguien más ya publicó — un servidor MCP que expone Postgres, y ese servidor funciona con Claude, ChatGPT, Gemini o cualquier otro agente compatible con MCP, sin más código. La propia lista de Anthropic, en el lanzamiento, nombraba servidores ya armados para Google Drive, Slack, GitHub, Git, Postgres y una herramienta de automatización de navegador llamada Puppeteer. El punto nunca fue que Anthropic los construyera todos. El punto es que cualquiera podía, y el catálogo de servidores disponibles creció mucho más allá de lo que una sola empresa podría sostener con su personal.
Cómo funciona el protocolo en realidad
Si se quita el marco, MCP es un protocolo cliente-servidor bastante sencillo, poco glamuroso a propósito. Define tres roles. Un Host es la aplicación que una persona realmente abre — Claude Desktop, un IDE como Cursor, la app de ChatGPT. El Host incorpora un MCP Client, que abre una conexión directa y con estado hacia un MCP Server — un programa pequeño que expone un sistema concreto: una base de datos, una herramienta de tickets, un sistema de archivos, una API interna. Cliente y servidor intercambian mensajes con formato JSON-RPC 2.0, un formato ligero de llamada a procedimiento remoto que ya es común en la infraestructura existente, por uno de dos transportes: stdio, cuando el servidor es un programa que corre en la misma computadora, o Streamable HTTP, cuando es un servicio alojado que corre en otro lado.
Lo que un servidor puede exponer se reduce a tres primitivas. Las Tools son funciones que el modelo puede llamar para hacer algo — create_task, run_query, send_message — y el modelo decide cuándo llamar una según la conversación. Los Resources son contexto de solo lectura que el Host puede traer y pasarle al modelo sin que este tenga que pedirlo — el contenido de un archivo, el esquema de una base de datos, un ticket de soporte. Los Prompts son plantillas reutilizables que dispara la persona — un "resume este hilo" o "redacta una actualización de estado" enlatado, que alguien invoca de forma explícita, y no algo que el modelo decide hacer por su cuenta. Un servidor bien construido deja claro cuál de las tres ofrece para una capacidad dada, porque esa distinción es justo lo que determina si una herramienta de IA conectada puede mirar algo o cambiarlo.
Quién más lo adoptó, y cuándo
Los primeros meses de MCP fueron un proyecto solo de Anthropic. Eso cambió rápido, y de una forma que de verdad es poco común en la IA: competidores directos convergieron en el protocolo de una sola empresa en lugar de publicar el suyo. OpenAI agregó compatibilidad con MCP a su Agents SDK en marzo de 2025, para que los desarrolladores conectaran flujos de agentes a cualquier servidor MCP en lugar de construir integraciones de herramientas hechas a medida y específicas de OpenAI. Al mes siguiente, Google DeepMind confirmó que Gemini y su propio kit de desarrollo de agentes también iban a ser compatibles con MCP — un movimiento que Google acompañó con su propio protocolo complementario, Agent2Agent, pensado para que agentes independientes se coordinen entre sí y no solo con herramientas. Para mayo de 2025, Microsoft había llevado compatibilidad nativa con MCP a Windows 11 a través de lo que llama Windows AI Foundry, y la compatibilidad también llegó a GitHub Copilot y a Copilot Studio.
Ninguna de esas cuatro empresas coincide en gran cosa cuando se trata de arquitectura de modelos, precios o estrategia de plataforma. Las cuatro ahora publican productos que hablan el mismo protocolo para conectar un agente con una herramienta. Eso es tan poco frecuente en esta industria que es la historia de verdad — más que cualquier función individual que MCP habilite.
Por qué esto es una cuestión de confianza, no solo de plomería
Esa convergencia es útil de verdad, y es exactamente la razón por la que MCP merece revisión y no confianza ciega. Un protocolo que vuelve trivial que un agente se conecte a los sistemas de su empresa es un protocolo que vuelve trivial que una conexión mal construida o mal configurada llegue a esos mismos sistemas. MCP en sí no lo impide. La especificación define cómo hablan un cliente y un servidor — no dice nada sobre quién puede autorizar una conexión, qué puede tocar esa conexión, o si alguien se va a dar cuenta si algo sale mal. Esas decisiones quedan por completo en quien construyó o configuró el servidor o el cliente que tienen enfrente. Algunos proveedores construyen todo eso con cuidado. Otros no lo construyen en absoluto, y el protocolo no los va a detener.
MCP es un protocolo de transmisión, no un sistema de control de acceso. Estandariza cómo un agente le pide a una herramienta que haga algo. Si ese pedido tiene alcance, queda registrado y se puede revocar es una decisión que alguien tomó — o no tomó — por encima de él.
Una lista de verificación antes de conectar uno
Antes de que su equipo conecte un servidor MCP — sea el producto de un proveedor, una herramienta de código abierto que alguien encontró en GitHub, o algo construido en casa — seis preguntas separan una conexión gobernada de una puerta abierta. Ninguna exige leer la especificación. Solo exigen que alguien pregunte antes de hacer clic en aprobar, y que de verdad lea la respuesta que devuelve la pantalla de conexión.
| Pregunten esto | Así se ve lo bueno | Ojo con esto |
|---|---|---|
| ¿Qué alcances o herramientas pide? | Detallado Una lista nombrada y concreta que se puede leer antes de aprobar — "crear tareas, leer mensajes en este canal". | General "Acceso total a la cuenta", sin una lista de lo que en realidad puede hacer. |
| ¿Es de solo lectura, o puede escribir y actuar? | Separado Lectura por defecto; cualquier acción que cambie datos necesita su propia autorización visible. | Junto El acceso de escritura viene incluido de forma automática, sin manera de saber qué capacidad hace qué. |
| ¿Es por persona o compartido en todo el equipo? | Por persona Cada persona inicia sesión con su propio acceso; el agente solo puede ver lo que esa persona puede ver. | Compartido Una clave de API o una cuenta de servicio usada por todo el equipo, que se salta los permisos individuales. |
| ¿Hay un registro de auditoría de lo que hizo? | Registrado Cada llamada a una herramienta queda anotada — quién la conectó, qué tocó y cuándo. | Sin registro No hay constancia más allá de lo que la propia herramienta de IA decida contarles que pasó. |
| ¿Se puede revocar al instante? | Inmediato Un interruptor, con efecto de inmediato, desde una página de configuración que ustedes controlan. | Demorado Revocar exige un ticket de soporte, una llamada al proveedor, o directamente no se puede. |
| ¿Revocarlo rompe alguna otra cosa? | Aislado Limitado a esa sola conexión; apagarla afecta solo a esa. | Enredado Comparte una credencial con otras herramientas, así que revocar una rompe en silencio otras tres. |
Cómo se ve en realidad una conexión bien construida
La propia configuración MCP de FabricLoop es una respuesta concreta a esa lista — no porque sea rara, sino porque cada pieza corresponde directo a una de las seis preguntas de arriba, y vale la pena nombrar la mecánica real y no la versión de marketing. FabricLoop corre en los dos roles a la vez: es un servidor MCP al que se conectan herramientas de afuera, de modo que Cursor, Claude o ChatGPT pueden crear una tarea, agregar un comentario o leer una nota usando los permisos de FabricLoop de una persona concreta — y es un cliente MCP que se conecta hacia afuera, de modo que un canal puede traer la app MCP de un proveedor, como GitHub o Linear, y mencionarla con @ como a un compañero de equipo.
Toda conexión, en cualquiera de las dos direcciones, empieza con una persona, no con un espacio de trabajo. Conectar un cliente externo como Cursor abre una pantalla de consentimiento OAuth en app.fabricloop.com/oauth/consent, donde esa persona elige un espacio de trabajo y aprueba las herramientas concretas que el cliente está pidiendo — el cliente después solo puede actuar con los alcances concedidos en esa pantalla, bajo los permisos de esa sola persona, nunca con una cuenta de servicio compartida. La dirección inversa funciona igual: un administrador puede habilitar la app MCP de un proveedor para todo el equipo, pero cada persona igual completa su propio inicio de sesión antes de que le funcione, y un administrador puede poner esa app en modo de solo lectura o limitarla a una lista de herramientas específicas, en lugar de todo lo que el proveedor expone.
Cada cliente conectado aparece en una pantalla de configuración junto a un control de Revocar que lo desconecta de inmediato — en la propia página de la persona, no en un ticket de soporte. En los planes Enterprise, esa actividad — incluidos los permisos MCP y lo que un agente conectado hizo de verdad — queda en un registro de auditoría que un equipo de seguridad puede revisar cuando lo necesite, en lugar de capturas de pantalla sacadas de un hilo de chat después de los hechos.
Nada de eso es ingeniería exótica. Es un conjunto pequeño de decisiones, poco glamurosas a propósito, repetidas con constancia: acotar el alcance, atarlo a una persona, registrarlo, y hacerlo revocable sin daño colateral. Es el mismo argumento que este sitio hace sobre la Legibility en un sentido más amplio — un acceso que se puede nombrar, registrar y revocar le gana a un acceso en el que nadie tiene que pensar — y MCP solo entrega eso cuando alguien lo construye de esa manera. El protocolo vuelve estándar la plomería. No vuelve automática la gobernanza.
La decisión que de verdad importa
MCP no se va a ir, y oponerse a él a esta altura se parece un poco a oponerse al USB. Todos los grandes proveedores de modelos ya lo publican, la lista de servidores disponibles sigue creciendo, y un agente que no puede llegar a sus herramientas es, para la mayor parte del trabajo real, un agente que no puede hacer mucho. La decisión interesante no es si dejan que una herramienta de IA se conecte a sus sistemas — cada vez más, alguna versión de esa decisión ya se está tomando por ustedes, una integración a la vez, mientras las herramientas que su equipo ya usa agregan en silencio compatibilidad con MCP debajo de una función en la que hicieron clic sin leer la letra chica. La decisión que todavía es de ustedes es qué revisan antes de hacer clic en aprobar.
MCP estandarizó cómo un agente de IA le pide a una herramienta que haga algo. No hizo nada para estandarizar si es seguro conceder ese pedido — esa parte sigue siendo, y va a seguir siendo, una decisión de la persona que hace clic en "aprobar".