Una de las trampas mas comunes con MCP aparece cuando una plataforma tiene demasiado poder. El error natural es exponer cada endpoint como si mas tools siempre significaran mas capacidad. En la practica suele pasar lo contrario: el agente se ahoga en opciones, gasta contexto y elige peor.

Justo por eso el Data 360 MCP Server que Salesforce publico en Developer Preview en mayo de 2026 es mas interesante de lo que parece. La noticia no es solo que Claude Code, Cursor o Codex puedan hablar con Data 360. La noticia es como lo hacen.

Salesforce no puso casi 190 operaciones REST una por una frente al modelo. Las comprime detras de tres facade tools:

search
payload_examples
execute

Ese diseno merece atencion porque ataca un problema real de arquitectura agentica, no solo conectividad.

Secuencia editorial del flujo search, payload_examples y execute para una operacion sobre Data 360

La idea correcta: primero encontrar, luego entender, despues ejecutar

El post oficial describe el flujo tipico asi:

el agente usa search para descubrir la capacidad correcta;
luego pide payload_examples para entender la estructura JSON necesaria;
y al final llama execute con el nombre de la operacion y sus parametros.

Esto suena obvio cuando lo lees, pero casi nadie lo implementa bien.

La mayoria de MCP servers muy grandes caen en una de dos fallas:

exponen demasiadas tools y saturan al modelo;
o esconden demasiado y obligan al agente a adivinar payloads complejos.

Salesforce intenta un punto medio bastante sano: bajar el menu visible sin perder amplitud funcional.

Por que Data 360 era un buen lugar para probar esta idea

La propia empresa admite que la superficie de Data 360 es grande. En el repo hablan de aproximadamente 187 operaciones agrupadas en 21 familias. El blog lo resume como "roughly 200".

Eso incluye cosas como:

ingestion y data streams;
mappings;
transforms SQL;
identity resolution;
calculated insights;
segmentacion y dataspaces;
conectores;
consultas;
semantic data models;
RAG retrievers y search indexes;
activaciones y data actions.

Si expones todo eso como tools aisladas, conviertes el catalogo en un problema. El valor del preview esta en reconocer que la forma de empaquetar capacidades importa tanto como las capacidades mismas.

El repo deja otra senal util: esto esta pensado para prueba local seria

El repositorio oficial no vende humo con disponibilidad total. Dice varias cosas bastante utiles:

hoy corre en contexto single user / single org por proceso;
recomiendan usarlo por STDIO y no exponerlo como servicio de red;
pide Java 17+ y Maven 3.9+;
y trae instaladores para dejarlo andando con clientes comunes.

Tambien deja ver una ruta de adopcion practica:

un script de instalacion para macOS/Linux;
alternativa en Python para Windows;
y setup rapido para credenciales de un org con Data 360 habilitado.

Eso lo vuelve mas interesante para builders que quieren probar de verdad, no solo leer el anuncio.

Instalacion editorial del repo open source, el cliente MCP y el contexto de un org Data 360 aislado

La senal de producto mas importante: preview abierto antes del hosted GA

Otra pieza que me parece madura es la secuencia de lanzamiento.

Salesforce no esta diciendo "esto ya esta listo y perfecto dentro de la plataforma". Esta diciendo algo mas defendible:

aqui esta el server open source en preview;
prueben la arquitectura;
den feedback;
y luego lo integraremos en la capa hosted de Salesforce.

Eso reduce dos riesgos:

esconder un mal diseno detras de la marca del vendor;
esperar a GA para descubrir que el modelo no navega bien una superficie tan grande.

Donde si puede fallar

La idea de facade tools es buena, pero no es automatica.

Puede salir mal si:

search devuelve demasiados candidatos sin criterio;
los ejemplos de payload no representan bien los casos reales;
execute se vuelve una puerta demasiado generica sin buenas restricciones;
el equipo trata la capa de ejemplos como documentacion opcional.

Al final, el patron funciona solo si la recuperacion de la capacidad correcta es lo bastante buena como para compensar la abstraccion.

Por que esta historia tiene demanda real

Las señales de interes aqui no vienen de keyword tools solamente. Vienen de una mezcla mas util:

SERPs muy tecnicas;
un repo oficial abierto;
docs de producto;
y el hecho de que Salesforce ya documenta Data 360 dentro de su mapa general de Hosted MCP.

Las consultas probables son bastante claras:

salesforce data 360 mcp
data 360 mcp server
mcp facade tools
claude code salesforce data 360
codex salesforce mcp

Para Agente IA, eso compite bien porque responde una pregunta mucho mas valiosa que "que es MCP": como exponer una superficie enorme sin romper el loop del agente.

Si quieres ver la version mas orientada a logica de negocio y no a datos, cruza esta nota con Salesforce convierte Apex en Hosted MCP. Y si todavia te falta base para ordenar tools, contexto y validacion, empieza por el curso gratis.

Mi lectura final: Salesforce no solo publico otro server MCP. Publico una hipotesis de empaquetado para APIs grandes: menos tools visibles, mas descubrimiento guiado y mejores ejemplos antes de ejecutar. Si esa receta cuaja, va a influir mucho mas alla de Data 360.