Pusimos a prueba el MCP Server de Salesforce Marketing Cloud Engagement con un caso de uso real, de principio a fin. No solo funcionó: nos obligó a repensar dónde aporta valor un consultor cuando la máquina ya sabe teclear.
Hasta hace poco, cualquier tarea en Salesforce Marketing Cloud Engagement (MCE) —crear una Data Extension, montar una automation, construir un journey— pasaba por recorrer la interfaz pantalla a pantalla. En JAKALA quisimos comprobar qué cambia cuando esa misma tarea se puede describir en lenguaje natural y es un agente de IA quien la ejecuta. Para ello pusimos a prueba el MCP Server de MCE: primero explorando sus capacidades y después con un caso de uso completo. Esto es lo que hicimos y, sobre todo, lo que aprendimos por el camino
Un agente que habla el idioma de Marketing Cloud
El puente entre ambos mundos es el Model Context Protocol (MCP), un estándar abierto —impulsado por Anthropic y hoy adoptado por buena parte del sector— que permite a un asistente de IA conectarse a una plataforma externa y operarla a través de un conjunto de herramientas bien definidas. En junio de 2026, Salesforce publicó su propio MCP Server para MCE: un servidor alojado y de nivel enterprise, desarrollado y mantenido por Salesforce, que expone las capacidades núcleo de la plataforma —Data Extensions, journeys, automations, contenido— como herramientas que cualquier asistente compatible con MCP puede invocar en lenguaje natural, sin escribir código ni navegar por la UI. En nuestro caso, el asistente fue Claude, aunque el servidor funciona igual con otros como ChatGPT o Gemini.
Y no, esto no es Agentforce. Agentforce es la plataforma de Salesforce para construir agentes autónomos; el MCP Server es, simplemente, la vía estándar para que el asistente que tú elijas pueda operar MCE. Son piezas distintas y complementarias.
Dos formas de aprovecharlo
El MCP Server admite dos formas de uso que no compiten, sino que se complementan.
Operar MCE en lenguaje natural. El asistente ejecuta tareas —montar campañas, journeys, automations— reduciendo la dependencia de la interfaz y el peso de lo repetitivo.
Acelerar el desarrollo técnico. El consultor mantiene el criterio y el control, y usa el asistente como copiloto para el trabajo de base: SQL, Data Extensions, automations, configuración operativa.
En la práctica, nuestro trabajo se centró en la segunda —el asistente como copiloto técnico—, y lo abordamos en dos fases.
Primero, probar las piezas
Antes de plantearnos ningún caso de uso, dedicamos tiempo a entender qué sabía hacer realmente el servidor. En JLAB, nuestro laboratorio interno de Jakala, fuimos probando las herramientas una a una: crear y consultar Data Extensions, leer esquemas y metadatos, generar SQL de segmentación, crear y modificar journeys, montar automations, operar sobre contenido y canales. No buscábamos todavía un resultado de negocio, sino calibrar el alcance real de cada capacidad, sus límites y su fiabilidad. Es una fase poco vistosa, pero fue la que nos dio la confianza para el siguiente paso: cuando conoces bien cada pieza, diseñas con criterio en lugar de improvisar.
Después, un caso de uso de principio a fin
Con las piezas ya calibradas, montamos un caso de uso real que usara el asistente como copiloto técnico. Elegimos un problema que cualquiera que haya hecho reporting sobre MCE conoce bien: la mayoría de las Data Views —las tablas internas que registran envíos, aperturas, clics y bounces— trabajan con una ventana móvil de seis meses. Lo que queda fuera de esa ventana deja de ser accesible por esa vía. Para cualquier análisis de tendencia a medio plazo, eso es un muro.
La solución de fondo es conocida: montar un sistema que copie ese dato, cada día, a Data Extensions propias que no tengan ese límite. Lo interesante no fue la solución en sí, sino cómo la construimos. A partir de un blueprint funcional que le describimos, el asistente generó y desplegó el sistema completo: veinte Data Extensions —de réplica, de acumulación y de exportación—, veinte queries de carga inicial y acumulación diaria, y cuatro automations programadas para ejecutarse de madrugada. Sobre ese histórico acumulado se calculan automáticamente métricas como open rate, click rate y bounce rate por envío, por asunto y por journey.
Como remate, le pedimos un email de KPIs. El asistente generó una pieza HTML con AMPscript que lee esas Data Extensions de reporting y las presenta en tablas con la identidad visual de JAKALA. El email se construye en el momento del envío —muestra siempre el dato más reciente, sin intervención manual— y va dentro de un journey con un decision split que filtra a los destinatarios antes de enviar. Todo el proceso, desde la Data Extension de entrada hasta el journey publicado, se completó sin salir de la conversación.
Lo que no le dejamos hacer
Tres cosas que no se ven en una demo.
El blueprint importa más que el prompt. El asistente no adivina: rinde en la medida en que el contexto y el diseño funcional están bien definidos de antemano. El trabajo de pensar la solución sigue siendo humano; lo que cambia es quién teclea.
El consumo es medible. Tokens de IA y llamadas a la API, con los límites y guidelines de la API de Marketing Cloud aplicando como en cualquier integración. Esto no es magia gratis, y poder medirlo es justo lo que lo hace evaluable.
Entiende el negocio, no solo la sintaxis. El momento que mejor lo resume lo cuenta Alberto Clemente, consultor de JAKALA:
“Lo más sorprendente no es que Claude pueda hacer llamadas API constantes a Marketing Cloud, sino que entiende el contexto de negocio de lo que estás construyendo. Cuando había un error de Primary Key en una Data Extension, no solo lo detectó: explicó por qué la estructura era incorrecta y propuso la solución correcta.”
El siguiente paso: de JLAB a una PoC
Lo que hemos validado en laboratorio nos deja, a partes iguales, una convicción y una cautela. La convicción: esta forma de trabajar acelera de verdad el trabajo de base y libera tiempo para lo que aporta criterio. La cautela: conviene medirla antes de escalarla. Por eso el siguiente paso ya está en marcha: vamos a llevar lo aprendido a una PoC con un cliente, trabajando varios casos de uso en un entorno de preproducción. Mediremos el éxito con criterios concretos: cuánto se reducen los tiempos de construcción y el retrabajo, qué consumo real supone (tokens y llamadas a la API) y, en el plano de seguridad y gobierno, cómo responde la validación de permisos y la supervisión humana en los pasos sensibles. Solo con esos datos sobre la mesa decidiremos cómo y dónde escalarlo a producción.
La dirección de fondo es clara. Salesforce describe este servidor como un primer paso hacia una experiencia headless, donde los datos, la lógica y la orquestación de la plataforma son accesibles sin pasar por la interfaz. El MCP Server es una de las primeras señales tangibles de hacia dónde va todo esto. Y preferimos aprender a trabajar así ahora, con un caso de uso en la mano, que descubrirlo cuando ya no sea opcional.
