Guía MuleSoft MCP: Habilitando a la IA información y acciones en tiempo real

Tiempo estimado de lectura: 22 minutos

¿Qué es MCP (Model Context Protocol)?

En el panorama actual de la Inteligencia Artificial, el acceso estático a datos ya no es suficiente. El verdadero valor reside en la capacidad de los agentes de IA para interactuar con el mundo real con información a día, hora y minuto actual.

Aquí es donde el Model Context Protocol (MCP) y MuleSoft se unen para transformar radicalmente la forma en que los agentes de IA consumen información y ejecutan procesos

MCP es un estándar open-source para conectar IA a sistemas externos. Introducido inicialmente por Anthropic y que recientemente ha pasado a formar parte de la Linux Foundation (abarca proyectos como Linux, Kubernetes, OpenTelemetry…) Al igual que las APIs nos permiten interactuar en tiempo real con sistemas, aplicaciones, bases de datos… Los Agente/Agentes de IA también necesitan estas capacidades para ser realmente útiles y aportar valor.

Me gusta definir una API como una “pequeña puertecita” en nuestras aplicaciones que permiten a otras aplicaciones/usuarios interactuar con las mismas. Yo veo a MCP de forma similar, pero en este caso los usuarios son Agentes.

Hasta la aparición de este protocolo, cada agente tenía que integrarse de una forma diferente a cada API, generando una fragmentación que dificultaba el escalado y  mantenimiento de soluciones de IA:

• Fragmentación técnica: Cada agente requería una integración personalizada para cada API
• Problemas en el mantenimiento: Cualquier cambio en la estructura de una API obligaba a actualizar manualmente la lógica de cada agente que la utilizaba.
• Acoplamiento de modelos: Las herramientas estaban «atrapadas» en implementaciones propietarias, lo que dificultaba cambiar de un Agente a otro (por ejemplo, pasar de GPT a Claude) sin rediseñar las conexiones

La arquitectura de MCP se basa en tres componentes clave:

• Host: Es la aplicación (como una interfaz de chat en una aplicación o un IDE como VsCode en modo Agente) donde reside el modelo de IA.
• MCP Client: El componente que vive dentro del Host e inicia la conexión con el MCP Server
• MCP Server: Es el servicio que expone herramientas, recursos o prompts. En nuestro caso, MuleSoft actúa como este servidor de alta capacidad.

• Herramientas (Tools): Son funciones ejecutables que el modelo puede invocar para realizar acciones en el mundo real (como «reservar una cita» o «enviar un WhatsApp»).
  • A nivel integración, esta es la pieza más interesante y con mayor valor
• Recursos (Resources): Son fuentes de datos legibles que proporcionan contexto adicional y veraz al modelo (archivos README.md para indicar instrucciones específicas al Agente o archivos de log).
• Prompts: Son plantillas de promts predefinidas que ayudan a guiar el comportamiento del Agente o a estructurar su respuesta de manera estandarizada.

Aquí es donde entra MCP actuando como el «USB-C» de la IA: permitiendo conectar con fuentes de datos (bases de datos, archivos, sistemas locales) y aplicaciones externas de forma segura y estandarizada. Esto permite que la IA no solo genere texto, sino que consulte información veraz y realice acciones concretas.

Conector de MCP en MuleSoft y sus capacidades

MuleSoft ha dado un paso de gigante al lanzar su MCP Connector, actuando como el puente definitivo entre la robustez de la Anypoint Platform y la agilidad de los agentes de IA. Sus capacidades principales incluyen

• Exposición de APIs como «Tools»: Permite transformar APIs o assets ya existentes de integración existente (API que se integra con SAP,  Salesforce, sistemas legacy o bases de datos) en «tools» que el agente de IA puede invocar directamente.
• Ejecución en Tiempo Real: El agente no trabaja con una «foto» de los datos que se entrenaron en su día al modelo, sino que consulta y modifica información en vivo a través de los flujos de MuleSoft.
• Cero Programación en el Modelo: El conector proporciona al Agente la definición técnica (metadata) necesaria para saber qué hace la herramienta y qué parámetros necesita, eliminando la necesidad de codificar lógica de integración dentro del prompt o del modelo.
• Seguridad Enterprise: Hereda todas las capas de seguridad de MuleSoft, permitiendo controlar quién (qué agente) accede a qué información y bajo qué políticas.

El conector a día de hoy nos oferece las siguientes operaciones (después veremos con más detalle algunas de ellas):

MuleSoft como MCP Server

En este modo, Mule «abre la puerta» a los agentes de IA para que interactúen con el MCP Server. Después las veremos con más detalle pero de forma resumida son estas:

• Tool Listener: Se invoca cuando un agente de IA decide invocar una «herramienta». Por ejemplo, cuando la IA dice «necesito reservar una cita», este listener dispara el flujo correspondiente.
• Resource Listener: Expone datos estructurados para que el agente los lea como contexto.
• On New Session Listener: Se activa el momento que un MCP Client se conecta al MCP Server, permitiendo capturar metadatos de la sesión, identificar al cliente y ejecutar lógicas de inicialización o auditoría antes de que se invoquen a las tools
  • Este concepto es importante, ya que a diferencia de las APIS, un MCP Client se conecta a un MCP Server, se queda conectado y a partir de ahí ya se descubren las tools o resources que expone y se pueden invocar, manteniendo la sesion iniciada y viva hasta que se desconecta.

MuleSoft como MCP Client

MuleSoft también puede actuar como cliente, permitiendo que tus flujos de integración consuman capacidades de otros servidores MCP externos:

• Call Tool: Permite que un flujo de MuleSoft llame a una tool de un MCP Server(por ejemplo, una tool de crear ticket del MCP Server de JIRA)
• Get Resource / Get Prompt: Permite traer datos o guías de otros servidores MCP para enriquecer la lógica de integración en MuleSoft.

Caso de Uso Mule como MCP Server: “El Asistente Médico Inteligente” con datos y acciones en tiempo real

Mi background más funcional de cuando empecé en el mundillo IT viene del sector médico.  Así que uno de los primeros casos de uso que se me vinieron a la cabeza fue el de un médico, que desde un chat, mediante lenguaje natural pudiera realizar acciones en lugar de aprender a usar la interfaz de la interfaz de la aplicación.

Imaginemos a un cardiólogo en una consulta con muchos pacientes y tareas que atender. En lugar de navegar por múltiples aplicaciones y menús, lanza una instrucción en lenguaje natural:

«Búscame a mis pacientes con riesgo cardiovascular crítico, reserva una cita conmigo mañana y confírmales la cita por WhatsApp y por SMS».

El caso de uso se básicamente es realizar el siguiente workflow:

1. Interactuar con una BBDD (base de datos) que tiene la información de los pacientes
2. Reservar mediante el sistema de citas
3. Y finalmente enviar un WhatsApp y un SMS al paciente confirmando la cita

A alto nivel sería la arquitectura sería algo similar a esto:

Este caso de uso no requiere construir nuevas integraciones desde cero. Por el contrario, se reutiliza la arquitectura de APIs ya existente en la organización. Y aquí es donde veo la mayor potencia de MCP en MuleSoft, se pueden aprovechar los endpoints y flujos ya existentes de las APIs que están funcionando, y desde las tools del MCP Server, referenciar a las APIS ya funcionando.

• Nota: Para este caso de uso ejemplo, las APIs de Mule que se integran con los sistemas finales descritos (la BBDD de pacientes, el servicio de reserva de citas, la API  de de Twilio) son mocks que siempre devuelven el mismo resultado, pero sirven para esta demo que lo que queremos es ver la capacidad de los agentes de interpretar los resultados y saber a qué tool llamar

Usando MuleSoft como MCP server se quedaría de la siguiente forma la arquitectura:

VSCode (simulando ser un chat en la aplicación de gestión clínica) actuando como el MCP Client, utiliza a GitHub Copilot (el Agente) para conectarse a nuestros servidores MCP en MuleSoft y hablar con las APIs mediante lenguaje natural.

Demo: VSCode + GitHub Copilot como MCP Client realizando la orquestación

Requisitos previos:

• VSCode actualizado (versión 1.96 o superior recomendada).
• Extensión de GitHub Copilot instalada e iniciada sesión en GitHub
• Anypoint Studio min v7.21
• Mule Runtime 4.6+

En el archivo mcp.json deberemos configurar el acceso a nuestros MCP Servers y arrancarlos

Para autenticarnos con los MCP Servers, en este caso por simplicidad usaremos de tipo “Basic Auth”. Ai intentar arrancar los MCP Servers, VsCode nos pedirá que introduzcamos el valor del header Authorization.

Los MCP Servers deberían haber arrancado y ya estarán disponibles a usar por Github Copilot.

Demo

Una vez configurado, abrimos el Chat de Copilot y entramos en modo Agent. Ahora, el médico escribiría lo que requiera. Copilot no tiene un flujo programado, sino que razona qué tools necesita usar basándose en las descripciones que definimos en los MCP servers de Mule. Incluso cuando no tiene los datos suficientes, se los pide al usuario.

Si se quiere ver el detalle concreto de lo que se ha enviado y devuelto en la tool podemos hacerlo:

Finalmente, una vez se tienen todos los datos necesarios seguirá haciendo la orquestación necesaria hasta completar el objetivo inicial definido.

En los siguientes apartados veremos técnicamente cómo se han definido, implementado y probado los MCP Servers en MuleSoft

1. SAPI-PATIENTS

Esta API simula la integración con una base de datos (BBDD) donde está alojada la información de los pacientes de la clínica.

Dispone varios endpoints para simular un CRUD en la BBDD, pero solo vamos a centrarnos en el de obtener pacientes. Como vemos actualmente el API devuelve esta lista de pacientes (GET /pacientes), los cuales algunos de ellos tiene un riesgo crítico

A nivel del API de Mule, es un API super sencillita que devuelve un mock de un listado de pacientes fijo

Para convertir esta API en un MCP Server habrá que hacer lo siguiente:

1.1 Establecer la configuración global del MCP Server

Algunas cosillas a destacar de esta configuración son las siguientes:

Connection (Transporte) Define el protocolo físico de comunicación entre el cliente de IA y la aplicación Mule:

• Streamable HTTP Server: Expone el servidor MCP a través de la red mediante un HTTP Listener. Es la opción necesaria para despliegues en CloudHub, RTF o cuando el cliente de IA accede de forma remota.
• Stdio: Usa los canales de Standard Input/Output(consola). Se suele usar para ejecución y depuración local.

B. Response Content Type (Entrega de Datos) Define la modalidad técnica en la que se envían los paquetes de datos al cliente:

• SSE (Server-Sent Events): Configuración por defecto y recomendada. Mantiene una conexión persistente que permite el «streaming» de datos, ideal para respuestas progresivas de agentes de IA.
• Standard / JSON: Envía la respuesta completa en un único paquete y cierra la conexión inmediatamente después.

1.2 Configurar las tools

Una vez establecida la configuración global, definimos las capacidades específicas que el agente de IA podrá ejecutar. Para nuestro endpoint de pacientes, utilizaremos la operación Tool Listener. Esta operación es el «contrato» que MuleSoft pública para que el Agente sepa cómo interactuar con el sistema.

Configuración del Tool Listener para «get_patients»:

Basándonos en nuestra implementación en Mule, configuramos el listener con lo siguiente:

1. Tool Name: get_patients.
2. Tool Description:«Esta herramienta recupera una lista de pacientes de la BBDD de pacientes. Permite a los consumidores de la API filtrar y paginar los resultados para optimizar la carga de datos.»
   • Importante: Esta descripción es la que el Agente procesa para decidir si esta herramienta es útil para cumplir la petición del usuario.
3. Parameters Schema (JSON): Definimos el contrato que permite al agente saber de qué forma llamar a la tool

Alguna reflexión que veo respecto al Tool Listener:

• Al igual que ocurre con las API Spec REST tradicionales en el Design Center, el Parameters Schema del Tool Listener debería residir en Anypoint Exchange como un asset reutilizable. Esto permitiría que la implementación de la API lo referencie directamente, asegurando que el «contrato» de la tool a esté centralizado, versionado y gobernado desde un único punto de verdad. Estoy seguro que en un futuro próximo esto llegará

Respecto al resto del flujo es bastante sencillo pero se puede ver la potencia de los MCP Servers:

1. Guardamos en una variable el payload que recibe el tool listener que consiste en un objeto con los campos enviados por el MCP Client/Agente
2. Invocamos a un subflujo ya existente en el API REST que se encargaría de integrarse con la BBDD
   1. Aquí es de las cosas más potentes que veo de MCP, podemos reutilizar la lógica/trabajo que ya hacían las API REST y si es necesario modificar algo
3. Finalmente modificamos el payload de respuesta, filtrando por aquellos pacientes con el valor del campo riesgo que nos haya llegado por el MCP Client/Agente
   1. Destacar que esto solo se ha realizado para mostrar algo de lógica adicional que podría realizar el MCP, este filtro  de devolver solo los pacientes según el riesgo indicado debería hacerse en la llamada a la BBDD

1.3 On New Session Listener

Se dispara cuando un cliente MCP se conecta (inicia el handshake) con el servidor MuleSoft

Este flujo en mi caso lo usé para:

• Logear la información que llega cuando un cliente MCP se conecta
• Y validar que el Basic Auth enviado es correcto y proteger mínimamente el acceso al MCP Server
  • La gobernanza/gestión de los MCP Servers debería realizarse al igual que en las APIs desde API Manager, actualmente es necesario Flex Gateway en este blog justo se explica esa parte

1.4 Testear el MCP Server con Postman

En este caso estoy usando Postman pero existe una herramienta que también es super potente llamada MCP Inspector

Crearemos una nueva colección con el botón que solemos crear las colecciones, requests, environments en Postman pero seleccionaremos de tipo MCP

Configuraremos los datos para poder llamar al MCP Server y pulsaremos en el botón “Connect”

Una vez conectados, nos aparecerán las tools disponibles del MCP Server automáticamente, seleccionamos cual queremos usar, informamos los parámetros que necesitemos y lo ejecutamos

Si la llamada de la tool ha funcionado correctamente, veremos que devuelve un listado de pacientes con riesgo “crítico”, que es lo que le habíamos pasado como parámetro en la invocación a la tool de get_patients

Una vez hemos comprobado que nuestra tool funciona correctamente, más tarde la configuraremos en nuestro agente para que sea este el que decida usarla cuando sea necesario y no especificarlo nosotros.

1.5 Subida a runtime manager

Respecto a la subida a runtime manager, no tiene nada de especial que estemos exponiendo un MCP Serve, se genera el JAR y se sube como un API normal. 

Para testear el API con Postman realizaríamos lo mismo del paso 1.4 Testear el MCP Server con Postman, pero simplemente cambiando la baseURL a la del ingress externo ya que en mi caso la he desplegado en CloudHub 2.0

2. SAPI-APPOINTMENTS

Una vez tenemos listo el MCP Server anterior para extraer datos de los pacientes, sapi-appointments nos permitirá simular el comprobar la disponibilidad de una cita en una clínica médica y reservar una cita para el paciente con el doctor

A nivel de configuración es muy similar a la anterior así que no se va a detallar demasiado

Una vez desplegado a CloudHub 2.0 se puede probar la tool con Postman

3. SAPI-TWILIO

Finalmente, para cerrar el proceso, el agente utiliza MCP Server encargado de integrase con el API de Twilio para enviar un mensaje de WhatsApp y un SMS al paciente

Una vez desplegado a CloudHub 2.0 se puede probar las tools  con Postman, por ejemplo la de enviar WhatsApp

Ejemplo de Mule como MCP Client: Hello World MCP Client

Para entender cómo MuleSoft puede actuar como MCP Client, veremos un ejemplo muy sencillo. Podríamos considerarlo como el «Hello World» de la programación tradicional, pero aplicado en este caso a MuleSoft actuando como MCP Client que consume una tool de un MCP Server externo.

En este caso hemos reutilizado por simplicidad el endpoint de crear pacientes aprovechando que en el API esta operación no estaba implementada

A nivel de global config del MCP Client tenemos configurado lo siguiente:

Y lanzando la llamada desde Postman en la respuesta después de pasar el payload a JSON esta sería la respuesta del MCP Server

Veo la opción de Mule como MCP Client es valiosa en escenarios donde necesitamos un comportamiento determinista. Por ejemplo: digamos que estamos implementando un agente de IA con Mule y en cierto punto queremos asegurar que este paso del workflow sea determinista llamando a una tool de un MCP Server.

Conclusiones

• MuleSoft prepara el terreno para evitar el Agent Sprawl
  • Al igual que en su día ocurrió con las APIs, en el cual MuleSoft enfocó su tecnología para poder tener una red de APIs. Actualmente está desarrollando funcionalidades y preparando el terreno para para poder descubrir, orquestar, gobernar y observar agentes. Siendo MCP un componente clave dentro de estos
• ¿1 MCP Server por API?
  • En este caso de uso por simplicidad hemos tenido 1 MCP Server por SAPI, pero se recomienda agrupar por dominio de negocio (Domain Driven Design)
    • https://nordicapis.com/why-mcp-shouldnt-wrap-an-api-one-to-one/
• Ubicación del MCP Server ¿Instancia embebida o separada?
  • ¿Es correcto que el MCP Server esté en la propia instancia del API o debería estar en una propia instancia separada y este que haga una HTTP request al API?
    • En esta demo hemos está dentro de la propia instancia por simplicidad, sin embargo en entornos más reales debería estar el MCP Server en una instancia separada de las APIs:
      • Independencia del Contrato y separación de los ciclos de vida del MCP y API
      • Modularidad
      • Escalabilidad y aislamiento
      • Posibilidad de orquestación de llamadas a varias APIs
• Seguridad: a día de hoy tenemos varias opciones pero ninguna tan estándar o sencilla como las APIs SOAP/REST que conectan con API Manager mediante el ApiKit router:
  • Seguridad en los flujos del API Implementation: Utilizando la operación “On New Session Listener” (la usada en este caso de uso), podemos interceptar headers personalizadas o validar tokens OAuth para validar la identidad del agente antes de exponer las herramientas
  • Seguridad de Red: solo habilitar el ingress interno y que solo se pueda acceder a las APIs de Mule si se está dentro de la misma red en la que se encuentra el ingress interno
  • Flex Gateway: podemos forzar que se pase por una capa de gobierno antes de llegar al API de MuleSoft. En este articulo de Edgar Moran está todo el detalle->Secure Your MuleSoft MCP Server: A Step-by-Step Guide using Managed Flex Gateway | by Edgar Moran | Another Integration Blog | Jan, 2026 | Medium

• Contrato del json schema embebido en el API Implementation El json schema del MCP Server debería estar en el design center, publicado como asset en Exchange y desde el api implementation referenciarlo, al igual que ocurre con las API Spec tradicionales
• Manejo y significado de los errores Anteriormente ya era super importante tener una respuesta de errores estándar, con detalle y que ayudará a los clientes del API a poder entender el motivo y quien había causado el error. Ahora siendo los clientes agentes de IA, es aún más crucial tenerlo ya que a partir de estos errores el agente puede entender el motivo del error, razonar y realizar otra acción (Ejemplo: sapi-appointments devuelve un 404 indicando que no se ha encontrado ningún médico con ese ID, con esto el agente de IA puede entender y pedirle al usuario que revise si la información proporcionada es la correcta)
• Observabilidad: A través de Anypoint Monitoring y los logs de Runtime Manage se puede tener trazabilidad sobre tools de los MCP Servers y la orquestación seguridad. Además mediante el correlationId podemos hacer una trazabilidad E2E de todos sistemas por los que ha pasado

Código en GitHub

• Sapi-patients
• Sapi-appointments
• Sapi-twilio

Bibliografía

• Model Context Protocol Docs
• MuleSoft MCP Connector
• Secure Your MuleSoft MCP Server: A Step-by-Step Guide using Managed Flex Gateway
• Postman MCP requests