Un agente de IA puede comprender una petición y, aun así, llamar a la herramienta equivocada. «Consulta el estado del pedido» no debería concederle acceso a una consola administrativa, a todas las APIs del ERP ni a una operación de escritura que no necesita. Entre la intención del usuario y el sistema de negocio hace falta un contrato claro: qué acción existe, qué datos acepta, qué devuelve y con qué autoridad se ejecuta.
El Model Context Protocol (MCP) proporciona un formato para que un cliente descubra herramientas de un servidor y las invoque con argumentos estructurados. SAP documenta su conexión con agentes de Joule Studio, classic edition. La oportunidad práctica no consiste en «conectar un agente a todo», sino en exponer una superficie pequeña y comprobable para una tarea de negocio concreta.
Hay una distinción temporal importante. La documentación de MCP consultada corresponde explícitamente a Joule Studio, classic edition. En una comunicación del 8 de octubre de 2026, SAP describía el nuevo Joule Studio como «próximo» a disponibilidad general y explicaba que los agentes nuevos se desplegarían en Joule Work. No conviene trasladar automáticamente los pasos de la edición clásica a la nueva plataforma ni dar por disponible una función solo porque haya sido anunciada.
El patrón: un agente, una fachada, herramientas pequeñas
Imaginemos un asistente de operaciones que ayuda a revisar entregas retrasadas en SAP S/4HANA. Una arquitectura prudente separa cuatro responsabilidades:
- Joule Agent interpreta la solicitud y selecciona una herramienta cuyo nombre y descripción expresan un propósito concreto.
- Servidor MCP publica un catálogo limitado de herramientas tipadas; no entrega al modelo una sesión genérica contra el ERP.
- Fachada de negocio valida identidad, parámetros, reglas, autorización y límites de volumen. Puede llamar a APIs empresariales aprobadas y aplicar lógica de proceso.
- SAP S/4HANA conserva el dato y la transacción de negocio. La fachada devuelve al agente solo el resultado necesario para responder o continuar.
La fachada puede implementarse con tecnologías adecuadas a la arquitectura de la empresa —por ejemplo, un servicio propio sobre SAP BTP—, pero eso es una decisión de diseño, no un requisito de la documentación de Joule. El límite esencial es semántico: el servidor ofrece operaciones de negocio, no una traducción indiscriminada de tablas o endpoints.
Diseña el contrato alrededor de una pregunta
Para un primer piloto, una herramienta de lectura podría llamarse get_delivery_status. Su entrada sería un identificador de entrega y, como máximo, un ámbito organizativo que el servidor pueda verificar contra la identidad del usuario. Su respuesta contendría estado, fecha prevista, último hito y una explicación breve de la fuente. No hace falta devolver todos los socios, direcciones, importes y notas de la entrega si la pregunta no los requiere.
{
"name": "get_delivery_status",
"description": "Devuelve el estado y la fecha prevista de una entrega autorizada.",
"inputSchema": {
"type": "object",
"properties": {
"delivery_id": {"type": "string", "minLength": 1, "maxLength": 20}
},
"required": ["delivery_id"],
"additionalProperties": false
}
}Este fragmento ilustra un contrato de herramienta, no una configuración lista para copiar en Joule. El servidor debe validar de nuevo la entrada: el esquema ayuda al cliente y al modelo, pero no sustituye la validación del lado que ejecuta la llamada. Conviene rechazar campos desconocidos, limitar tamaños y definir qué significa exactamente «estado» para que una respuesta no dependa de interpretaciones implícitas.
De la lectura a la escritura: una frontera deliberada
La siguiente herramienta no debería ser una operación ambigua como update_delivery. Si el caso de negocio requiere bloquear una entrega, separa la propuesta de la ejecución. Un agente puede primero producir una recomendación con el motivo y las evidencias; un usuario autorizado confirma la acción en el flujo empresarial; y una herramienta de escritura acepta una referencia de aprobación verificable. La API aplica de nuevo las reglas en el momento de ejecutar.
Una petición de escritura debería llevar una clave de idempotencia o un identificador de operación para que un reintento no cree dos bloqueos. También debe devolver un resultado inequívoco: ejecutado, rechazado por regla, pendiente de aprobación o ya procesado. MCP transporta una llamada y su respuesta; no vuelve idempotente una transacción ni resuelve por sí solo el control de autorizaciones del negocio.
Esta separación es un análisis de arquitectura, no una promesa de que cada implementación de Joule incluya un mecanismo universal de aprobación humana. La confirmación puede residir en la interfaz corporativa, en un workflow o en el servicio de negocio, según el escenario. Lo importante es que la autoridad final no dependa únicamente de las instrucciones en lenguaje natural del agente.
Conectar el servidor en Joule Studio, classic edition
La guía oficial de SAP especifica requisitos concretos que conviene verificar antes de abrir el editor del agente:
- El servidor debe exponerse mediante una destinación HTTPS de tipo Streamable; las destinaciones de tipo SSE no se admiten en este flujo.
- La destinación requiere la propiedad adicional
sap-joule-studio-mcp-server = true, debe registrarse en Control Tower y su URL base no debe terminar en/mcp. El path del servidor se configura aparte. - Se crean destinaciones tanto en la subcuenta de Joule Studio como en la de Joule, con el mismo nombre en ambas.
- La guía enumera autenticación básica, Client Credentials y JWT Bearer entre las opciones compatibles; recomienda Client Credentials para servidores MCP. Hay restricciones: Principal Propagation no es compatible y varios flujos OAuth interactivos no funcionan en esta integración.
Dentro del agente se añade el servidor MCP, un nombre y una descripción útil, se selecciona la destinación y se revisan las herramientas que anuncia. La descripción no es decorativa: ayuda al agente a decidir cuándo usar la conexión. Si dos servidores exponen nombres de herramienta parecidos, un namespace claro evita colisiones y hace las trazas más legibles.
SAP documenta un timeout predeterminado de 200 segundos para esperar la respuesta de una llamada. No lo conviertas en una excusa para ocultar operaciones lentas. Mide los tiempos de extremo a extremo, define un presupuesto por herramienta y devuelve estados de progreso o un identificador de seguimiento cuando el trabajo no pueda terminar en una interacción breve.
Prueba útil: inspecciona la decisión y el tiempo, no solo la respuesta
En la edición clásica, SAP indica que para probar un agente se necesita un entorno privado y activar AI Agent Builder Activation. La vista de prueba permite revisar la secuencia de eventos anidados, abrir trazas y registros de solicitudes, ver la configuración y observar el tiempo consumido por cada paso. Es un buen punto de partida para detectar si el agente llamó a una herramienta innecesaria, envió datos de más o se quedó esperando al sistema externo.
Prueba el contrato con casos normales y adversos antes de desplegarlo:
- Una entrega existente y autorizada: respuesta correcta, campos mínimos y fuente identificable.
- Un identificador inexistente o fuera del ámbito del usuario: error controlado, sin filtrar si existe en otra sociedad.
- Una entrada mal formada, demasiado larga o con propiedades adicionales: rechazo en el servidor.
- Un MCP server lento o no disponible: timeout coherente y mensaje que no invente un resultado.
- Un intento repetido de una operación de escritura: una sola transacción gracias a la clave de idempotencia.
Registra por llamada el nombre y versión de la herramienta, el resultado técnico, duración, identificador de correlación y decisión de autorización. Evita guardar indiscriminadamente prompts completos, datos personales o respuestas sensibles. La observabilidad sirve para explicar fallos y costes; no justifica ampliar la retención de información sin propósito.
Despliegue: privado antes de compartido
La guía de despliegue de Joule Studio, classic edition exige liberar el proyecto, disponer de un entorno y contar con el rol Extensibility_Developer; si el proyecto contiene un agente, también debe estar activa la opción correspondiente de creación de agentes. SAP advierte de posibles conflictos con capacidades estándar al desplegar proyectos en el asistente compartido y recomienda probar antes. La edición clásica impone además límites al uso de entornos compartidos: como máximo diez grupos de usuarios o cinco usuarios, sin mezclar ambas modalidades en el mismo entorno.
Un plan breve y reutilizable puede ser:
- Día 1: acordar una pregunta de negocio, propietario, usuarios, datos y APIs permitidas.
- Días 2–3: publicar solo una herramienta de lectura y validar autorización, esquema y errores.
- Días 4–5: probar trazas y latencia con usuarios piloto; corregir nombres, descripciones y respuesta.
- Después: añadir una acción de escritura únicamente si existe caso medible, aprobación explícita e idempotencia.
Lo confirmado y lo que todavía no debe darse por hecho
Confirmado por SAP: Joule Studio, classic edition permite añadir servidores MCP a agentes; la conexión usa destinaciones con requisitos específicos y permite revisar las herramientas expuestas. La edición clásica ofrece una prueba con trazas y medición por pasos. El 8 de octubre, SAP comunicó que Joule Studio se encontraba próximo a disponibilidad general y que el nuevo SAP AI Agent Hub ya estaba generalmente disponible para gobernar agentes, modelos y servidores MCP.
Lectura de Sapindex: MCP reduce el coste de describir e invocar herramientas con contratos comunes, pero no elimina el trabajo de modelar permisos, semántica, errores y operaciones repetibles. El mejor piloto no es el que conecta más sistemas: es el que demuestra que una herramienta concreta responde a una necesidad sin exponer datos ni acciones que el usuario no necesita.
Para un ejemplo de cómo una integración debe sobrevivir a reintentos y duplicados, consulta nuestro patrón de arquitectura SAP orientada a eventos. Para el marco más amplio de adopción empresarial, enlazamos también la guía sobre inteligencia artificial en SAP y el artículo de gobierno de automatización e IA.
Un agente útil no necesita una llave maestra. Necesita herramientas que expresen bien el trabajo, un servidor que haga cumplir las reglas y una prueba que permita seguir cada decisión. Ese contrato convierte una demostración conversacional en una extensión empresarial que se puede entender, medir y mantener.
