Qué es el MCP Server de Marketing Cloud Engagement y qué esperar de él

El dolor

Conectar una IA a Marketing Cloud Engagement dejó de ser un proyecto para pasar a ser una realidad cuando Salesforce puso en producción su propio servidor MCP. Es oficial, está alojado por ellos y montarlo son diez minutos.

El problema es exactamente ese. Son diez minutos, no hay que escribir código, y nadie te explica qué acabas de enchufar a tu org.

En una frase

Después de una semana probándolo contra una org real, mi resumen es este:

Sirve para entender tu org y para construir dentro de ella. No sirve para administrarla ni para saber cómo va. No esperes un agente que te sirva de consultor.

Si solo te llevas una idea del artículo, que sea esa. El resto es el detalle de por qué.

Las tres piezas, y por qué conviene no confundirlas

La documentación oficial lo explica bien y no me voy a extender: hay tres componentes. El LLM, que es el modelo que interpreta lo que pides. El cliente, que es la aplicación desde la que hablas (Claude Code, Gemini CLI, etc.). Y el servidor MCP, que es el único que toca Marketing Cloud.

Merece la pena pararse aquí porque casi todo el mundo dice "he dado acceso a Claude" sin saber muy bien qué implicación tiene y qué resultado esperar. El permiso no lo tiene el modelo. Lo tiene el installed package de tu org, y eso significa que la conversación sobre seguridad no va de qué asistente usas, sino de qué marcaste en una pantalla de checkboxes.

Y hay un detalle que no sale en los resúmenes: la autenticación es interactiva. No es una integración server-to-server con identidad propia. El agente actúa como el usuario que autenticó, así que en el registro de auditoría de la org todo aparece con el nombre autenticado. No existe una identidad "el asistente" a la que pedir cuentas después.

Lo que no existe

Esta es la sección que a mí me habría ahorrado más tiempo, porque la documentación te cuenta lo que hay y no lo que falta. Y lo que falta no es cuestión de permisos: no existen las herramientas.

Fuera del catálogo se quedan los usuarios, los roles y los permisos. La configuración de cuenta y todo Setup. Los informes y la analítica de envíos. El historial de cambios. Y WhatsApp, que no tiene ni herramienta ni endpoint.

Hay una ausencia que es más fina de lo que parece: no puede decirte cuánto consumo de API llevas. Cada llamada que hace sale de tu límite anual, el que depende de tu edición de Marketing Cloud, y no hay ninguna herramienta que te diga por dónde vas. Gasta tu cuota y no sabe contarla. De momento, no es crítico.

Y ya que hablamos de consumo, conviene decir de dónde sale el dinero: Salesforce no te cobra nada por el servidor. No hay coste adicional, ni licencia nueva, ni SKU que negociar con tu account executive. El coste está en el otro lado:

Cada cosa que le pides consume tokens del asistente, así que la factura cae en tu contrato de IA, no en el de Marketing Cloud.

Parece un detalle contable y no lo es. Significa que el gasto cambia de bolsillo y probablemente de departamento, que es variable según cuánto lo uséis, y que quien aprueba la conexión no suele ser quien paga la consecuencia. Merece la pena saber quién paga eso antes de enseñárselo a un equipo entero.

Una herramienta no es una llamada a la API

Hasta ahora, los desarrolladores hemos usado las librerías API para poder integrarnos con Marketing Cloud para realizar acciones como crear una Data Extension, insertar un registro en un Journey, borrar un contacto. De esta forma, cada operación que queríamos realizar en Marketing Cloud se traducía en una llamada a la API.

Pero con el servidor MCP las cosas cambian. En lugar de llamar directamente a la API, lo hacemos a través de herramientas. Es decir, podemos pedirle a nuestra IA que realice acciones en Marketing Cloud de manera nativa, sin tener que programar código.

Al revisar las descripciones de las herramientas del MCP Server, me di cuenta de que no son solo una lista de funciones disponibles, sino un sistema de instrucciones que guían al agente sobre cómo y cuándo usar cada herramienta.

O sea que:

Salesforce no está exponiendo una API. Está dirigiendo a un agente.

¿Lo malo? Dependemos de la evolución de un producto que no controlamos.

¿Lo bueno? Que Salesforce se encarga de mantener actualizado el servidor MCP con las novedades de la plataforma. Y que trae protecciones, aunque conviene entender de qué tipo: en su mayoría son instrucciones escritas para que el modelo las lea y las obedezca, no permisos que impidan la operación. Protegen, pero no de la misma forma que un scope definido en el installed package.

¿Integración o asistente?

Siguiendo desde el punto anterior, la pregunta que se podría hacer cualquiera es si viene a sustituir las integraciones. La respuesta corta es no. En mi opinión:

Esto no sustituye a una integración. Sustituye a que tú abras Postman.

Es decir, lo que desaparece es la fontanería, y es mucha: el token, la URL base, saber si toca REST o SOAP, la cabecera correcta, la forma del payload, y la coreografía de las operaciones que son varias llamadas encadenadas. Todo eso lo pone el servidor MCP de Salesforce.

Lo que no desaparece es saber cómo funciona Marketing Cloud Engagement o cómo funciona tu negocio.

Durante estos años he estado trabajando con soluciones IA personalizadas que se comunicaban con Marketing Cloud a través de API. Y una de las cosas que más me gustaban era precisamente no tener que tocar la interfaz de usuario. Me gusta la programación y me gusta la IA, por lo que esa combinación era perfecta para mí. Pero la realidad es que para muchos usuarios no es así.

Este servidor MCP ha solventado y mejorado algunas de las soluciones con las que he estado trabajando durante estos años. Por ejemplo, la creación de contenido dinámico, la creación de Data Extensions o Query Activities. Todas estas operaciones requerían hasta ahora una integración personalizada. Con el servidor MCP, estas operaciones se pueden realizar de manera nativa sin escribir una sola línea de código.

Por supuesto, la curva de aprendizaje es menor. No tienes que aprender a usar una nueva herramienta de desarrollo, sino que puedes usar la conversación con el agente. Y lo mejor de todo es que la integración está hecha desde Salesforce, por lo que no tienes que preocuparte por mantenimientos, actualizaciones ni problemas de compatibilidad. La contrapartida es que tampoco decides tú: evolucionan ellos. Algo que hoy usas puede desaparecer, y algo que echabas de menos puede aparecer sin que te avisen. No es tu mantenimiento, pero sí tu vigilancia.

¿Qué no cubre por ahora y en lo que he estado trabajando? Conocer el contexto de negocio, por lo que, en mi caso, he necesitado crear soluciones personalizadas para cubrir estas necesidades.

¿Supone esto una regresión? Bueno, volvemos a tocar código. Pero no es lo mismo que antes. Ahora el código puede ser mucho más simple, ya que no tenemos que preocuparnos por la autenticación ni por la estructura de la API. Y lo mejor de todo, puede evolucionar y seguro que lo hará.

Qué debes tener en cuenta antes de conectarlo

Cuatro decisiones o recomendaciones que deberás tomar antes de conectarlo.

El paquete es el único control real. No lo es la lista de herramientas de tu cliente MCP, ni el criterio del modelo. Los scopes del installed package son los que marcan qué podremos hacer y qué no. Créalo aparte, con lo mínimo, y no le añadas un permiso "un momento, para probar".

Empieza en solo lectura y quédate ahí un tiempo. Casi todo el valor está en documentar y entender. Escribir puede esperar a que sepas qué tienes.

Asume que el agente actúa como tú. Si eso te incomoda en la org de un cliente, valora si deberías conectarlo o no.

Decide quién vigila el catálogo, y cada cuánto. El servidor cambia: Salesforce añade herramientas, y una herramienta nueva no está en la lista de las que bloqueaste, así que llega concedida por defecto. Lo que autorizas hoy protege del catálogo de hoy. Ponle un responsable y una fecha en el calendario, o no va a pasar.

Qué marcar exactamente en esa pantalla, y qué dejar sin marcar, da para un artículo entero y lo escribiré más adelante en esta serie.

El límite

Esto no es una guía de instalación: para eso está la documentación oficial, que además está bien. Tampoco es una evaluación de producto ni una recomendación de su uso. Y no cubre si tu cliente te deja conectar un tercero a su org, que es una conversación de contrato y no una decisión técnica.

Lo dice el propio Salesforce en la primera página, y lo suscribo entero: la IA puede producir resultados inexactos o dañinos, hay que asignar únicamente los permisos necesarios, revisar lo que devuelve, y la responsabilidad de lo que hagas con el resultado es tuya.

Qué viene ahora

Acabamos de ver que esto lee datos de contacto, escribe, ejecuta y envía. La pregunta siguiente es qué puede salir mal, y dónde está la línea entre leer la estructura de una org y leer los datos de las personas que hay dentro. Es más difícil de trazar de lo que parece, y de eso irá el próximo artículo.