¿Qué es MCP, y por qué de pronto todas las herramientas de IA lo hablan?
Durante la mayor parte de la última década, conectar un modelo de IA con las herramientas de su empresa significaba una integración a medida para cada par. Model Context Protocol, el estándar abierto que Anthropic presentó en noviembre de 2024, sustituyó eso por un único conector que encaja en todas partes, y OpenAI, Google y Microsoft lo han adoptado desde entonces. Así es como funciona de verdad, y una lista de comprobación real antes de conectar uno a los datos de su equipo.
Abra la aplicación de escritorio de Claude y pídale que revise las pull requests abiertas de su equipo, y simplemente puede hacerlo. No porque Anthropic haya integrado GitHub en Claude. Sino porque en algún sitio — 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 hablar con cualquier cosa que lo hable. Lo mismo ocurre ahora con ChatGPT, Gemini de Google y Microsoft Copilot. Esa convergencia, más que cualquier lanzamiento de función aislado, es la razón por la que MCP se ha convertido en aquello para lo que casi todos los proveedores de IA dedicaron el último año a construir soporte.
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. Sus propios materiales de lanzamiento describieron la idea con una analogía que se quedó: piense 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 los primeros adoptantes que ya estaban incorporando soporte de 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ó, el mismo día, con la capacidad de ejecutar servidores MCP en local en el propio equipo de una persona.
El problema que resuelve: N herramientas por M fuentes de datos
El problema que MCP resuelve tiene un nombre que los ingenieros usan con naturalidad: el problema de integración N por M. Supongamos que una empresa usa cinco herramientas de IA que necesitan actuar sobre los datos de la compañía — Claude, ChatGPT, GitHub Copilot, Cursor y un bot de soporte interno — y que esos datos viven en ocho sitios: Slack, GitHub, una base Postgres, Salesforce, Notion, Google Drive, Jira y una API interna. Sin un protocolo compartido, conectar cada herramienta con cada fuente de forma útil exige hasta cuarenta integraciones distintas — cinco por ocho — cada una con su propio esquema de autenticación, su propio manejo de errores y su propio coste de mantenimiento cada vez que una de esas API cambia de forma. Añada 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 merecía el tiempo de ingeniería, y todo lo demás se quedó en manual: copiar, pegar, volver a explicar, repetir.
MCP convierte la multiplicación en suma. Una empresa que quiere que Claude lea de su base Postgres no construye un conector de Postgres específico para Claude. Construye — o reutiliza uno que otra persona 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 prefabricados 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. Es que cualquiera podía hacerlo, y el catálogo de servidores disponibles ha crecido mucho más allá de lo que una sola empresa podría dotar de personal.
Cómo funciona el protocolo en realidad
Si se quita el marco, MCP es un protocolo cliente-servidor bastante sencillo, deliberadamente poco glamuroso. Define tres roles. Un Host es la aplicación que una persona abre de verdad — 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 ya habitual en la infraestructura existente, sobre uno de dos transportes: stdio, cuando el servidor es un programa que corre en local en la misma máquina, o Streamable HTTP, cuando es un servicio alojado que corre en otro sitio.
Lo que un servidor puede exponer se reduce a tres primitivas. Los Tools son funciones que el modelo puede llamar para actuar — create_task, run_query, send_message — y el modelo decide cuándo llamar a una según la conversación. Los Resources son contexto de solo lectura que el Host puede traer y entregar al modelo sin que este tenga que pedirlo — el contenido de un archivo, un esquema de base de datos, un ticket de soporte. Los Prompts son plantillas reutilizables, disparadas por la persona — un «resume este hilo» o «redacta una actualización de estado» ya preparado, que alguien invoca de forma explícita, en lugar de algo que el modelo decide hacer por su cuenta. Un servidor bien construido deja explícito cuál de los tres ofrece para una capacidad dada, porque esa distinción es exactamente 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 genuinamente inusual en la IA: competidores directos convergieron en el protocolo de una sola empresa en lugar de publicar el suyo. OpenAI añadió soporte de MCP a su Agents SDK en marzo de 2025, y permitió a los desarrolladores conectar flujos de agentes a cualquier servidor MCP en lugar de construir integraciones de herramientas a medida, específicas de OpenAI. Al mes siguiente, Google DeepMind confirmó que Gemini y su propio kit de desarrollo de agentes también soportarían MCP — un movimiento que Google emparejó con su propio protocolo complementario, Agent2Agent, pensado para que agentes independientes se coordinen entre sí y no solo con herramientas. En mayo de 2025, Microsoft había llevado soporte nativo de MCP a Windows 11 a través de lo que llama Windows AI Foundry, y el soporte también llegó a GitHub Copilot y 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 envían ahora productos que hablan el mismo protocolo para conectar un agente con una herramienta. Eso es lo bastante raro en este sector como para ser la historia de verdad — más que cualquier función individual que MCP haga posible.
Por qué esto es una cuestión de confianza, no solo de fontanería
Esa convergencia es genuinamente útil, y es exactamente la razón por la que MCP merece escrutinio y no confianza ciega. Un protocolo que vuelve muy fácil que un agente se conecte a los sistemas de su empresa es un protocolo que vuelve igual de fácil que una conexión mal construida o mal configurada alcance esos mismos sistemas. MCP por sí mismo no lo impide. La especificación define cómo hablan un cliente y un servidor — no dice nada sobre quién puede conceder una conexión, qué puede tocar esa conexión, o si alguien se dará cuenta si algo sale mal. Esas decisiones quedan por completo en quien construyó o configuró el servidor o el cliente concreto que tiene delante. Algunos proveedores construyen todo eso con cuidado. Otros no lo construyen en absoluto, y el protocolo no se lo va a impedir.
MCP es un protocolo de cableado, no un sistema de control de acceso. Estandariza cómo un agente pide a una herramienta que haga algo. Si esa petición está acotada, registrada y es revocable es una decisión que alguien tomó — o no — por encima.
Una lista de comprobación antes de conectar uno
Antes de que su equipo conecte un servidor MCP — ya sea un producto de un proveedor, una herramienta de código abierto que alguien encontró en GitHub, o algo construido internamente — seis preguntas separan una conexión gobernada de una puerta abierta. Ninguna exige leer la especificación. Solo exigen que alguien pregunte antes de pulsar aprobar, y que lea de verdad la respuesta que devuelve la pantalla de conexión.
| Pregunte esto | Cómo se ve lo bueno | Vigile |
|---|---|---|
| ¿Qué alcances o tools solicita? | Detallado Una lista concreta y con nombre que puede leer antes de aprobar — «crear tareas, leer mensajes de este canal». | General «Acceso completo a la cuenta», sin una lista de lo que realmente puede hacer. |
| ¿Es de solo lectura, o puede escribir y actuar? | Separado Acceso de lectura por defecto; cualquier acción que cambie datos necesita su propia concesión visible. | Agrupado Acceso de escritura 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 ve lo que esa persona puede ver. | Compartido Una clave 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 Ningún rastro más allá de lo que la propia herramienta de IA decide contarle. |
| ¿Se puede revocar al instante? | Inmediato Un interruptor, con efecto en el acto, desde una página de ajustes que usted controla. | Demorado Revocar exige un ticket de soporte, una llamada al proveedor, o no es posible en absoluto. |
| ¿Revocarlo rompe alguna otra cosa? | Aislado Acotado a esa única conexión; apagarla solo afecta a esa. | Enredado Comparte una credencial con otras herramientas, así que revocar una rompe en silencio otras tres. |
Cómo se ve de verdad una conexión bien construida
La propia configuración MCP de FabricLoop es una respuesta concreta a esa lista — no porque sea inusual, sino porque cada pieza corresponde directamente a una de las seis preguntas de arriba, y merece la pena nombrar la mecánica real y no la versión de marketing. FabricLoop actúa en ambos roles a la vez: es un servidor MCP al que se conectan herramientas externas, de modo que Cursor, Claude o ChatGPT pueden crear una tarea, añadir un comentario o leer una nota con los permisos de FabricLoop de una persona concreta — y es un cliente MCP que se conecta hacia fuera, de modo que un canal puede incorporar la app MCP de un proveedor, como GitHub o Linear, y mencionarla con @ como a un compañero de equipo.
Cada conexión, en cualquiera de los dos sentidos, empieza por una persona, no por 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 los tools concretos que pide el cliente — el cliente solo puede actuar después con los alcances concedidos en esa pantalla, bajo los permisos de esa única persona, nunca con una cuenta de servicio compartida. El sentido inverso funciona igual: un administrador puede activar la app MCP de un proveedor para todo el equipo, pero cada persona sigue completando su propio inicio de sesión antes de que funcione para ella, y un administrador puede poner esa app en modo de solo lectura o limitarla a una lista de tools concretos, en lugar de todo lo que el proveedor expone.
Cada cliente conectado aparece en una pantalla de ajustes junto a un control de Revocar que lo desconecta de inmediato — la página de la propia persona, no un ticket de soporte. En los planes Enterprise, esa actividad — incluidas las concesiones MCP y lo que un agente conectado hizo de verdad — llega a un registro de auditoría que un equipo de seguridad puede revisar cuando lo necesite, en lugar de capturas sacadas de un hilo de chat a posteriori.
Nada de eso es ingeniería exótica. Es un conjunto pequeño de decisiones, deliberadamente poco glamurosas, repetidas con constancia: acotar, vincular a una persona, registrar, hacer que se pueda revocar sin daño colateral. Es el mismo argumento que este sitio sostiene de forma más amplia sobre la Legibility — un acceso que se puede nombrar, registrar y revocar gana a un acceso en el que nadie tiene que pensar — y MCP solo entrega eso cuando alguien lo construye así. El protocolo hace estándar la fontanería. No hace automática la gobernanza.
La decisión que de verdad importa
MCP no va a desaparecer, y oponerse a estas alturas se parece un poco a oponerse al USB. Todos los grandes proveedores de modelos ya lo envían, 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 gran cosa. La decisión interesante no es si dejar que una herramienta de IA se conecte a sus sistemas — cada vez más, alguna versión de esa decisión ya se toma por usted, una integración cada vez, mientras herramientas que su equipo ya usa añaden en silencio soporte de MCP debajo de una función en la que hizo clic sin leer la letra pequeña. La decisión que todavía es suya de verdad es qué comprueba antes de pulsar aprobar.
MCP estandarizó cómo un agente de IA pide a una herramienta que haga algo. No hizo nada por estandarizar si es seguro conceder esa petición — esa parte sigue siendo, y seguirá siendo, una decisión de la persona que pulsa «aprobar».