MCP para tu SAP: el día que tu agente IA descubre solo lo que puede hacer (y por qué eso debe darte un poco de miedo)

Imagina esto. Conectas un agente de IA a un sistema y, sin que le programes ni una sola operación, el agente pregunta “¿qué sabes hacer?”, recibe la lista completa de capacidades y empieza a usarlas. No le has escrito código para leer datos, ni para escribir, ni para calcular nada. Él solo descubre todo el catálogo y se pone a trabajar. Eso es MCP (Model Context Protocol), el protocolo de contexto para modelos que se está convirtiendo en el estándar de cómo la IA accede a herramientas externas. De hecho, MCP dejó de ser “el protocolo de Anthropic” para convertirse en estándar de industria: fue donado a la Linux Foundation en diciembre de 2025 (con OpenAI, Google y Microsoft entre los impulsores) y hoy ya existen miles de servidores MCP públicos.

Es una de esas cosas que, la primera vez que la ves funcionar, te quitan el aliento. En uno de los talleres preguntamos a un agente “¿qué materiales tienes en stock por debajo de 50?” y el agente, sin ninguna operación programada a mano, descubrió por sí mismo la herramienta adecuada, la invocó y devolvió los tres materiales que cumplían la condición. Nadie había programado esa consulta. Fue el momento “wow” de la sesión.

Y luego, cuando se apagan las luces de la demo, llega la pregunta incómoda. Porque ese sistema que el agente “descubre solo” puede ser tu SAP. Y “que la IA descubra sola todo lo que puede hacer” es exactamente la frase que tu responsable de seguridad no quiere oír sin muchos matices.

Este artículo va de las dos caras de MCP. Primero, qué es, explicado para gente que viene de SAP. Y después —que es lo que de verdad importa— por qué un MCP genérico le abre al agente toda la superficie del sistema, y cuándo es mejor el trabajo aburrido de definir tú, a mano, exactamente qué puede tocar.

Qué es MCP, explicado para SAPeros

Si trabajas con SAP, ya conoces la idea de fondo de MCP aunque no lo sepas. Solo que la conoces con otro nombre: $metadata.

Cuando abres el $metadata de un servicio OData, el servicio se describe a sí mismo. Te dice de golpe qué entidades existen, qué propiedades tienen, qué operaciones admiten. No tienes que adivinar nada: el propio servicio publica su contrato. Un cliente OData puede leer ese $metadata y saber exactamente cómo hablar con el servicio sin que nadie se lo explique aparte.

MCP hace lo mismo, pero para herramientas de IA. Un servidor MCP publica un catálogo de tools (herramientas), y cualquier agente que se conecte descubre qué herramientas hay disponibles y cómo invocarlas. No le programas las operaciones una a una. El servidor se autodescribe, igual que el $metadata. La analogía que usamos en clase resume la idea en una frase:

MCP es a la IA lo que OData es a SAP: un estándar para descubrir e invocar herramientas, igual que OData estandariza el acceso a los datos.

La diferencia es solo el vocabulario. Donde OData dice “aquí están mis entidades”, MCP dice “aquí están mis herramientas”.

Cómo se ve en la práctica

El mecanismo es sencillo de seguir. El agente se conecta al servidor MCP y lanza una petición de descubrimiento, tools/list. El servidor responde con el catálogo completo: nombre de cada herramienta, qué parámetros acepta, qué hace. A partir de ahí, el agente decide cuál usar según lo que le pidas y la invoca.

En el taller montamos un servidor MCP que exponía cinco herramientas sobre datos de SAP: dos para consultar una función de cálculo de precios y tres para trabajar con materiales (Materiales_query, Materiales_get y una de simulación de precio). Cuando le preguntamos por el stock bajo 50, en el nodo que conecta con el MCP no había ninguna operación configurada. Solo la URL del servidor. El agente descubrió la herramienta Materiales_query, la invocó y devolvió los tres materiales con stock por debajo del umbral. Cero operaciones escritas a mano.

Aquí conviene aterrizar el contraste, porque es el corazón de todo lo que viene después.

La cara B: un MCP genérico libera toda la superficie

Aquí va la opinión que defiendo, y no es la cómoda.

Todo lo que hace a MCP maravilloso —que el agente descubra e invoque las herramientas sin que tú las programes— es exactamente lo que lo hace peligroso en producción. La ventaja y el riesgo son la misma propiedad vista desde dos lados.

El ejemplo que pongo siempre en clase es deliberadamente fuera de SAP, para que se vea claro. Imagina que conectas un MCP directo a un sistema de pagos como PayPal. El catálogo de ese servidor expone todas sus funciones: consultar movimientos, ver saldos, mover dinero. Tú quizá solo querías que el agente leyera el estado de una transacción. Pero el agente ve todo el catálogo. Alguien escribe “¿cuánto saldo hay en la cuenta?” y el agente, encantado, te lo podría contestar. O algo peor, porque esa función de “mover dinero” también está en la lista de herramientas que descubrió. Lo puedes limitar, sí, pero por defecto el MCP genérico está liberando todas las funciones.

Ahora cambia “sistema de pagos” por “tu SAP”. El agente podría leer o escribir cualquier cosa que el servidor MCP exponga: business partners, pedidos, datos financieros, condiciones de precio. No porque alguien lo haya programado para hacerlo, sino porque la herramienta estaba en el catálogo y el agente tiene permiso para descubrirla e invocarla. En un contexto de datos sensibles y operaciones que modifican el sistema, eso no es un detalle técnico: es una decisión de arquitectura de seguridad.

Por eso, en mi forma de trabajar, prefiero a menudo el camino aburrido. Defino las tools manuales como sub-workflows: cada herramienta es un flujo acotado a una operación concreta —leer este conjunto de campos, crear este tipo de documento con estas validaciones— y el agente solo ve esas. Lleva más tiempo de montaje. Pero tú decides exactamente qué puede hacer el agente, ni una operación más. La superficie es la mínima, no la total.

No es purismo. Es que con un MCP genérico no puedo mirar a un cliente a los ojos y decirle “tu agente solo puede hacer estas tres cosas en tu SAP productivo”, porque no es verdad: puede hacer todo lo que el servidor publique.

La mitigación que surgió sola en clase: un MCP por dominio

Lo bonito de enseñar esto en vivo es que, a veces, la mejor idea no la pones tú. La pone un alumno.

En una de las sesiones, hablando de cómo el agente llamaba a varias operaciones de SAP, un asistente preguntó algo que es, sin más, el modelo mental correcto:

¿Se podría exponer cada dominio —business partners, pedidos de compra— como un MCP distinto? Un MCP solo para las acciones de business partners, y otro MCP para las acciones de pedidos.

Sí. Y no es solo una idea ordenada de organización: es la mitigación de seguridad.

En lugar de un único servidor MCP monolítico que lo expone todo, montas un MCP por dominio funcional. Uno para compras, otro para ventas, otro para finanzas, cada uno con su propia autorización. El agente que atiende consultas de compras solo ve y descubre las herramientas de compras. No tiene forma de invocar una operación de finanzas, porque sencillamente no está en el catálogo que él ve. La superficie deja de ser “todo el sistema” y pasa a ser “este dominio, con estos permisos”.

Y aquí está lo interesante: eso es justo el camino por el que SAP BTP está exponiendo MCP. No un agujero gigante hacia todo el core, sino servidores acotados, por capacidad, con autorización diferenciada. El alumno llegó solo, en una hora de clase, a la arquitectura que el propio fabricante está adoptando.

Y la jugada del fabricante ya no es una promesa: en SAP Sapphire 2026 (mayo de 2026) SAP integró Claude (Anthropic) en su plataforma de IA y en Joule vía MCP, y el ABAP MCP Server oficial alcanzó disponibilidad general (GA) en el segundo trimestre de 2026. Es decir, MCP es la vía oficial por la que SAP abre su ecosistema a los agentes. Y precisamente porque esa puerta avanza tan rápido —cada trimestre hay más servidores, más capacidades expuestas, más agentes llamando— el control de la superficie no es algo que puedas dejar para después: hay que cuidarlo con más mimo, no con menos.

La regla de bolsillo, entonces, no es “MCP sí” o “MCP no”. Es esta:

Para SAP productivo con escritura o datos sensibles, el control gana: tools manuales acotadas, o un MCP por dominio con autorización por tool. El MCP genérico abierto es para prototipar, no para producción.

Cuándo cada enfoque, y buenas prácticas de seguridad

No hay un ganador absoluto. Hay un trade-off, y la respuesta correcta depende de cuánta superficie estés dispuesto a abrir y de quién controla el servidor.

Y, como reglas de seguridad transversales, estas son las que repito:

Una nota técnica para cerrar el cómo. Puedes construir tu propio servidor MCP que exponga solo lo que tú decidas: en el taller lo hicimos sobre SAP BTP, publicando una función de negocio acotada como herramienta MCP, consumida desde un orquestador de flujos mediante un nodo cliente que solo necesitaba la URL del servidor. El detalle de cómo se desarrolla ese servidor da para otro artículo entero; aquí lo que importa es el enfoque de arquitectura y consumo. La pieza clave no es el código: es la decisión de qué metes en ese catálogo y qué dejas fuera. Esa decisión es tuya, no del protocolo.

Conclusión

MCP es, casi con seguridad, el futuro del acceso de la IA a SAP. El autodescubrimiento de capacidades es demasiado potente como para que no se imponga, y el propio SAP ya está abriendo ese camino en BTP. Quien no entienda MCP en 2026 se va a quedar fuera de la conversación.

Pero “que la IA descubra sola todo lo que puede hacer” es, palabra por palabra, lo que tu responsable de seguridad no quiere oír sin matices. Y tiene razón. La ventaja de MCP —que expone toda su superficie para que el agente la descubra— es también su mayor riesgo cuando esa superficie es tu sistema productivo.

Así que la pregunta de verdad no es si usar MCP. Es cuánta superficie le das. Tools manuales para control fino, MCP por dominio para compartimentar, MCP genérico solo donde tú mandas en el servidor y los datos no muerden. Define la puerta antes de abrirla.

Fuentes

• Model Context Protocol — Especificación oficial (Anthropic)
• SAP BTP — Soporte para Model Context Protocol (MCP)
• n8n — MCP Client Tool node
• n8n — MCP Server Trigger node
• OData $metadata y Service Documents — SAP Help Portal
• SAP Community — Agentic AI for ABAP / ABAP MCP Server (GA Q2 2026)