Qué es MCP (Model Context Protocol) y MCP vs API: en qué se diferencian
Tabla de contenido
Cada vez que una empresa quiere que un asistente de IA consulte su CRM, lea documentos internos o ejecute una tarea en un sistema, aparece el mismo problema: hay que construir una integración a la medida para cada herramienta y para cada aplicación de IA. El Model Context Protocol (MCP) nació para resolver ese problema con un estándar común.
En este artículo explicamos qué es MCP, cómo funciona por dentro, cuál es la diferencia entre MCP y API, qué cuidados de seguridad exige y en qué casos conviene usarlo en una empresa.
Qué es MCP: el Model Context Protocol explicado
MCP es un estándar abierto para conectar aplicaciones de IA con sistemas externos como bases de datos, archivos, buscadores o flujos de trabajo. Anthropic lo presentó en diciembre de 2024 y hoy lo soportan asistentes como Claude y ChatGPT, además de herramientas de desarrollo como Visual Studio Code y Cursor.
La documentación oficial lo compara con un puerto USB-C: así como USB-C ofrece una forma estándar de conectar dispositivos electrónicos, MCP ofrece una forma estándar de conectar aplicaciones de IA con sistemas externos.
Gracias a ese estándar, un asistente puede acceder a información y ejecutar acciones en otras herramientas sin que cada integración se programe desde cero. Un mismo servidor MCP para el ERP, por ejemplo, puede ser usado por el asistente de ventas, por un agente de operaciones y por la herramienta interna de análisis.
Por qué surgió MCP: el problema de las integraciones duplicadas
Antes de MCP, cada proveedor de IA definía su propia forma de conectar herramientas. Si una empresa quería que tres aplicaciones de IA usaran su sistema de tickets, tenía que construir y mantener tres integraciones diferentes.
MCP convierte ese problema en uno más simple. Cada sistema se expone una sola vez como servidor MCP, y cada aplicación de IA implementa una sola vez el cliente MCP. A partir de ahí, cualquier cliente compatible puede hablar con cualquier servidor compatible. El esfuerzo deja de multiplicarse con cada nueva combinación.
Cómo funciona MCP: arquitectura host, cliente y servidor
Los tres participantes
MCP usa una arquitectura cliente-servidor con tres participantes. El host es la aplicación de IA que coordina todo, por ejemplo Claude Desktop o Visual Studio Code. El cliente es el componente que el host crea para mantener una conexión dedicada con un servidor. El servidor es el programa que ofrece contexto y capacidades.
Un host puede conectarse a varios servidores al mismo tiempo, y crea un cliente por cada uno. Un servidor puede ejecutarse localmente o de forma remota.
Herramientas, recursos y prompts
Un servidor MCP puede exponer tres tipos de elementos, llamados primitivas:
- Herramientas (tools): funciones que la IA puede ejecutar, como consultar una base de datos, crear un ticket o llamar a una API.
- Recursos (resources): datos de contexto, como el contenido de un archivo, el esquema de una base de datos o un registro de cliente.
- Prompts: plantillas reutilizables que guían la interacción con el modelo, por ejemplo instrucciones con ejemplos para usar bien las herramientas.
El cliente también puede ofrecer capacidades al servidor. La más relevante para empresas es la elicitación, que permite al servidor pedir información adicional o una confirmación al usuario antes de continuar.
Capas y transportes: JSON-RPC, STDIO y HTTP
MCP tiene dos capas. La capa de datos define los mensajes, basados en JSON-RPC 2.0, y las primitivas. La capa de transporte define cómo viajan esos mensajes. Para servidores locales se usa STDIO, la entrada y salida estándar del proceso, sin pasar por la red. Para servidores remotos se usa Streamable HTTP, que admite autenticación estándar y para la cual la especificación recomienda OAuth.
Cómo fluye una solicitud en MCP, paso a paso
Para entender MCP en la práctica, conviene seguir una solicitud real. Supongamos que un analista le pide al asistente corporativo: "¿cuántos reclamos abiertos tiene el cliente X?".
- Descubrimiento: el cliente MCP consulta al servidor qué versión del protocolo y qué capacidades soporta.
- Listado de herramientas: el cliente pide la lista de herramientas disponibles. Cada una llega con nombre, descripción y un esquema de parámetros.
- Decisión del modelo: el host entrega esa lista al modelo, que decide usar la herramienta de búsqueda de reclamos con el identificador del cliente.
- Ejecución: el cliente envía la llamada al servidor, que consulta el sistema de reclamos a través de su API interna.
- Respuesta: el servidor devuelve el resultado y el modelo redacta la respuesta para el analista.
- Actualizaciones: si el servidor agrega o cambia herramientas, puede notificar al cliente para que actualice su lista.
MCP vs API: cuál es la diferencia
MCP no reemplaza a las API. Normalmente un servidor MCP se apoya en las API de un sistema y las presenta de una forma que cualquier aplicación de IA compatible puede descubrir y usar.
| Aspecto | API tradicional | MCP |
|---|---|---|
| Propósito | Exponer las funciones de un servicio a desarrolladores | Dar a las aplicaciones de IA un modo estándar de usar herramientas y datos |
| Integración | Una integración a la medida por cada aplicación y servicio | Un servidor reutilizable para cualquier cliente compatible |
| Descubrimiento | El desarrollador lee la documentación y programa las llamadas | El cliente consulta al servidor qué herramientas y recursos ofrece |
| Descripción | Pensada para personas que programan | Pensada para que un modelo entienda cuándo y cómo usar cada herramienta |
| Cambios | Cada consumidor debe actualizar su código | El servidor puede notificar a los clientes que su lista cambió |
MCP, function calling y plugins
Es común confundir MCP con el function calling de los modelos. El function calling es la capacidad del modelo de decidir que necesita una herramienta y generar los parámetros para usarla. MCP es el estándar que define cómo la aplicación encuentra esas herramientas y cómo se comunica con el sistema que las ejecuta. Son complementarios: el modelo decide, MCP conecta.
Los plugins propietarios resolvían algo parecido, pero cada uno funcionaba solo dentro de una plataforma. La ventaja de MCP es que un servidor construido una vez sirve para varios hosts y proveedores de IA, lo que reduce la dependencia de un solo proveedor.
Casos de uso de MCP para integrar IA en la empresa
Usar MCP para integrar IA con los sistemas de la empresa tiene más sentido donde varios asistentes o agentes necesitan los mismos datos. Algunos ejemplos:
- Banca: asistentes que consultan productos, movimientos y políticas internas a través de servidores con permisos controlados y trazabilidad completa.
- Seguros: agentes que revisan pólizas, el estado de siniestros y la documentación del cliente sin duplicar integraciones con el sistema central.
- Herramientas internas: acceso a la intranet, al sistema de tickets o al repositorio de documentos desde el asistente que ya usan los empleados.
- Desarrollo de software: asistentes de código que leen el repositorio, los tickets y los registros de errores para proponer correcciones.
Si quieres ver cómo se aplica en un caso real, descarga nuestro caso de estudio sobre arquitectura MCP en el sector bancario.
Seguridad en MCP: lo que hay que cuidar
Un servidor MCP le da a la IA acceso a datos y acciones reales, así que debe tratarse como cualquier integración crítica. La documentación oficial dedica una guía completa a las buenas prácticas de seguridad. Los puntos clave son:
- Autenticación y autorización: usar OAuth en servidores remotos y validar que cada token fue emitido para ese servidor. La especificación prohíbe reenviar tokens de otros servicios.
- Permisos mínimos: empezar con alcances de solo lectura y pedir permisos adicionales únicamente cuando una operación los necesite.
- Inyección de instrucciones: un documento o una respuesta externa puede intentar manipular al modelo para que use una herramienta indebida. Por eso conviene validar entradas y pedir aprobación humana en acciones sensibles.
- Servidores locales: ejecutarlos con privilegios restringidos y aislados, y revisar el comando exacto antes de instalarlos.
- Registro y auditoría: guardar qué herramienta se usó, con qué parámetros y para qué usuario.
Cuándo no conviene usar MCP
MCP no es obligatorio en todos los casos. Si solo existe una integración puntual y estable, entre una aplicación y un sistema, una API directa puede ser más simple de construir y de mantener.
También hay que considerar la madurez interna. Si la empresa todavía no tiene APIs ordenadas, un inventario de datos ni un modelo de permisos claro, el primer paso es ese trabajo de base. MCP ordena el acceso de la IA, pero no reemplaza una arquitectura de integración bien diseñada.
En resumen, MCP es un estándar abierto que conecta aplicaciones de IA con herramientas y datos de forma uniforme. No sustituye a las API: las aprovecha y las vuelve reutilizables para agentes de IA, con descubrimiento automático de capacidades y un modelo de seguridad propio. En Rootstack ayudamos a las empresas a diseñar integraciones con MCP seguras y alineadas con su arquitectura.
Preguntas frecuentes
¿MCP reemplaza a las API?
No. Los servidores MCP suelen apoyarse en las API existentes y las exponen en un formato estándar que las aplicaciones de IA pueden descubrir y usar.
¿Qué puede hacer un servidor MCP?
Puede ofrecer herramientas que ejecutan acciones, recursos con datos de contexto y prompts con plantillas reutilizables para guiar al modelo.
¿Es seguro usar MCP en una empresa?
Depende de la implementación. Conviene aplicar OAuth, permisos mínimos, validación de entradas, registro de acciones y aprobación humana en las tareas sensibles.
¿Necesito cambiar de proveedor de IA para usar MCP?
No. MCP es soportado por varios asistentes y herramientas, así que un mismo servidor puede funcionar con distintos proveedores de IA.
Blogs relacionados
RAG vs. fine-tuning para agentes de IA empresariales
Gobernanza de IA: RBAC, auditoría y supervisión en agentes
