Salesforce MCP: conectar dejó de ser la parte difícil

Durante veinte años, conectar cualquier cosa a Salesforce implicaba un proyecto. Middleware, mapeo de campos, una cuenta de servicio, una fecha de salida en vivo. Eso ya no es así, y lo interesante es lo que queda después.

Un cliente nos preguntó hace poco qué haría falta para que su equipo pudiera hacerles preguntas a sus datos de Salesforce en lenguaje natural, desde las herramientas en las que ya trabaja. Hace cinco años, ese alcance habría empezado con una arquitectura de integración y una cifra con varios ceros.

Con Salesforce MCP, la respuesta honesta hoy es que la parte de conectar es casi trivial. Lo que no es trivial es decidir a qué conectarlo.

Ese giro es toda la historia, y es fácil perderla de vista entre los anuncios de producto.

Qué cambió realmente

En abril de 2026, Salesforce puso los servidores MCP alojados en disponibilidad general para toda org con Enterprise Edition o superior. Salesforce MCP estaba en piloto desde la primavera de 2025 y en beta desde octubre de ese año.

MCP son las siglas de Model Context Protocol. Es un estándar abierto que define cómo los asistentes de IA se comunican con los sistemas que guardan datos reales. La forma útil de entenderlo no es como una función de Salesforce, sino como un enchufe común. Antes, cada herramienta de IA que quisiera llegar a tu CRM necesitaba su propia conexión a medida, construida y mantenida por separado. Con MCP, todas hablan el mismo idioma.

Un servidor MCP alojado es un punto de conexión que Salesforce opera por ti. Expone las partes de tu org que elijas (objetos concretos, flujos, acciones de Apex, consultas definidas) a cualquier cliente de IA que hable el protocolo. Salesforce se encarga del alojamiento, la autenticación y la aplicación de permisos. No hay nada que aprovisionar ni disponibilidad que administrar.

En términos prácticos: tu Salesforce se convierte en algo con lo que un asistente de IA puede conversar, desde la herramienta en la que tu equipo ya vive, sin que nadie tenga que construir antes un puente.

Cómo era antes este problema

Vale la pena ser preciso sobre lo que desapareció, porque la diferencia no es gradual.

La versión anterior era un proyecto de desarrollo. Elegías un middleware o escribías tú mismo la integración. Creabas una cuenta de servicio y negociabas sus permisos con alguien de seguridad. Mapeabas campos. Manejabas reintentos, fallas y límites de llamadas. Escribías un manual de operación. Y después mantenías todo eso, que se rompía más o menos cada vez que algo cambiaba en el sistema de origen.

La versión nueva es una tarea de configuración. Habilitas un servidor en Setup, creas una external client app y conectas el cliente. Salesforce calcula menos de treinta minutos para todo el camino, y en nuestra experiencia no es marketing. Dejar funcionando la primera conexión lleva de verdad una tarde, incluida la lectura.

Eso significa que los meses de esfuerzo que antes se iban en construir la conexión ahora quedan libres para otra cosa. La pregunta es si los equipos los invierten en las decisiones, o si simplemente llegan más rápido a una posición peor.

El cambio que más importa no es el protocolo

Si vas a leer una sola sección de este artículo, que sea esta. Lo técnicamente interesante de MCP es la estandarización. Lo interesante por sus consecuencias es un cambio más silencioso en cómo funciona el acceso.

Las integraciones tradicionales se ejecutan con una cuenta de servicio. Una sola identidad, casi siempre creada hace años, casi siempre con más permisos de los que nadie recuerda haber concedido, actuando en nombre de todos. Cuando esa integración escribe un registro, el historial de auditoría dice que lo hizo la integración. Si la integración puede ver todo, también puede verlo cualquier cosa que se conecte a través de ella.

Salesforce MCP no funciona así. Cada transacción se ejecuta como el usuario autenticado. Los permisos CRUD, la seguridad a nivel de campo y las reglas de uso compartido se aplican exactamente igual que ya se aplican a esa persona. El acceso se controla con OAuth y PKCE, y en este modelo no existen cuentas de servicio anónimas.

Actualización. Ese modelo está cambiando para los agentes que se conectan desde fuera de Salesforce. Salesforce anunció que los agentes externos, usen MCP o la API, se registrarán en la plataforma con su propia identidad y su propio permission set, más acotado, en lugar de actuar como la persona a la que ayudan, y que sus llamadas se medirán para facturarse. Lo central de esta sección se mantiene, y con más fuerza: lo que un asistente puede alcanzar pasa a ser una decisión explícita sobre una identidad con nombre, y no algo que hereda de quien pregunta. Salesforce explica el cambio en Understand AIforce Impact (en inglés).

De ahí salen dos cosas, y las dos vale la pena decirlas en voz alta en tu próxima reunión interna.

La buena noticia. El asistente no puede ver nada que la persona que pregunta no pudiera ver ya. Tu modelo de permisos actual, ese que tus administradores llevan años afinando, es el que hace el trabajo. Si el agente actualiza un registro, el nombre de esa persona queda en el historial de auditoría. Nadie tiene que aprender un modelo de seguridad nuevo ni confiar en uno.

La noticia incómoda. Tu modelo de permisos ahora sostiene un peso que antes nunca tuvo del todo. Si un usuario tiene acceso de lectura a un campo que nadie sabía que podía leer, probablemente nunca lo notó, porque encontrarlo habría implicado navegar hasta un formato de página olvidado. Un asistente lo va a mostrar en un resumen la primera vez que sea relevante. El exceso de permisos que durante años fue teórico se vuelve visible en la primera semana.

Esto no es un argumento en contra de conectar nada. Es un argumento para revisar tus permission sets antes de hacerlo, y no después de que alguien pegue una respuesta sorprendente en un canal.

Con cuánto detalle se decide qué exponer

La otra cosa que conviene entender antes de definir el alcance es que “conectar la IA a Salesforce” no es una sola decisión. La plataforma trae varios servidores preconfigurados con capacidades deliberadamente distintas, y tú eliges.

Los servidores SObject preconfigurados se dividen de la forma más lógica: sobject-reads solo lee y consulta, sobject-mutations permite crear y actualizar pero no eliminar, sobject-deletes cubre la eliminación y sobject-all da acceso completo. Habilitar uno y no los demás es un límite real, aplicado por la plataforma, no una política que esperas que la gente respete.

Además de esos, puedes construir servidores personalizados que expongan exactamente lo que quieras:

• Named Queries te permiten definir con precisión qué objetos y campos devuelve una herramienta. Es la opción que la mayoría de los equipos debería estar usando y casi ninguno usa. Permite que un asistente responda preguntas sobre una parte concreta de tu modelo de datos sin exponer toda la superficie de consulta de tu org.
• Los flujos y las Apex Invocable Actions se pueden exponer como herramientas. Esto importa más de lo que parece: significa que el asistente llama a tu lógica de negocio, con tus validaciones y tus efectos secundarios, en lugar de manipular registros directamente y esperar que el resultado coincida con tu proceso.
• Las plantillas de prompts les dan a las personas un punto de partida sensato para tareas recurrentes, basado en tus datos y no en lo que el usuario haya escrito en ese momento.

También hay una propiedad de seguridad estructural que es fácil pasar por alto. El servidor define exactamente qué operaciones existen. Un asistente no puede llamar a algo que no se expuso de forma explícita, porque desde su punto de vista esa operación no existe. Eso es muy distinto de entregarle a algo una API key y un permission set y confiar en que se mantenga dentro de los límites. Salesforce además puso el acceso MCP detrás de su propio scope de OAuth, así que concederlo no da acceso a las APIs REST existentes.

Las preguntas que nos hicieron cuando lo mostramos

Construimos un prototipo para una organización de formación y educación que quería ver cómo funcionaba esto con sus propios datos: una conexión de solo lectura a un sandbox y un cliente de IA haciendo preguntas sobre sus datos de Salesforce en lenguaje natural. Deliberadamente sin glamour. Tomó una tarde.

La demo no fue lo interesante. Lo interesante fue lo que preguntó la sala después de verlo funcionar, porque las preguntas fueron más agudas que las que suelen aparecer en esta etapa. Las cuatro vale la pena tomarlas prestadas.

“¿Qué puede ver exactamente, y cómo lo limitamos?” Surgió al cabo de un minuto, más o menos, y es la primera pregunta correcta. No qué puede hacer. Qué puede ver. Todo lo demás se desprende de esa respuesta: qué objetos, qué campos, qué registros, y si esos límites los aplica la plataforma o solo están escritos en algún lado con la esperanza de que se cumplan.

“¿Cómo le enseñamos nuestro vocabulario?” Sus programas, sus etapas, su definición de quién cuenta como activo. Un modelo que entiende Salesforce de forma genérica no sabe qué quiere decir tu organización con ninguna de esas palabras. Creemos que esta es la pregunta que mejor predice si un despliegue termina siendo útil, porque una respuesta técnicamente correcta expresada con el vocabulario equivocado sigue siendo una respuesta equivocada, y lo es de una manera difícil de notar. El mecanismo es inyectar tus definiciones como contexto, junto con las reglas sobre lo que el asistente nunca debe hacer.

“¿Podemos empezar en solo lectura?” Lo plantearon ellos mismos, antes de que lo sugiriéramos. Vale la pena anotarlo, porque se suele asumir que los clientes presionan por acceso de escritura mientras el partner frena. En nuestra experiencia muchas veces es al revés, y esa cautela está mejor informada de lo que la gente cree.

“¿A dónde van las respuestas?” La que no anticipamos. Una respuesta que se queda en una ventana de chat sirve exactamente una vez. La pregunta de fondo era sobre los resultados: si una respuesta puede terminar en un documento, en una hoja de cálculo, en un reporte que lee otra persona, o adjunta al registro del que salió. Es una pregunta justa, muchas veces marca la diferencia entre una demo que la gente disfruta y una herramienta que la gente usa, y cambia lo que decides construir.

Ninguna de estas preguntas es sobre el protocolo. Las cuatro son sobre alcance, lenguaje y flujo de trabajo, que es justamente el punto.

El trabajo se movió, no desapareció

Esta es la parte que querríamos que un cliente escuchara antes de firmar nada.

El esfuerzo que antes se iba en construir y mantener una integración no se evaporó. Se movió hacia el principio, a decisiones que antes se tomaban de forma implícita y ahora hay que tomar de forma explícita:

• Qué objetos y campos deberían ser accesibles, con nombre y apellido, no por suposición.
• Si tus permission sets reflejan de verdad lo que la gente debería ver hoy, o lo que alguien configuró en 2021.
• Qué significan tus términos de negocio, con la precisión suficiente para que un asistente que responde en lenguaje natural no cree tres versiones de la verdad.
• Si el asistente debería manipular registros directamente o llamar a tus flujos y acciones existentes.
• Qué debería poder modificar, si es que algo, y qué tiene que quedarse en solo lectura.

Ninguna de estas preguntas es difícil. Pero son preguntas que un proyecto de middleware te permitía postergar seis meses. Ahora llegan el primer día, lo cual es mejor, pero solo si alguien está preparado para ellas.

Por eso los proyectos que salen mal rara vez son los que chocan con un muro técnico. Son aquellos en los que la conexión funcionó de inmediato, nadie había decidido qué se debía exponer, y el alcance creció por inercia hasta que alguien de la dirección hizo una pregunta incómoda.

Lo que cambia Claudeforce, y lo que no

Mientras terminábamos este artículo, Salesforce y Anthropic anunciaron Claudeforce (26 de agosto de 2026). Vale la pena tratarlo directamente, porque es lo más grande que ha pasado en este espacio desde la disponibilidad general de abril, y porque refuerza el argumento anterior en lugar de contradecirlo.

Lo principal es Salesforce in Claude, un plugin con 37 habilidades de ventas ya construidas que cubren la preparación de reuniones, la revisión de la salud de una oportunidad y la revisión del pipeline. Un administrador lo conecta una vez, los permisos se administran de forma centralizada y todos los vendedores del equipo tienen acceso desde el primer día. Claude también pasa a ser un modelo de razonamiento dentro de la plataforma de agentes de Salesforce, y el modelo predeterminado en Slack. Sales Cloud in Claude abrió las solicitudes de beta en Dreamforce, el 15 de septiembre de 2026, después de un piloto que incluyó a Deloitte, GitLab y Legora. El acceso se solicita a través de AgentExchange y las solicitudes aprobadas reciben instrucciones de activación.

El detalle que conviene notar es cómo describe Salesforce la infraestructura de fondo. El anuncio le atribuye ese papel a AIforce, la capa que lleva los datos y los flujos de trabajo del negocio a cualquier agente, en palabras de la propia Salesforce, “through MCP servers, APIs, and CLI tools” (a través de servidores MCP, APIs y herramientas de línea de comandos). El protocolo del que trata este artículo es la base sobre la que funciona el producto empaquetado.

¿Qué cambia, entonces? Para los equipos de ventas que trabajan dentro de Claude, buena parte de la configuración que describimos aquí ahora viene hecha. Es realmente útil y no vamos a fingir lo contrario. Si tu caso de uso es ventas y tu gente ya vive en Claude, la beta está abierta a solicitudes y vale la pena pedirla.

Lo que no cambia es todo aquello de lo que realmente trata este artículo. Las habilidades ya construidas cubren ventas, dentro de un cliente, en beta. Atención al cliente, finanzas, operaciones, tus objetos personalizados y tu propio vocabulario siguen siendo cosa tuya: te toca definirlos a ti. Y las decisiones son idénticas en ambos casos: qué objetos y campos deberían ser accesibles, si tus permission sets reflejan lo que la gente debería ver hoy, qué significan tus términos de negocio con la precisión suficiente para responder con ellos, y qué se queda en solo lectura. Esas cuatro, y las dos que solo importan cuando la escritura entra en juego, son las que trabajamos en guardrails de IA en Salesforce.

Instalar un plugin no te exime de esas decisiones. Te lleva bastante más rápido al momento en que ya tendrías que haberlas tomado.

Por dónde empezar

Si quieres averiguar cuánto vale Salesforce MCP en tu propia org sin comprometerte a nada, hay un camino de muy bajo riesgo.

Habilita el servidor platform/sobject-reads en un sandbox. Es de solo lectura, así que nada en tu org puede cambiar. Conecta un cliente de IA. Dáselo a tres o cuatro personas que conozcan bien tus datos y deja que hagan las preguntas que realmente tienen, durante dos semanas.

Vas a aprender tres cosas rápido: si las respuestas son lo bastante buenas para ser útiles, dónde se desarman tus datos o tus definiciones cuando se les pregunta de frente, y qué casos de uso inventa la gente que nadie puso en el alcance original. En nuestra experiencia, lo tercero suele ser lo más valioso, y nunca coincide con el caso de negocio que se escribió antes.

Después, y solo después, plantea la conversación sobre el acceso de escritura. Escribimos aparte sobre por qué la base, no el modelo, decide si la IA funciona en una org de Salesforce, y ese argumento se aplica aquí con más fuerza, no con menos, precisamente porque la barrera técnica ahora es muy baja.

Nuestra visión

Hay una versión de este momento que sale mal, y no se parece a un incidente de seguridad. Se parece a una docena de equipos que conectan cada uno un asistente a producción porque es fácil, nadie anota qué se expuso, y pasa un año de inconsistencias silenciosas antes de que alguien lo note.

También hay una versión que sale bien, y no es más cautelosa. Solo es más deliberada al principio. La misma tarde de configuración, precedida por una semana decidiendo qué debería ser accesible y qué significan tus términos.

Creemos que MCP es lo más relevante que le ha pasado a la integración con Salesforce en una década, y lo decimos aunque elimina trabajo por el que antes nos pagaban. La conexión ya no es la parte difícil. Es una buena noticia. Solo significa que la parte difícil ahora es la que siempre fue más importante.

Por si sirve de algo, esta es la idea detrás de PilotIQ, nuestro propio asistente que funciona dentro de Salesforce: la misma convicción de que lo que un asistente puede alcanzar importa más que lo inteligente que sea.

Fuentes

Todas las fuentes están en inglés.

• Salesforce Newsroom, Salesforce and Anthropic Announce Claudeforce (26 de agosto de 2026). Alcance de la alianza, el plugin Salesforce in Claude y disponibilidad.
• Salesforce Developers, Salesforce Hosted MCP Servers Are Now Generally Available (29 de abril de 2026). Anuncio de disponibilidad general, modelo de seguridad y pasos de configuración.
• Salesforce Developers, Hosted MCP Servers documentation. Servidores preconfigurados, Named Queries y configuración de servidores personalizados.
• Salesforce Developers, Expose Custom Apex as a Hosted MCP Tool for Agents (mayo de 2026).
• Model Context Protocol. La especificación del estándar abierto.