Los asistentes de inteligencia artificial pueden redactar textos, resumir documentos y responder preguntas generales. Sin embargo, su utilidad dentro de una empresa es limitada cuando no pueden acceder a la información ni a las aplicaciones que forman parte del trabajo diario.
Un asistente aislado no conoce el estado actual de los pedidos, las oportunidades abiertas en el CRM, el inventario disponible o las incidencias registradas por el equipo de soporte.
Para consultar estos datos y ejecutar acciones necesita conectarse con sistemas externos.
Model Context Protocol, conocido como MCP, propone una forma estandarizada de realizar estas conexiones. El protocolo permite que aplicaciones de inteligencia artificial accedan a fuentes de información, herramientas y procesos mediante una interfaz común. La documentación oficial lo presenta como un estándar abierto para conectar aplicaciones de IA con sistemas externos.
Una empresa podría utilizar MCP para que un asistente:
- Consulte clientes en un CRM.
- Busque documentos internos.
- Revise el inventario.
- Cree una incidencia.
- Prepare un informe.
- Actualice una oportunidad comercial.
- Consulte información de una aplicación propia.
La ventaja principal es que no resulta necesario diseñar una conexión completamente distinta para cada combinación de modelo y herramienta.
Sin embargo, MCP no convierte cualquier asistente en un empleado autónomo ni elimina la necesidad de crear APIs, permisos y reglas. El protocolo organiza la comunicación, pero la empresa sigue siendo responsable de decidir qué información puede consultarse, qué acciones están permitidas y cuándo debe intervenir una persona.
Qué es Model Context Protocol
Model Context Protocol es un protocolo abierto que estandariza cómo una aplicación de inteligencia artificial puede descubrir y utilizar información o herramientas externas.
Puede compararse con un conector común.
Antes de los protocolos estandarizados, una empresa que quería conectar varios asistentes con diferentes sistemas tenía que desarrollar numerosas integraciones específicas.
Una conexión podía unir un modelo con el CRM. Otra conectaba un asistente diferente con el gestor documental. Una tercera permitía consultar el ERP.
Cada combinación podía utilizar formatos, autenticación y mecanismos distintos.
MCP proporciona un lenguaje compartido para describir las capacidades disponibles y permitir que una aplicación de IA las utilice. Anthropic compara este enfoque con un puerto USB-C para aplicaciones de inteligencia artificial: una interfaz común que facilita la conexión con diferentes datos y herramientas.
El protocolo no sustituye a los programas empresariales.
Actúa como una capa que permite que un cliente compatible se comunique con ellos de una manera más uniforme.
Qué componentes intervienen
Una integración MCP suele incluir tres elementos principales.
Aplicación anfitriona
Es el entorno desde el que el usuario interactúa con la inteligencia artificial.
Puede ser:
- Un asistente empresarial.
- Una aplicación de escritorio.
- Una herramienta para programadores.
- Un chat incorporado a una web.
- Una aplicación interna.
La aplicación decide cuándo puede resultar útil consultar una herramienta externa.
Cliente MCP
El cliente forma parte de la aplicación anfitriona y gestiona la comunicación con uno o varios servidores MCP.
Se encarga de descubrir las capacidades disponibles, enviar solicitudes y devolver los resultados al modelo.
Servidor MCP
El servidor MCP expone información y operaciones de un sistema concreto.
Puede conectarse con:
- CRM.
- ERP.
- Base de datos.
- Ecommerce.
- Gestor documental.
- Aplicación de soporte.
- Calendario.
- Software propio.
El servidor funciona como una capa de traducción. Recibe una petición mediante MCP, consulta la aplicación correspondiente y devuelve una respuesta estructurada.
OpenAI permite conectar sus modelos con servidores MCP remotos para proporcionar nuevas capacidades y acceder a servicios externos desde sus herramientas y APIs.
Qué puede exponer un servidor MCP
El protocolo puede ofrecer diferentes tipos de capacidades.
La implementación concreta depende de la versión utilizada y de las necesidades de la aplicación.
Herramientas
Las herramientas permiten ejecutar acciones.
Por ejemplo:
- Buscar un cliente.
- Crear un ticket.
- Consultar stock.
- Actualizar una oportunidad.
- Generar un documento.
- Programar una cita.
- Enviar información a otra aplicación.
Cada herramienta debe describir qué hace, qué datos necesita y qué resultado devuelve.
Recursos
Los recursos proporcionan información que la aplicación puede consultar.
Pueden representar:
- Archivos.
- Documentos.
- Registros.
- Informes.
- Manuales.
- Contenido de una base de conocimientos.
- Información de una aplicación.
Un servidor puede permitir que el asistente busque un documento y después lea su contenido.
Flujos o instrucciones reutilizables
También pueden exponerse estructuras que ayudan a ejecutar tareas concretas de forma coherente.
Por ejemplo, una plantilla para analizar una incidencia o preparar un informe comercial.
La utilidad de esta separación consiste en que el asistente puede descubrir qué capacidades existen sin necesitar que todas estén programadas directamente dentro de su aplicación.
Casos de uso de MCP para empresas
La mejor forma de valorar MCP es analizar procesos empresariales concretos.
Consultar información comercial
Un asistente conectado al CRM puede responder preguntas como:
- ¿Qué oportunidades deben cerrarse este mes?
- ¿Qué clientes no han recibido seguimiento?
- ¿Cuál es el valor del pipeline?
- ¿Qué contactos están asociados a esta empresa?
El sistema consulta datos actuales, en lugar de responder a partir de información general o de un archivo exportado hace semanas.
Preparar reuniones
El asistente puede combinar información procedente del calendario, del CRM y de documentos relacionados.
Antes de una reunión podría presentar:
- Datos del cliente.
- Últimas comunicaciones.
- Proyectos activos.
- Incidencias abiertas.
- Documentos relevantes.
- Próximas acciones.
El usuario evita buscar manualmente en varias herramientas.
Gestionar soporte técnico
Un agente conectado con el sistema de soporte puede:
- Interpretar la consulta del cliente.
- Consultar la base de conocimientos.
- Buscar incidencias similares.
- Crear un ticket.
- Asignar una categoría.
- Proponer una respuesta.
- Escalar el caso cuando sea necesario.
Las acciones sensibles pueden quedar pendientes de aprobación.
Consultar inventario y pedidos
En un ecommerce, el asistente podría comprobar:
- Disponibilidad.
- Variantes.
- Estado de un pedido.
- Información logística.
- Historial de una compra.
- Condiciones de devolución.
La consulta debe respetar los permisos y verificar la identidad del usuario antes de mostrar información privada.
Crear informes internos
Un asistente puede recuperar datos de distintas fuentes y preparar un resumen.
Por ejemplo:
- Ventas del mes.
- Pedidos pendientes.
- Incidencias críticas.
- Campañas activas.
- Proyectos retrasados.
El informe debe indicar la procedencia de los datos y evitar cálculos que no puedan comprobarse.
Diferencias entre MCP y una API convencional
MCP no elimina las APIs.
En muchos casos, el servidor MCP utiliza precisamente una API para comunicarse con la aplicación empresarial.
Una API define cómo otro programa puede consultar o modificar un sistema. MCP añade una capa estandarizada orientada específicamente a aplicaciones de inteligencia artificial.
La diferencia puede entenderse así:
- La API expone las capacidades del software.
- El servidor MCP adapta esas capacidades a un formato común para asistentes y agentes.
Si una empresa ya dispone de buenas APIs, crear un servidor MCP puede resultar más sencillo.
Cuando el sistema no tiene ninguna interfaz, primero puede ser necesario desarrollar una API o una conexión directa con su base de datos.
MCP tampoco sustituye a la lógica empresarial.
Las reglas de precios, permisos, validaciones y estados deberían continuar controladas por las aplicaciones responsables.
Diferencias entre MCP y RAG
MCP y RAG pueden utilizarse juntos, pero resuelven necesidades diferentes.
Retrieval-Augmented Generation permite recuperar información relevante desde una base documental para utilizarla como contexto antes de generar una respuesta.
Suele aplicarse a:
- Manuales.
- Políticas.
- Documentación.
- Preguntas frecuentes.
- Contenidos internos.
MCP tiene un alcance más amplio.
Además de recuperar información, puede permitir que el asistente utilice herramientas y ejecute acciones en sistemas externos. Google Cloud distingue ambos conceptos señalando que RAG se centra principalmente en recuperar contenido para mejorar una respuesta, mientras que MCP estandariza la interacción con datos, servicios y operaciones externas.
Una empresa podría utilizar RAG para responder preguntas sobre su manual interno y MCP para crear posteriormente una tarea dentro de su gestor de proyectos.
Ventajas de utilizar un estándar común
La adopción de un protocolo común puede aportar varios beneficios.
Menos integraciones específicas
La empresa puede desarrollar una capa reutilizable para diferentes clientes compatibles.
Esto no garantiza que todas las aplicaciones funcionen exactamente igual, pero reduce la dependencia de integraciones completamente propietarias.
Separación entre modelo y herramientas
Las capacidades empresariales no tienen que programarse dentro de un único asistente.
Pueden exponerse desde un servidor y utilizarse desde diferentes aplicaciones autorizadas.
Evolución más sencilla
Cuando cambia una herramienta empresarial, puede actualizarse el servidor MCP sin rediseñar necesariamente toda la aplicación de IA.
Mayor control
La empresa decide qué capacidades expone.
Puede proporcionar acceso de lectura a unos usuarios y permitir acciones únicamente a otros.
Datos actualizados
El modelo puede consultar la fuente original en el momento de la petición.
Esto reduce la dependencia de copias, exportaciones y documentos desactualizados.
La seguridad debe formar parte del diseño
Conectar un asistente con sistemas internos amplía sus capacidades, pero también aumenta el riesgo.
Un servidor MCP puede proporcionar acceso a datos y operaciones importantes. Por eso, no debería publicarse como una interfaz abierta sin autenticación ni límites.
La especificación contempla mecanismos de autorización para transportes basados en HTTP, permitiendo que los clientes accedan a servidores restringidos en nombre de usuarios o propietarios de recursos.
Una implementación empresarial debería considerar:
- Autenticación.
- Autorización.
- Permisos por usuario.
- Mínimo privilegio.
- Registro de acciones.
- Cifrado.
- Límites de uso.
- Validación de entradas.
- Separación de entornos.
- Revocación de accesos.
No todos los usuarios deberían descubrir o utilizar las mismas herramientas.
Un empleado de soporte puede consultar pedidos, pero no modificar precios. Un asistente comercial puede crear una oportunidad, pero no eliminar clientes.
Separar lectura y escritura
Una de las decisiones más importantes consiste en diferenciar entre consultar información y modificar sistemas.
Las acciones de lectura pueden incluir:
- Buscar documentos.
- Consultar clientes.
- Revisar stock.
- Obtener un informe.
Las acciones de escritura pueden:
- Crear registros.
- Modificar pedidos.
- Enviar mensajes.
- Cancelar servicios.
- Eliminar información.
- Ejecutar pagos.
Las operaciones de escritura presentan un riesgo mayor.
Conviene introducir:
- Confirmación del usuario.
- Aprobación humana.
- Límites económicos.
- Validación adicional.
- Registro completo.
- Posibilidad de reversión.
OpenAI advierte que un servidor MCP remoto puede permitir que sus sistemas accedan, envíen y reciban información, además de ejecutar acciones en los servicios conectados. Esto hace necesario evaluar cuidadosamente la confianza, los permisos y el tratamiento de los datos.
Protegerse frente a instrucciones maliciosas
Un agente puede recibir mensajes diseñados para manipular su comportamiento.
También puede encontrar instrucciones maliciosas dentro de documentos, páginas o registros consultados.
Por ejemplo, un archivo podría incluir un texto oculto que intente convencer al asistente de enviar información a un tercero.
La aplicación no debería tratar los datos recuperados como instrucciones de confianza.
Conviene aplicar medidas como:
- Separar instrucciones y contenido.
- Limitar las herramientas disponibles.
- Validar los argumentos.
- Confirmar acciones sensibles.
- Restringir los destinos.
- Revisar resultados.
- Registrar llamadas.
- Bloquear combinaciones peligrosas.
El modelo nunca debería decidir por sí solo qué permisos posee. Los permisos deben aplicarse desde el servidor y desde los sistemas empresariales.
No exponer directamente la base de datos
Permitir que un modelo construya cualquier consulta contra una base de datos puede generar riesgos de seguridad, rendimiento e integridad.
Resulta más seguro exponer herramientas específicas.
En lugar de ofrecer una operación genérica como:
“Ejecutar consulta SQL”
Puede ofrecerse:
- Buscar cliente por identificador.
- Consultar pedidos del usuario.
- Obtener ventas por periodo.
- Revisar disponibilidad de producto.
Cada herramienta valida sus parámetros y limita el conjunto de datos accesible.
Esto también facilita la auditoría y reduce la posibilidad de que el asistente interprete mal una petición.
Elegir los primeros procesos
No conviene comenzar conectando todas las aplicaciones de la empresa.
Un proyecto inicial debería centrarse en un proceso concreto y de riesgo controlado.
Los mejores candidatos suelen presentar:
- Muchas consultas repetitivas.
- Información repartida.
- Reglas claras.
- Volumen suficiente.
- Resultado fácil de comprobar.
- Bajo impacto en caso de error.
Por ejemplo, puede empezarse permitiendo que el asistente consulte documentación y estado de tickets.
Después, cuando la empresa comprueba su funcionamiento, puede añadir acciones como crear incidencias o actualizar determinados campos.
Cómo plantear un proyecto MCP
Una implantación puede organizarse en varias fases.
Analizar el proceso
Hay que identificar qué tarea quiere resolver la empresa y qué herramientas intervienen actualmente.
Inventariar datos y acciones
Debe definirse qué información puede consultar el asistente y qué cambios podría realizar.
Revisar las APIs disponibles
Las aplicaciones pueden disponer de APIs preparadas, conectores o limitaciones que afecten al proyecto.
Diseñar las herramientas
Cada herramienta debería tener un objetivo limitado, entradas claras y una respuesta estructurada.
Aplicar permisos
Los accesos deben depender del usuario, del entorno y del nivel de riesgo.
Probar escenarios normales y adversos
No basta con comprobar que las consultas correctas funcionan.
También deben probarse:
- Datos incompletos.
- Peticiones ambiguas.
- Intentos de acceso indebido.
- Servicios caídos.
- Respuestas excesivas.
- Instrucciones maliciosas.
- Acciones duplicadas.
Medir el resultado
La empresa puede analizar:
- Tareas completadas.
- Tiempo ahorrado.
- Errores.
- Acciones rechazadas.
- Solicitudes de aprobación.
- Incidencias.
- Uso por herramienta.
- Satisfacción del equipo.
La evolución del protocolo en 2026
MCP continúa evolucionando rápidamente.
La especificación publicada el 28 de julio de 2026 introdujo una arquitectura central sin estado, mejoras de autorización, enrutamiento mediante cabeceras, resultados almacenables en caché y un marco formal de extensiones. El objetivo de estos cambios es facilitar la fiabilidad, el escalado y el uso empresarial de servidores remotos.
Su hoja de ruta para 2026 también ha priorizado la escalabilidad del transporte, la comunicación entre agentes, la gobernanza y la preparación para entornos empresariales.
Esta evolución implica que las empresas deberían evitar implementaciones rígidas basadas en versiones antiguas.
Conviene utilizar SDK mantenidos, documentar la versión compatible y planificar actualizaciones.
Una capa común para convertir asistentes en herramientas empresariales
MCP permite que una aplicación de inteligencia artificial deje de trabajar de forma aislada y se conecte con datos, herramientas y procesos reales.
Una empresa puede utilizarlo para consultar un CRM, buscar documentos, revisar pedidos, crear incidencias o preparar informes desde una interfaz conversacional.
El protocolo reduce la necesidad de desarrollar una integración completamente distinta para cada asistente, pero no elimina el trabajo técnico.
Siguen siendo necesarios APIs fiables, permisos, autenticación, validaciones, monitorización y reglas empresariales.
La mejor estrategia consiste en comenzar con procesos limitados, priorizar las operaciones de lectura y exigir supervisión en cualquier acción sensible.
En Calltek desarrollamos aplicaciones, APIs e integraciones personalizadas para conectar sistemas empresariales con asistentes de inteligencia artificial. Podemos diseñar servidores MCP adaptados a CRM, ERP, ecommerce y herramientas internas, aplicando permisos y controles que permitan automatizar procesos sin perder el control sobre los datos ni las operaciones.
