Salesforce convierte Apex en Hosted MCP: cuando tu logica de negocio deja de vivir solo en la UI

En muchas empresas la parte mas valiosa del stack no vive en el modelo ni en el prompt. Vive en la logica de negocio enterrada durante anos en CRM, Flows, reglas, validaciones y clases internas. Esa capa siempre fue util, pero casi siempre estaba atrapada detras de la UI.

Salesforce movio esa frontera el 13 de mayo de 2026 con una guia que vale mas de lo que parece: ya puedes exponer Apex como Hosted MCP tool para agentes. Dicho sin maquillaje, una clase con logica real puede pasar de servir pantallas internas a servir directamente a Claude, ChatGPT, Cursor o cualquier cliente MCP compatible, usando infraestructura gestionada por Salesforce.

Lo importante no es MCP; es que la logica sale de la interfaz

El blog de Salesforce arranca con una idea fuerte: la plataforma siempre tuvo logica de negocio profunda, pero esa inteligencia estaba amarrada a Lightning, Visualforce o flows internos. Con Headless 360 y Hosted MCP, esa misma capa puede quedar disponible como herramienta para un agente.

El ejemplo oficial no usa una demo trivial. Usa una tool de pipeline intelligence que:

• resuelve una cuenta con fuzzy matching;
• cruza objetos relacionados en una sola consulta;
• calcula riesgo por deal;
• devuelve pipeline ponderado;
• y resume salud comercial con contexto listo para interpretar.

Eso es exactamente el tipo de cosa que un agente aprovecha mejor que un endpoint crudo. No recibe solo filas. Recibe una respuesta ya pensada para decidir.

La parte tecnica que si cambia como debes escribir herramientas

Salesforce deja una advertencia muy buena entre lineas: el agente no lee tu codigo; lee tu schema y tus descripciones.

Cuando un cliente MCP hace tools/list, el modelo ve basicamente:

• nombre;
• descripcion;
• inputSchema;
• outputSchema.

Con eso decide si usa la tool, que parametros manda y como interpreta la salida. Por eso el post insiste tanto en descriptionOverride, anotaciones @InvocableVariable y schemas generados desde Apex. La implicacion practica es grande:

• una descripcion vaga reduce seleccion correcta;
• una salida cruda obliga al modelo a adivinar;
• una tool demasiado estrecha o demasiado amplia empeora comportamiento.

En otras palabras, esta noticia no solo va de conectividad. Va de disenar herramientas para que un agente pueda elegirlas bien.

Donde Salesforce si tiene una ventaja rara

Lo mejor del enfoque Hosted MCP no es que "ya viene listo". Lo mejor es que hereda piezas de plataforma que casi siempre cuestan meses reproducir fuera:

• grafo de objetos ya modelado;
• permisos por usuario y sharing rules;
• automatizaciones y Flows existentes;
• y logica Apex que la empresa ya pago con anos de trabajo.

La documentacion de productos soportados deja ver ademas que el menu no se queda en Apex. Salesforce tambien puede exponer @AuraEnabled, Apex REST, endpoints del API Catalog, Flows, Data 360 y varios servidores SObject con distintos niveles de mutacion.

El mejor detalle del anuncio: no todo debe ir en un solo server

La doc de custom servers pone una regla que muchos builders necesitan escuchar: un cliente MCP tiene limites practicos sobre cuantas tools puede usar bien. Si metes demasiadas en el mismo buffet, el modelo empieza a seleccionar peor.

Salesforce propone curar servidores por persona o workflow. Eso es buen criterio tambien fuera de Salesforce. Un vendedor no necesita el mismo set de tools que finanzas. Un agente de soporte no necesita todo lo que toca revenue ops.

Este punto vuelve la historia mucho mas valiosa para SEO cualificado, porque responde problemas concretos:

• hosted mcp salesforce
• apex mcp tool
• salesforce headless 360
• salesforce mcp custom server

No es trafico de curiosidad. Es trafico de equipos que ya operan Salesforce y quieren sacar valor a agentes sin reinventar auth, routing y tool discovery.

Los riesgos reales

No leeria esto como permiso para exponer cualquier clase vieja y esperar magia.

Los errores mas probables son:

1. publicar tools demasiado granulares que obligan al agente a encadenar pasos fragiles;
2. publicar tools demasiado amplias que mezclan responsabilidades;
3. dejar descripciones pobres y luego culpar al modelo por elegir mal;
4. olvidar que el valor de Salesforce esta en devolver insight computado, no campos crudos.

El ejemplo del blog funciona porque ya entrega evaluacion de riesgo y health summary dentro del metodo. Eso le ahorra interpretacion innecesaria al modelo.

Mi lectura

Esta es una noticia mejor de lo que aparenta porque no se trata solo de "Salesforce ya habla MCP". Se trata de que una empresa puede reusar su logica madura de negocio como capa operativa para agentes sin montar un servidor paralelo desde cero.

Si tu equipo ya vive en Salesforce, esta nota abre una ruta muy concreta para conectar agentes con contexto real y permisos reales. Y si todavia estas ordenando cuando conviene exponer tools y cuando no, compara este enfoque con Salesforce Marketing Cloud Engagement en MCP GA: una historia va por operaciones de campaign ops; la otra va por convertir tu propia logica de negocio en interfaz para agentes.

La senal de fondo es simple: el valor de MCP no esta solo en conectar APIs externas. Tambien esta en liberar logica interna de alto valor para que un agente la use con criterio, contexto y seguridad.