Un MCP server que le da a Claude acceso scoped de lectura y escritura a Salesforce, con tiers de permisos, audit logging y un cap duro sobre escrituras en bulk. Ponlo frente a Claude Code o Claude.ai y tu equipo puede preguntar “muéstrame todos los deals atorados sobre cincuenta mil y actualiza sus close dates” sin salir del chat.

Lo que vas a necesitar

Una Connected App de Salesforce con scopes de API y refresh-token
Un host que pueda correr un proceso de larga duración (Node, Python o el container de tu elección)
Claude Code, Claude Desktop o cualquier cliente compatible con MCP
Un doc de política de permisos acordado con tu equipo de seguridad

Setup

Levanta el server. La implementación de referencia es un MCP server en Node con tres familias de herramientas: query, read_record y write_record. Clona, instala, configura las variables de entorno con las credenciales de la Connected App.
Define la política de permisos. Un archivo YAML lista qué objetos son legibles, qué campos son escribibles y qué operaciones requieren un paso de confirmación explícita. La política por defecto es solo lectura. Las escrituras requieren un allowlist.
Agrega el server a tu cliente MCP. En Claude Code, agrega una entrada en tu config de cliente apuntando al proceso local. El server anuncia sus herramientas al arrancar.
Conecta el audit logging. Cada llamada a herramienta produce una entrada de log estructurada: usuario, herramienta, argumentos, hash del resultado. Pipe a tu stack de logging de elección. Esto es no negociable para operaciones de escritura.
Prueba primero con solo lectura. Corre “muéstrame mi pipeline” antes que “actualiza cincuenta deals”. La confianza viene de unas semanas de operación en solo lectura.

Cómo funciona

El MCP server traduce llamadas de herramienta de Claude en queries SOQL y llamadas REST a Salesforce. Las lecturas pasan por el filtro de política y devuelven JSON. Las escrituras pasan por un paso de confirmación: el server devuelve un preview “qué haría”, Claude lo muestra al usuario, el usuario confirma, el server hace commit.

Las escrituras en bulk son especiales. El server pone un cap duro sobre cualquier operación de update a veinticinco registros por defecto. Operaciones más grandes requieren una herramienta bulk_write separada que está apagada por defecto y solo se habilita para identidades de usuario específicas.

Cuídate de

El audit logging es obligatorio. Si una herramienta de escritura corre sin una entrada de log correspondiente, el server debe fallar cerrado. No hagas ship sin este guard.
Drift de field-level security. Los permisos de Salesforce cambian. El archivo de política del server puede salirse de sincronía. Corre un job semanal que haga diff de la política contra la FLS actual y alerte sobre mismatches.
Rotación de tokens. Los refresh tokens expiran. Construye el flujo de rotación antes del lanzamiento, no después del primer 401.
UX de confirmación. El preview “qué haría” debe ser inequívoco. “Actualiza cincuenta deals” no es suficiente; muestra los IDs y el diff a nivel de campo.

Stack

Salesforce — sistema de registro
MCP server — capa de traducción, política y auditoría
Claude — interfaz de lenguaje natural, llamador de herramientas