La mayoría de los equipos que crean flujos impulsados por IA se topan con el mismo muro hacia la tercera semana. Tienen un LLM operativo. Tienen datos en un CRM, un almacén de datos, quizá un sistema de archivos. Y tienen una pila creciente de código personalizado de conexión entre ambos: una integración a medida por fuente de datos, cada una ligeramente diferente, cada una propiedad de quien la escribió, cada una un riesgo silencioso de mantenimiento que nadie ha tenido plenamente en cuenta todavía.
Ese es el problema que Model Context Protocol fue creado para resolver. No es un producto ni una plataforma: es un estándar abierto que cambia la propia capa de integración. Entender qué es realmente MCP, cómo funciona su arquitectura y cuáles son sus límites reales lleva unos veinte minutos. Recuperarse de una mala decisión de adopción tomada sin ese entendimiento lleva considerablemente más tiempo.
Lo que la mayoría de los equipos aprende después de haberse comprometido
- MCP es un estándar abierto, no un producto: estandariza cómo los LLM se conectan a herramientas y datos, no qué contienen esas herramientas.
- El problema M×N es real: N fuentes de datos por M aplicaciones de IA equivale rápidamente a una deuda insostenible de integraciones personalizadas.
- MCP no sustituye las API, no gestiona los controles de acceso ni diseña su estrategia de recuperación: eso sigue siendo responsabilidad suya.
- OpenAI y Google DeepMind ya lo han adoptado, lo que reduce el riesgo de infraestructura de apostar por él.
¿Qué es Model Context Protocol (MCP)?
Model Context Protocol es un protocolo abierto presentado por Anthropic a finales de 2024 que estandariza cómo las aplicaciones de IA se conectan a herramientas externas, fuentes de datos e información contextual. Si ha escuchado la comparación de «USB-C para la IA» y la ha descartado como una fórmula de marketing, en realidad es más precisa de lo que parece a primera vista; entender por qué es precisa es la forma más rápida de entender qué es MCP.
Antes de USB-C, cada fabricante de dispositivos tenía su propio conector. El cargador de su portátil no servía para su teléfono. El cable de su teléfono no servía para su cámara. Cada dispositivo nuevo implicaba un cable nuevo, una nueva superficie de incompatibilidad, una nueva cosa que perder en un cajón. USB-C no sustituyó la electricidad. Estandarizó la interfaz para que un conector pudiera funcionar en muchos dispositivos.
MCP hace lo mismo en la capa de integración con LLM. Antes de MCP, cada aplicación de IA que necesitaba acceder a una fuente de datos externa requería una integración personalizada: un conector a medida, su propia lógica de autenticación, sus propias convenciones para transmitir contexto y su propia superficie de mantenimiento. MCP es un protocolo abierto que sustituye esos conectores únicos por una única interfaz estándar.
La base técnica es concreta. MCP se basa en JSON-RPC 2.0 y define conexiones con estado entre las aplicaciones de IA y los sistemas a los que se conectan. La especificación de MCP cubre el acceso estandarizado a archivos, funciones y prompts contextuales: tres tipos de capacidades que, en conjunto, abarcan la mayor parte de lo que un agente LLM necesita realmente de un sistema externo.
MCP es un protocolo abierto, lo que significa que no es propiedad exclusiva de Claude de Anthropic. Cualquier aplicación de IA puede implementar el estándar y conectarse a cualquier servidor compatible con MCP. La capa de protocolo estándar es lo que hace posible esa interoperabilidad. Y la adopción temprana del ecosistema —Block y Apollo estuvieron entre los primeros integradores mencionados en el anuncio de Anthropic— es lo que hizo que valiera la pena apostar por el ecosistema.
Conviene hacer una aclaración antes de continuar: MCP no es un producto que se compra ni una plataforma en la que se inicia sesión. Se implementa. Esa distinción importa para evaluar la tecnología.
El problema que MCP realmente resuelve: integraciones M×N
Imagine un equipo de ingeniería mediano que está creando tres aplicaciones internas de IA: un asistente de código, un agente de soporte al cliente y una herramienta de análisis de datos. Necesitan que cada una de esas aplicaciones acceda a cuatro fuentes de datos: GitHub, Jira, su almacén de datos y su CRM.
Son 3 aplicaciones por 4 fuentes de datos, es decir, 12 integraciones personalizadas. Cada una necesita lógica de autenticación, convenciones para transmitir contexto, gestión de errores y mantenimiento continuo. Cuando el CRM actualiza su API, cuatro de esas doce integraciones deben corregirse. Cuando se añade una nueva aplicación de IA, se crean desde cero cuatro conectores personalizados más.
Este es el problema de integración M×N —M aplicaciones de IA por N fuentes de datos— y es exactamente lo que resuelve MCP. En lugar de M×N conectores a medida, los equipos crean N servidores MCP, uno por fuente de datos, y M clientes MCP, uno por aplicación de IA. El protocolo gestiona la interfaz entre ambos. Añada una nueva aplicación de IA y se conectará a los servidores MCP existentes sin conectores nuevos. Añada una nueva fuente de datos y las aplicaciones de IA existentes podrán acceder a ella de inmediato.
La deuda de ingeniería acumulativa aquí es real. Cada integración personalizada es una superficie de mantenimiento. Cambie el nombre de un campo en el CRM y la integración que no seguía un estándar se rompe de una manera difícil de rastrear. Añada límites de velocidad a una API y cada conector a medida los gestionará de forma diferente, o no los gestionará en absoluto, que es cuando empiezan los fallos silenciosos. Sigo viendo repetirse este patrón: los equipos no notan que la integración está rota porque la aplicación de IA sigue funcionando, el panel permanece en verde y los datos obsoletos se acumulan silenciosamente en los procesos posteriores.
También hay un aspecto relacionado con las alucinaciones del que no se habla lo suficiente. Cuando los LLM reciben contexto incoherente, incompleto u obsoleto porque cada integración se creó de forma diferente y se mantiene con estándares distintos, el modelo rellena los huecos con invenciones plausibles. El problema de calidad de integración se convierte en un problema de calidad de respuesta. MCP reduce esa superficie al estandarizar cómo se transmite el contexto, de modo que al menos el mecanismo de entrega es coherente, aunque la calidad de los datos siga siendo responsabilidad suya.
Por qué las integraciones personalizadas se rompen con los flujos de IA agéntica
Los flujos de IA de un solo paso son permisivos. Se llama a una API, se obtiene contexto, el modelo responde y la interacción termina. Pero los sistemas de IA agéntica —los que toman secuencias de decisiones, invocan múltiples herramientas y operan de forma autónoma a lo largo del tiempo— son una situación diferente.
En un flujo agéntico, las conexiones a fuentes de datos se llaman repetidamente, en combinaciones que el desarrollador original no anticipó por completo, mediante un modelo que puede componer llamadas a herramientas en secuencias inesperadas. Un conector único y frágil que funcionaba bien en pruebas de un solo paso se rompe bajo esa carga de maneras realmente difíciles de diagnosticar. El comportamiento de las llamadas a herramientas es incoherente entre conectores porque cada uno fue creado por una persona distinta con supuestos diferentes. La superficie de mantenimiento crece con cada nueva herramienta a la que el agente necesita acceder.
MCP aborda esto proporcionando a los sistemas agénticos un contrato de interfaz predecible. El agente no necesita saber cómo funciona la integración personalizada de cada herramienta: utiliza el mismo patrón de protocolo para cada conexión. Esa coherencia es lo que los sistemas agénticos realmente necesitan.
Cómo MCP establece una única interfaz entre herramientas y fuentes de datos
Lo que MCP estandariza, en concreto, es la conversación entre una aplicación de IA y los sistemas a los que necesita acceder. Hay una forma definida de descubrir qué capacidades están disponibles, una forma definida de solicitarlas y una forma definida de recibir resultados, independientemente de lo que haya al otro lado de la conexión.
Esto es lo que significa en la práctica «estándar para conectar IA con herramientas y datos». Un modelo que se conecta a un servidor MCP de GitHub utiliza el mismo patrón de protocolo que utiliza para un servidor MCP de Jira. Las API subyacentes son diferentes. La interfaz MCP es la misma. MCP estandariza esa capa de interfaz, no los sistemas que hay detrás.
Para los equipos que crean flujos de IA con múltiples herramientas, esto tiene una consecuencia real: el trabajo de añadir una nueva fuente de datos se reduce de «crear una integración personalizada, gestionar la autenticación, definir convenciones para transmitir contexto y conectar la gestión de errores» a «conectarse al servidor MCP para esa fuente». El estándar hace el resto.
Arquitectura de MCP: cómo funciona el modelo cliente-servidor
La arquitectura es más fácil de entender cuando deja de pensar en MCP como un servicio y empieza a pensarlo como un protocolo: un conjunto de reglas sobre cómo deben comportarse dos partes en una conversación.
Hay tres roles en una interacción MCP: el host, el cliente y el servidor.
El host es la aplicación que contiene el LLM. Claude Desktop es un ejemplo. Un asistente de programación es otro. Este es el entorno donde se ejecuta la IA y es responsable de gestionar las conexiones de clientes MCP que alberga internamente.
El cliente MCP es el componente dentro del host que habla el protocolo. Mantiene una conexión con uno o más servidores MCP, negocia capacidades y traduce las solicitudes del modelo en llamadas MCP. Un host puede gestionar varios clientes, lo que significa que una única aplicación de IA puede comunicarse simultáneamente con muchos sistemas diferentes.
El servidor MCP es lo que se sitúa delante de una fuente de datos, una base de datos, un sistema de archivos o una API externa. Expone capacidades en un formato estandarizado y responde a las solicitudes de los clientes MCP. El servidor no sabe ni le importa qué host está al otro lado: simplemente habla el protocolo.
Clientes MCP, servidores MCP y qué hace realmente cada uno
El cliente MCP es la aplicación o el entorno de IA que inicia las solicitudes de capacidades. Cuando un modelo de lenguaje necesita leer un archivo, consultar una base de datos o invocar una función externa, la solicitud fluye a través del cliente MCP. El cliente se encarga de la negociación del protocolo y mantiene la conexión con los servidores MCP disponibles.
El servidor MCP es el componente que expone las capacidades reales. Se crea o despliega un servidor MCP delante de un sistema —GitHub, un CRM, un almacén de archivos— y ese servidor pone la funcionalidad del sistema a disposición de los clientes MCP de forma estandarizada. El host MCP gestiona la autenticación y el ciclo de vida de las conexiones abiertas. Los distintos servidores MCP disponibles pueden exponer capacidades superpuestas o complementarias, y el cliente las descubre en tiempo de ejecución.
Hay algo que conviene dejar explícito: los servidores MCP se sitúan delante de sistemas existentes. No sustituyen las API, bases de datos ni servicios externos que hay debajo de ellos. Un servidor MCP de GitHub sigue llamando a la API de GitHub internamente. Un servidor MCP que expone datos de su CRM sigue conectado a su CRM. MCP es infraestructura orientada al modelo que estandariza cómo las aplicaciones de IA acceden a esos sistemas subyacentes, no un sustituto de los propios sistemas.
Herramientas, recursos y prompts: las tres cosas que expone un servidor MCP
Existe una idea errónea persistente de que MCP es simplemente una mejor forma de hacer llamadas a funciones: exponer herramientas para que los LLM las invoquen, sin más. El servidor real expone tres tipos distintos de capacidades, y confundirlos lleva a construir una solución insuficiente.
Las herramientas son funciones ejecutables. El modelo puede invocarlas para realizar acciones: ejecutar una consulta, crear un registro, enviar un mensaje o comprobar un estado. Estas son las capacidades en las que la mayoría de las personas piensa inmediatamente cuando escucha «implementaciones de servidores MCP».
Los recursos son datos. Archivos, filas de bases de datos, contenido estructurado y documentación. El modelo puede leerlos para completar el contexto. Los servidores MCP también pueden exponer recursos que cambian con el tiempo, para que el modelo reciba contexto actualizado en lugar de instantáneas obsoletas.
Los prompts son plantillas contextuales: estructuras de prompt predefinidas que los servidores MCP proporcionan para ayudar a los modelos a interactuar con un sistema de forma más eficaz. A menudo se pasan por alto, pero son la forma en que los equipos codifican contexto específico de dominio en la capa de protocolo, para que el modelo no tenga que redescubrirlo en cada sesión.
Las tres capacidades juntas son lo que hace que MCP sea más que un envoltorio de llamadas a funciones. El protocolo está diseñado para proporcionar contexto, no solo para ejecutar acciones.
Cómo funciona MCP: JSON-RPC 2.0 y descubrimiento dinámico
MCP funciona sobre JSON-RPC 2.0, un protocolo ligero de llamadas a procedimientos remotos que utiliza JSON para codificar mensajes. Cada interacción MCP es una solicitud y respuesta estructuradas, con estado durante una sesión y con negociación de capacidades al establecer la conexión.
La parte de descubrimiento dinámico es lo que hace precisa la metáfora de «USB-C» a nivel arquitectónico. Cuando un cliente MCP se conecta a un servidor, pregunta qué capacidades están disponibles. El servidor responde con su conjunto actual de capacidades. El modelo puede usar esas capacidades sin necesitar conocimiento codificado de forma fija sobre lo que expone el servidor. Añada una nueva herramienta al servidor y el cliente la descubrirá en la siguiente conexión, sin que sea necesaria una actualización de integración.
📊 En la práctica:
El mecanismo de descubrimiento dinámico es la razón por la que un único cliente MCP puede conectarse a varios servidores simultáneamente e invocar capacidades en todos ellos durante una misma sesión, sin una nueva integración personalizada para cada uno. Un agente de IA que consulta GitHub, Jira y un CRM en un flujo puede hacerlo mediante tres conexiones a servidores MCP, todas usando el mismo patrón de protocolo. El modelo no gestiona tres interfaces. Utiliza una.
MCP frente a API: dónde está realmente el límite
Esta es la pregunta que veo surgir con más frecuencia después de que los equipos leen su primera explicación sobre MCP, y el malentendido es constante: la gente asume que MCP sustituye las API. No es así. Se sitúa sobre ellas.
Una API define cómo un sistema específico recibe solicitudes y devuelve respuestas. Es específica de cada sistema: la API de Salesforce es diferente de la API de Stripe, que es diferente de la API de GitHub, y está diseñada para llamadores deterministas que saben exactamente lo que solicitan. Las API son la abstracción adecuada para sistemas de software que se comunican con otros sistemas de software.
El problema es que los agentes LLM no deterministas no se comportan como los sistemas de software convencionales. No siempre saben de antemano qué capacidades necesitarán. Toman decisiones durante la ejecución. Componen llamadas a herramientas en secuencias que no se anticiparon completamente. La integración nativa de API, que presupone un llamador predecible, se vuelve frágil rápidamente cuando quien llama es un modelo que trabaja mediante una cadena de razonamiento de varios pasos.
MCP complementa esa capa de API subyacente al situarse por encima de ella, orientado al modelo. Un servidor MCP llama internamente a la API de Salesforce. Pero la aplicación de IA accede a Salesforce mediante la interfaz MCP, no mediante una integración directa de API. MCP proporciona una abstracción coherente para que el modelo no necesite conocer los detalles de cada API que utiliza: simplemente utiliza el protocolo.
La implicación práctica: la integración MCP no sustituye sus credenciales de API, su lógica de autenticación ni sus controles de acceso a fuentes de datos. Los abstrae desde la perspectiva del modelo. La API sigue ahí. La capa MCP es la interfaz orientada al modelo que se sitúa delante de ella.
Lo que MCP hace y las llamadas a funciones por sí solas no pueden hacer
Las llamadas a funciones permiten que un modelo invoque una capacidad específica en una herramienta específica. Son potentes para interacciones con una sola herramienta. Lo que no gestionan bien es el contexto multisistema: situaciones en las que el modelo necesita contexto relevante de una fuente, ejecuta una acción en otra y utiliza una plantilla de prompt de una tercera, todo en la misma sesión.
MCP ofrece un protocolo unificado para esas tres interacciones simultáneamente. Estandariza no solo la invocación de herramientas, sino también el acceso a recursos —datos actuales de sistemas conectados— y las plantillas de prompt —estructuras contextuales que ayudan al modelo a razonar bien sobre un dominio—. Esa combinación es lo que hace que MCP sea adecuado para flujos de IA conscientes del contexto que abarcan múltiples sistemas, frente a las llamadas a funciones de una sola herramienta que se detienen en el límite de una API.
MCP también puede complementar las llamadas a funciones: los equipos ya usan ambos enfoques juntos, con MCP gestionando la orquestación multisistema y las llamadas a funciones gestionando interacciones específicas de un solo sistema donde una llamada directa a API resulta más limpia. No se excluyen mutuamente. El límite del servicio externo es donde decide qué abstracción encaja mejor.
MCP frente a RAG: dos problemas distintos que suelen confundirse
Veo que se comparan como si fueran enfoques competidores para resolver el mismo problema. No lo son. Resuelven problemas diferentes en capas diferentes, lo que significa que casi siempre debe considerar ambos.
RAG, generación aumentada por recuperación, es una estrategia de tiempo de inferencia. Cuando un modelo necesita responder a una pregunta, un sistema RAG recupera documentos relevantes de una base de conocimiento y los inyecta en la ventana de contexto antes de que el modelo genere una respuesta. Su objetivo es introducir la información correcta en el contexto del modelo en el momento en que necesita razonar. La recuperación ocurre durante la inferencia, los documentos se inyectan y el modelo los utiliza.
MCP es un protocolo. Opera en la capa de integración, estandarizando cómo los sistemas de IA se conectan a herramientas, fuentes de datos y contexto, independientemente de la estrategia de recuperación que esas conexiones utilicen internamente. Un servidor MCP que expone un almacén de documentos podría utilizar RAG internamente para ofrecer fragmentos relevantes. O podría no hacerlo. Al protocolo le da igual en ambos casos.
MCP funciona como la interfaz mediante la que un sistema de IA accede a recursos externos. RAG es una estrategia para lo que ocurre cuando se accede a una colección de documentos. Los sistemas de IA generativa que necesitan tanto acceso a herramientas estructuradas como recuperación de documentos utilizarán a menudo MCP y RAG juntos: MCP como capa de conexión y RAG como lógica de recuperación dentro de uno o más sistemas conectados.
El asistente conversacional de IA que responde preguntas sobre su base interna de conocimiento es un buen ejemplo de ambos trabajando juntos: MCP gestiona la conexión con el almacén de documentos, RAG gestiona lo que se recupera de él y el modelo razona sobre cualquier contexto que llegue a la ventana.
Confundir ambos enfoques lleva a construir una solución insuficiente. Los equipos que piensan «tenemos RAG, así que no necesitamos MCP» terminan con buena recuperación y conexiones frágiles. Los equipos que piensan «tenemos MCP, así que no necesitamos diseñar una estrategia de recuperación» terminan con interfaces limpias y mala calidad de contexto.
Casos de uso de MCP: dónde lo están desplegando realmente los equipos
Entender qué es MCP en abstracto resulta útil. Entender dónde lo están desplegando realmente los equipos y por qué aporta algo diferente: permite saber si encaja con el problema que usted está analizando ahora mismo.
Hay cuatro patrones de despliegue que veo repetirse en el ecosistema actual, cada uno relacionado directamente con una decisión real de equipo.
Entornos de desarrollo impulsados por IA y agentes de código
El uso de Model Context Protocol en herramientas para desarrolladores es actualmente el caso de uso más visible del ecosistema. Los asistentes de programación con IA como Claude Desktop y Cursor utilizan MCP para conectar modelos con repositorios, documentación, rastreadores de incidencias y el estado de los flujos de CI/CD, todo a la vez y mediante una interfaz coherente.
El efecto práctico: un desarrollador que pregunta a un asistente de IA «¿qué se ha roto en la última compilación y qué cambió en el archivo relevante?» recibe una respuesta basada simultáneamente en el sistema de CI/CD y el historial de versiones, sin que el asistente necesite integraciones separadas codificadas para cada uno. El asistente de programación envía la solicitud a través del cliente MCP, los servidores MCP disponibles responden con datos actuales y el modelo razona sobre ellos.
Los equipos que crean agentes de IA para flujos de desarrollo utilizan cada vez más MCP como capa de conectividad precisamente porque la superficie de herramientas en un entorno de desarrollo es amplia —acceso a repositorios, ejecutores de pruebas, sistemas de documentación, rastreadores de incidencias— y el problema M×N se acumula rápidamente. MCP crea una base estable bajo esa complejidad, de modo que la lógica del agente se mantiene limpia incluso cuando crecen los sistemas conectados.
Agentes de IA empresariales conectados a CRM, ERP y sistemas de negocio
Para los equipos empresariales que crean agentes de IA que necesitan interactuar con sistemas operativos —CRM, ERP, plataformas de RR. HH., herramientas de analítica—, la integración MCP cambia significativamente el patrón de desarrollo. En lugar de crear un conector a medida por sistema y por agente, el equipo crea una vez un servidor MCP delante de cada sistema. Cada agente de IA que necesita acceder a ese sistema se conecta mediante el mismo servidor.
El valor empresarial está en ese «una vez». Habilite a los agentes de IA para acceder a Salesforce mediante un servidor MCP y todos los agentes posteriores que necesiten datos de Salesforce utilizarán la misma conexión. Conecte sistemas de IA a SAP mediante un servidor MCP y el trabajo de integración queda hecho a nivel de protocolo, no por separado para cada nueva aplicación de IA.
He visto equipos de operaciones describir esto como conseguir por primera vez una capa de integración compartida: algo que no podían justificar crear como infraestructura personalizada, pero que el patrón MCP hace viable porque el trabajo se acumula en la dirección correcta: cada servidor creado se reutiliza, no se vuelve a crear.
Flujos de datos y analítica con acceso gobernado a servidores MCP
El caso de uso de asistentes de analítica es donde las implicaciones de control de acceso de MCP se hacen más visibles. Un equipo quiere permitir que un LLM consulte un almacén de datos o una plataforma de analítica, pero no quiere acceso sin restricciones ni que el modelo explore libremente datos sensibles.
Un servidor MCP delante de la fuente de datos define exactamente qué contexto se expone. El servidor controla qué consultas pueden ejecutarse, qué tablas son accesibles y qué formato de respuesta recibe el modelo. El flujo se conecta a esa superficie definida, no directamente al almacén de datos subyacente.
El control de acceso se sitúa en la capa del servidor MCP. Es una decisión de diseño, no una función de producto que se obtiene automáticamente, y volveré a este punto en la sección sobre el ecosistema. Sin embargo, la arquitectura hace viable el acceso gobernado a datos de una manera que las conexiones directas entre LLM y bases de datos no permiten.
MCP Server Builder de Latenode es la parte de la plataforma que recomiendo a los equipos cuando surge esta necesidad: permite crear un servidor MCP controlado que define lo que el modelo puede ver, sin requerir infraestructura personalizada. El enfoque de interfaz de herramientas limpia primero —definir con qué puede interactuar el agente antes de conectarlo a cualquier sistema activo— es el error de configuración que la mayoría de los equipos omite, y es el que genera el ticket de soporte tres semanas después.
No es una situación hipotética. Es donde suele empezar el ticket.
El ecosistema MCP: adopción, frameworks y lo que aún falta
El impulso del ecosistema detrás de MCP es la parte que modifica el cálculo de riesgo para los equipos que consideran adoptarlo. OpenAI y Google DeepMind han adoptado el protocolo junto con Anthropic, lo que significa que MCP ya no es un estándar de un único proveedor: se está convirtiendo en infraestructura fundamental para el desarrollo de IA agéntica en los principales laboratorios.
Frameworks de IA como LangChain, LangGraph y LlamaIndex interoperan con servidores MCP, lo que significa que la cadena de herramientas para crear sistemas agénticos converge cada vez más en MCP como capa de conexión. Los servidores MCP prediseñados para sistemas comunes —GitHub, Slack, bases de datos y sistemas de archivos— se acumulan en repositorios públicos, reduciendo el coste de desarrollo de integraciones habituales.
Dicho esto, el ecosistema tiene carencias reales que el entusiasmo por la adopción tiende a ocultar. Entenderlas antes de comprometerse vale los cinco minutos que lleva.
Principales adoptantes y por qué el impulso del ecosistema importa para la IA agéntica
Cuando la adopción de un nuevo protocolo se limita a su creador, los equipos afrontan un riesgo real de infraestructura: ¿qué sucede si el creador cambia de rumbo, el estándar se bifurca o la comunidad no se materializa? Ese riesgo es menor con MCP de lo que era hace doce meses.
La adopción de MCP por OpenAI y Google DeepMind indica que el estándar ha superado un umbral importante: ya no es solo el protocolo de Anthropic. Cuando varios laboratorios de IA se comprometen con una interfaz compartida, la inversión del ecosistema que la respalda —herramientas, documentación, servidores prediseñados y soporte de frameworks— crece de formas que benefician a todos quienes desarrollan sobre el estándar.
Para los equipos que crean sistemas de IA agéntica, esto importa en la práctica: MCP ayuda a los agentes de IA a conectarse con herramientas y datos de una forma que no está vinculada a un único proveedor de modelos. Un agente creado hoy con Claude puede acceder a los mismos servidores MCP que un agente creado mañana con GPT. Hacer que los flujos de IA sean portables entre modelos se está convirtiendo en un objetivo de ingeniería real a medida que cambian las preferencias de modelos, y MCP contribuye a ese objetivo más que cualquier enfoque de un único proveedor. Múltiples agentes de IA dentro de la misma organización pueden compartir infraestructura de servidores MCP, lo que acumula la inversión de desarrollo en lugar de multiplicarla.
Lo que MCP aún no gestiona: estrategia de recuperación y controles de acceso
Aquí está lo que las explicaciones bienintencionadas sobre MCP suelen minimizar: el protocolo estandariza la interfaz. No diseña lo que hay detrás.
MCP no toma decisiones de estrategia de recuperación por usted. Si su servidor MCP expone una base de conocimiento documental, alguien todavía debe decidir cómo se organiza esa base de conocimiento, qué estrategia de fragmentación utiliza, cómo se mantiene la actualización y cuándo se retiran los datos obsoletos. Las interacciones MCP siguen un protocolo definido. La calidad del contexto que devuelven esas interacciones depende por completo del trabajo de diseño que haya realizado en el lado del servidor.
Los controles de acceso son la misma historia. Un servidor MCP es un posible punto de exposición de datos. Qué datos expone, a qué clientes, bajo qué condiciones y con qué registro de auditoría es una cuestión de diseño de sistemas de IA que MCP no responde. El sistema externo subyacente puede tener sus propios controles de acceso. La capa de servidor MCP puede añadir más. Pero «tengo un servidor MCP» no equivale a «tengo una capa de acceso a datos gobernada». El trabajo de gobernanza aún debe realizarse.
Un asistente de IA conectado a un servidor MCP que expone un amplio almacén de datos internos sin restricciones de acceso cuidadosamente diseñadas es una superficie de seguridad, no solo una superficie de integración. Vale la pena decirlo claramente antes de la decisión de desarrollo, no después de la respuesta a un incidente.
🤔 La pregunta incómoda:
Los equipos adoptan MCP para reducir la complejidad de integración. Eso es real. Pero cada servidor MCP que conecta es una nueva superficie de exposición de datos que ahora se resuelve mediante solicitudes de protocolo en vez de integraciones revisadas manualmente. La superficie total de gobernanza crece en proporción directa al número de servidores que conecta, y el protocolo no se audita a sí mismo. Tener conexiones más simples no significa tomar menos decisiones de seguridad. Significa que esas decisiones deben ocurrir en algún lugar de forma más deliberada que en el código de integración que sustituyeron.
