Protocolo de Contexto de Modelos (MCP): conectar la IA a las herramientas de negocio

¿Qué es el Model Context Protocol (MCP)?

El Model Context Protocol (MCP) es un estándar abierto y de código abierto, presentado por Anthropic en noviembre de 2024. Normaliza la forma en que las aplicaciones de IA, en particular los grandes modelos de lenguaje (LLM), se conectan a herramientas, sistemas y fuentes de datos externos [11].

Una capa de estandarización entre la IA y los servicios

IBM describe el MCP como una capa de estandarización. Permite que las aplicaciones de IA se comuniquen con servicios externos: herramientas, bases de datos, modelos predefinidos [12]. El MCP no es un modelo de IA ni un software de negocio. Es un protocolo, es decir, una convención de intercambio común entre el asistente y los sistemas que debe utilizar.

Mendix, editor de una plataforma de desarrollo, lo define de forma similar: un protocolo de código abierto que permite a las aplicaciones de IA conectarse a fuentes de datos y herramientas externas, con la promesa de seguridad [19]. Esta promesa la avanza el editor. Supone una verificación en cada despliegue.

La imagen del USB-C

Para ilustrar este papel, varios actores comerciales recurren a la comparación con el USB-C.

• Red Hat presenta el MCP como un protocolo único y estandarizado para conectar una aplicación de IA a un sistema externo, y lo compara con un cable USB-C que conecta un dispositivo a distintos accesorios [1].
• NextStart.AI habla del «puerto USB-C de la IA empresarial» [30].

La analogía se apoya en la situación anterior. Antes del MCP, cada editor debía desarrollar su propio conector para cada modelo, y cada empresa debía mantener esas integraciones con cada actualización [30]. Con un puerto común, una misma herramienta puede, en principio, conectarse a distintos asistentes sin desarrollo específico.

La imagen tiene sus límites: el USB-C es una norma de hardware, mientras que el MCP es un protocolo de software. Las secciones siguientes detallan su funcionamiento, sus diferencias con una API clásica y las precauciones que hay que tomar para un despliegue en empresa.

¿Qué problema resuelve el MCP para una empresa?

El MCP resuelve, ante todo, un problema de integración: conectar un modelo de IA con las herramientas de una empresa exigía tantos conectores a medida como combinaciones modelo/herramienta existieran. Antes del protocolo, cada editor debía desarrollar su propio conector para cada modelo, y cada empresa debía mantener esas integraciones con cada actualización [30].

La «fontanería» que se multiplica

La dificultad no residía tanto en la capacidad de razonamiento de los modelos como en la fontanería necesaria para conectarlos al sistema de información. Esta fontanería se multiplicaba con cada nueva combinación asistente/herramienta [21]. Hasta entonces, muchos proyectos de IA se basaban en integraciones hechas a mano para cada pareja modelo + herramienta [27]. El cálculo es sencillo: diez herramientas y tres asistentes representan potencialmente treinta integraciones distintas, que hay que desarrollar y luego mantener. El MCP responde a este obstáculo de interoperabilidad proponiendo un protocolo universal [10].

Modelos que solo conocen su entrenamiento

El segundo problema está en los propios modelos. Un gran modelo de lenguaje (LLM) generalmente solo conoce los datos con los que fue entrenado, y esos datos pueden quedar obsoletos rápidamente [8]. Para un uso profesional, esto es un límite directo: un modelo por sí solo no sabe nada del estado de un expediente de cliente, de un stock o de un ticket abierto esta mañana.

El MCP aborda este límite dando a los modelos un acceso estructurado y evolutivo a los datos y herramientas que necesitan. El contexto, procedente de los sistemas empresariales, pasa a ser en tiempo real y verificable [18]. Así, las respuestas de la IA se apoyan en el estado actual de los sistemas, y no solo en lo que el modelo aprendió.

Qué cambia para una DSI

El protocolo no hace a los modelos más «inteligentes». Desplaza el esfuerzo: en lugar de reescribir integraciones, los equipos técnicos se apoyan en una interfaz compartida entre la IA y las herramientas.

¿Cómo funciona el MCP en la práctica?

El MCP se basa en una arquitectura cliente-servidor. El cliente MCP emite solicitudes estandarizadas, y los servidores MCP exponen los recursos de la empresa (bases de datos, API, herramientas) a través de una interfaz unificada [17].

Mensajes, roles y autenticación

Los intercambios son bidireccionales [8][17] y se realizan mediante mensajes JSON [17]. La arquitectura se apoya en JSON-RPC 2.0 y separa claramente tres roles: el host, el cliente y el servidor [27]. La terminología varía según las fuentes. [17] designa simplemente como «cliente» al modelo de IA, mientras que [27] distingue el host del cliente. En cuanto a la autenticación, [17] indica que el protocolo recurre a OAuth2. Este punto procede de una única fuente del expediente, y hay que confirmarlo en la especificación oficial antes de fijar una arquitectura.

Descubrimiento dinámico de herramientas

El modelo descubre por sí mismo las herramientas disponibles, sin una lista codificada de antemano [17][26]. Este descubrimiento se produce en ejecución: una herramienta añadida a un servidor se vuelve accesible de inmediato para los modelos conectados [35]. Desde la perspectiva de la DSI, enriquecer un servidor basta para ampliar las capacidades del asistente, sin tocar cada aplicación cliente.

Flujos de trabajo de varios pasos

Esta arquitectura permite ejecutar flujos de trabajo con estado y de varios pasos, en lugar de interacciones aisladas de solicitud-respuesta [9]. Así, la IA puede acceder a los datos adecuados, en el momento oportuno, e interactuar con los sistemas de negocio como lo haría un colaborador [26].

Una especificación en evolución

Una fuente menciona una versión de la especificación fechada el 28 de julio de 2026, que introduciría un núcleo «stateless» y mejoras de autorización [13]. Este punto parece matizar la noción de flujos de trabajo con estado descrita antes [9]. El expediente no contiene la especificación oficial, y [13] es un contenido divulgativo. No zanjamos el asunto: antes de cualquier desarrollo, verifique la versión vigente en la documentación del protocolo.

¿En qué se diferencia el MCP de una API o de un conector clásico?

Una API expone una función precisa de una herramienta, mientras que el MCP estandariza el diálogo entre una IA y esa herramienta [23]. Ambos no se sitúan al mismo nivel: la API describe lo que un software sabe hacer, el protocolo describe cómo un modelo de IA accede a ello.

Lo que cambia el MCP respecto a un conector clásico

Un conector clásico se escribe para un par concreto, un modelo y una herramienta. Antes del MCP, cada editor debía desarrollar su propio conector para cada modelo, y cada empresa debía mantener esas integraciones con cada actualización [30]. El MCP desplaza este trabajo en tres puntos:

• Normalización del acceso: el protocolo uniformiza la forma en que un modelo accede a las herramientas y a los datos [5].
• Separación de responsabilidades: la lógica de negocio, el modelo y la infraestructura siguen siendo distintos [5].
• Reutilización: un único servidor MCP por herramienta puede servir a todas las aplicaciones de IA de la empresa [15].

Según una fuente editorial, un asistente puede entonces leer y escribir en el CRM, el ERP, la mensajería o la agenda sin integración específica [29]. Esta promesa la formula un actor comercial y debe validarse en cada despliegue.

Una capa que complementa las API

El MCP no reemplaza las API. En la arquitectura descrita, los servidores MCP exponen recursos (bases de datos, API, herramientas) a través de una interfaz unificada [17]. La API sigue siendo, por tanto, el medio de acceso a la aplicación, y el servidor MCP la hace explotable por un modelo de forma estándar. Para un uso sin IA (intercambios entre sistemas, procesamientos por lotes), nada en el expediente justifica pasar por el MCP.

Una cuestión de método

Las formulaciones más categóricas de esta comparación proceden de fuentes editoriales o comerciales: [23] para la distinción entre API y MCP, [15] para la reutilización de un servidor por todas las aplicaciones de IA. La descripción de la separación entre lógica de negocio, modelo e infraestructura [5] procede de un editor de software. Estas fuentes describen la intención del protocolo. La ganancia real depende del número de herramientas y asistentes que haya que conectar, y la DSI debe medirla en su propio ámbito.

¿Qué herramientas y casos de uso se pueden conectar mediante MCP?

El Model Context Protocol apunta, en primer lugar, a las herramientas empresariales: CRM, Slack, Google Drive y bases de datos [3]. Concretamente, un asistente de IA puede leer y escribir en estas herramientas, incluidos el ERP, la mensajería y la agenda, sin integración específica [29]. Esta capacidad de escritura, que permite actuar y no solo consultar, exige precauciones en materia de derechos de acceso, tratadas más adelante en este artículo.

Las categorías de herramientas afectadas

Caso de uso: una administración local

En un asistente documental de administración o de entidad local, el MCP puede conectar un agente conversacional a varias fuentes internas [33]. La fuente cita cuatro tipos:

• los directorios de archivos;
• las bases documentales;
• las herramientas de gestión de tickets;
• las bases de conocimiento [33].

El agente consulta así estos recursos desde una única interfaz conversacional, en lugar de que cada uno exija su propio desarrollo. El texto, publicado por la Banque des Territoires, presenta el protocolo como una pieza de la arquitectura de IA empresarial, y no como un simple detalle técnico [33].

Caso de uso: la industria

En la fabricación, el MCP proporciona a los modelos de lenguaje el contexto que necesitan a partir de las herramientas y sistemas que los fabricantes ya utilizan [6]. El modelo no necesita, pues, apoyarse en un conjunto de datos separado: trabaja con los sistemas que hacen funcionar el taller. Esta fuente procede de un actor comercial, y sus formulaciones describen un potencial, no un resultado medido.

Lo que hay que retener para el planteamiento

Ambos casos parten del mismo principio: la IA se conecta a sistemas existentes en lugar de sustituirlos. Para una DSI, la pregunta de partida no es tanto «¿qué modelo elegir?» como «¿qué fuentes internas exponer, con qué derechos de lectura y de escritura?».

¿Es el MCP un estándar realmente adoptado?

El MCP se presenta como adoptado por los principales proveedores de IA, pero el expediente no contiene ninguna fuente primaria (comunicado de un editor o especificación oficial). Los hechos que siguen proceden de fuentes secundarias, a menudo comerciales, y algunos deben confirmarse.

Lo que coinciden las fuentes

• Origen: el MCP es un estándar abierto presentado por Anthropic en noviembre de 2024 [11].
• OpenAI: la adopción se remonta a marzo de 2025 [29].
• Google y Microsoft: una agencia de consultoría indica que el MCP fue adoptado por OpenAI, Google y Microsoft en 2025 [16]. El expediente no proporciona una fecha precisa para Google ni para Microsoft.
• Ecosistema: el proyecto publica servidores de referencia (sistemas de archivos, bases PostgreSQL, búsqueda web) y un registro oficial recoge los servidores disponibles. Directorios comunitarios enumeran miles de otros, desde el conector de base de datos hasta las herramientas de negocio de nicho [31]. Esta descripción procede de una guía práctica redactada por una agencia, sin recuento preciso.

Lo que hay que verificar

Sobre la especificación, la fuente solo indica estas dos evoluciones [13]. Si se confirman, afectarán a la gestión del estado y a la autorización, dos puntos que deben examinarse antes de cualquier despliegue. Por tanto, hay que leer la versión vigente en la especificación oficial antes de fijar una arquitectura.

En cuanto a la previsión de Gartner, la cadena de transmisión cuenta con dos intermediarios. Además, se refiere a los agentes de IA y no al MCP en sí: es Divalto quien afirma que el MCP es el protocolo en el que se apoyan estos agentes para acceder a los datos [32]. Ofrece un orden de magnitud, no una medición de la adopción del protocolo.

En la práctica, la adopción por parte de los grandes proveedores y el tamaño del ecosistema están bien documentados. Las versiones precisas de la especificación y las cifras de mercado deben verificarse con las fuentes primarias.

¿Es seguro el MCP? ¿Qué precauciones debe tomar la DSI?

El MCP se presenta como un medio seguro para conectar la IA a los sistemas empresariales, pero las fuentes disponibles describen esta promesa sin demostrarla. La seguridad de un despliegue depende, por tanto, de su propio análisis de riesgos.

Lo que dicen las fuentes

Varias fuentes asocian el MCP a una conexión segura. Proofpoint lo describe como un estándar abierto que permite a los modelos conectarse «de forma segura» a fuentes de datos y sistemas externos [2]. Mendix habla de conexión «de manera segura» [19]. Digitalkin lo califica de estándar «fiable, portátil y trazable» [34]. Kiteworks, editor especializado en seguridad, hace de la seguridad de la IA un eje central del protocolo [7].

Estas afirmaciones son mayoritariamente editoriales. Proceden de actores comerciales, algunos de los cuales venden productos de seguridad o de desarrollo. Deben leerse como posicionamientos, no como resultados de auditoría.

Lo que el expediente no permite afirmar

El expediente no detalla ningún riesgo concreto del MCP, no cuantifica ninguna vulnerabilidad y no documenta ningún incidente. Por tanto, no se puede concluir que el protocolo sea seguro por construcción, ni elaborar un inventario de sus fallos. Una fuente describe intercambios mediante mensajes JSON con autenticación OAuth2 [17]. Otra menciona «mejoras de autorización» en una versión de la especificación fechada el 2026-07-28 [13]. Esta fecha resulta sorprendente y debe verificarse en la especificación oficial antes de tomar cualquier decisión.

Tres puntos que instruir antes de cada despliegue

La DSI puede enmarcar el análisis en torno a tres ejes:

• Autenticación: cómo se identifican el cliente MCP y cada servidor, y cómo se conceden y revocan los accesos.
• Alcance de los derechos: qué puede leer el asistente y, sobre todo, qué puede escribir en cada herramienta. Las fuentes indican que un asistente puede actuar en herramientas de negocio como un CRM o un ERP [29], lo que hace de este alcance un factor determinante.
• Trazabilidad: la capacidad de reconstruir qué acciones se han desencadenado, por quién y con qué datos. La mención de trazabilidad debe verificarse en el despliegue real [34].

Este análisis debe aplicarse a cada servidor MCP seleccionado, ya provenga de un editor, de un directorio comunitario o de un desarrollo interno.

¿Cómo poner en marcha el MCP y dónde se sitúa Oupi?

Una empresa dispone de tres vías para poner en marcha el MCP: reutilizar servidores existentes, desarrollar sus propios servidores o recurrir a una agencia o a una formación. Estas vías pueden combinarse.

1. Utilizar servidores existentes. El proyecto MCP publica servidores de referencia (sistemas de archivos, bases PostgreSQL, búsqueda web). Un registro oficial recoge los servidores disponibles, y directorios comunitarios enumeran miles de otros, desde el conector de base de datos hasta el manejo de herramientas de negocio de nicho [31]. Es el punto de partida más rápido para las herramientas habituales. El expediente no precisa cómo se verifican los directorios comunitarios: antes de cualquier uso, se impone una revisión técnica y de seguridad.

2. Desarrollar servidores propios. Los sistemas específicos de la empresa (ERP a medida, intranet, base de tarifas) corresponden a servidores propios [31]. Este desarrollo corre a cargo del equipo interno, que expone sus propios datos y funciones a través del protocolo.

3. Recurrir a una agencia o a una formación. Algunas agencias proponen desarrollar servidores MCP a medida e integrarlos en los flujos de trabajo existentes [24]. En cuanto a la formación, un organismo ofrece aprender a diseñar arquitecturas componibles basadas en servidores MCP y a conectar LLM con herramientas y datos expuestos mediante el protocolo [25]. Otro propone una formación intra o inter-empresas, en Francia o a distancia, desde 1 700 € sin IVA y elegible para los OPCO [4]. Estas ofertas proceden de actores comerciales: los contenidos y las tarifas son los del prestador.

En la práctica, se puede empezar por los servidores existentes para las herramientas estándar. El desarrollo específico se reserva para los sistemas internos, y la competencia se construye en paralelo.

Dónde se sitúa Oupi

Oupi es una plataforma de IA diseñada, desarrollada y alojada en Francia. Se conecta a cientos de aplicaciones externas mediante MCP y conectores.