Servidor MCP do Salesforce: ferramentas, permissões e como conectá-lo com segurança

O que é o servidor MCP do Salesforce

OServidor MCP do Salesforce transforma seu CRM em ferramentas chamáveis. Model Context Protocol é o padrão aberto que permite que um agente de IA descubra e invoque ferramentas em um sistema externo; a implementação do Salesforce expõe sObjects padrão e personalizados por meio dele.

O que o diferencia da maioria servidores MCP remotos é onde ele é executado: o Salesforce hospeda seus servidores MCP de dentro da sua organização, ativado por meio do pacote gerenciado TrueFoundry Salesforce — sem terceiros no meio, sem necessidade de configurar um aplicativo OAuth.

O que você ativa determina o que os agentes podem acessar:

Esses dois se resumem à única decisão que importa: este agente precisa alterar registros ou apenas lê-los? A aba Servidores Salesforce na Configuração lista o que sua edição pode ativar. [VERIFICAR] Se variantes além dessas duas aparecem lá, não está documentado.

Dentro de qualquer servidor, a superfície é o seu modelo de dados. A documentação descreve as ferramentas por capacidade e tipo de objeto, em vez de publicar nomes de funções fixos, portanto, a aba Ferramentas na página de detalhes do servidor é o inventário real da sua organização.

O que os agentes realmente fazem com ele

Os fluxos de trabalho úteis encadeiam leituras e, ocasionalmente, escritas:

• Revisão de pipeline. Consulte oportunidades em aberto acima de um determinado valor, extraia as contas e contatos relacionados, faça o cruzamento com a data da última atividade e sinalize os negócios que ficaram parados.
• Pesquisa pré-chamada. Leia a conta, seus casos abertos, seu histórico de vendas fechadas e quaisquer objetos personalizados que contenham uso do produto, e então escreva um resumo de uma página.
• Triagem de casos. Agrupe os casos abertos por área de produto e severidade, destacando aqueles que estão ultrapassando as metas de resposta.
• Higiene de dados. Encontre registros duplicados ou incompletos e normalize os campos — este é o único caso aqui que requer sobject-all.

Três desses quatro são apenas de leitura, e esse é o padrão. A maior parte do que as equipes desejam de um servidor MCP de CRM é leitura. Portanto, leitura versus escrita não é um princípio abstrato aqui — é uma questão concreta respondida no momento da ativação, e a maioria dos agentes deve ficar no lado de somente leitura.

Por que a conexão direta falha em escala de equipe

Um analista de RevOps conectando o Salesforce ao Claude Desktop é aceitável. A mesma integração para trinta pessoas em vendas, suporte e finanças, não.

Um agente com acesso de escrita pode alterar os números que a diretoria vê. Valores de oportunidade, datas de fechamento e estágios compõem a previsão; campos de conta alimentam relatórios de território e ARR. Um agente que "limpa" um estágio ou exclui um suposto duplicado não vazou nada — ele corrompeu o sistema de registro com o qual o financeiro fecha o trimestre, e histórico sobrescrito não é um commit que se reverte. A injeção de prompt agrava isso: uma instrução plantada na descrição de um caso chega a um agente de triagem que possui as mesmas ferramentas de escrita que um agente de higiene de dados.

Um agente com acesso de leitura pode extrair todo o pipeline para o contexto de um modelo. Uma consulta ampla em Oportunidades retorna todos os negócios abertos, seus valores e seus proprietários — e, em uma conta de serviço compartilhada, essa consulta não é limitada pelas regras de compartilhamento de ninguém. Sua previsão se torna um prompt.

Credenciais compartilhadas apagam o próprio modelo de permissão do Salesforce. Perfis, conjuntos de permissões, segurança em nível de campo, regras de compartilhamento — as equipes passam anos ajustando isso. Então, uma integração se autentica com uma credencial de nível administrativo, cada solicitação herda privilégios de administrador e todo esse trabalho é perdido.

Sem atribuição quando algo muda. O histórico de campo informa que um registro foi alterado e qual usuário o alterou — não que um agente o alterou com base em um prompt de uma thread do Slack.

Nada disso é um argumento contra conectar o Salesforce. É um argumento a favor de um plano de controle à frente dele — que é para o que um gateway de MCP serve.

Want to see this end to end?

Spin up a TrueFoundry account, activate the read-only Salesforce server, and hand your team a governed CRM agent in an afternoon.

Get started free

Antes de começar: o que o lado do Salesforce exige

Como o servidor reside na sua organização, esta integração possui pré-requisitos reais, ao contrário da maioria dos MCPs gerenciados.

• Uma conta TrueFoundry com permissão para adicionar servidores MCP.
• Administrador do Salesforce acesso — você está instalando um pacote e alterando as Configurações.
• Uma edição da organização com acesso à API habilitado: Developer, Enterprise ou Professional Edition com acesso à API ativado.

Reserve cerca de dez minutos, a maior parte do tempo será aguardando a instalação e a ativação.

Conectando o servidor MCP do Salesforce através da TrueFoundry

A TrueFoundry provisiona o Salesforce como um MCP Gerenciado pela TrueFoundry: a plataforma detém a URL do servidor, autenticação de saída, escopos e credenciais, mantendo-os atualizados conforme o Salesforce os altera:

Como o servidor é seu, o Salesforce adiciona três etapas do lado da organização antes disso.

Etapa 1 — Instale o pacote MCP do Salesforce da TrueFoundry. Faça login na sua organização como Administrador e, em seguida, abra o link de instalação na mesma sessão do navegador:

https://login.salesforce.com/packaging/installPackage.apexp?p0=04ta7000001FUejAAG

Na tela de instalação, escolha Instalar para todos os usuários, clique emInstalar, e aguarde a confirmação de sucesso.

Passo 2 — Habilite o Serviço MCP. Em Configuração, pesquise Interface do Usuário na Busca Rápida, encontre Habilitar Serviço MCP, ative-o e Salvar.

Passo 3 — Ative o servidor MCP. Ainda em Configuração, pesquise Servidores MCP e abra a aba Servidores Salesforce . Encontre o servidor desejado — sobject-all para leitura/gravação completa, sobject-reads para apenas leitura — e clique em Ativar; pode levar até dois minutos. Leia a próxima seção antes de escolher.

Passo 4 — Conecte no TrueFoundry. Vá para Servidores MCP, encontre Salesforce MCPe clique em Conectar. Você será redirecionado para uma tela de login e consentimento do Salesforce: faça login, revise as permissões solicitadas e clique em Permitir.

Passo 5 — Verificar. O servidor deve exibir Conectadoe oFerramentas a aba deve listar suas ferramentas. Clique em Testar em qualquer ferramenta, ou execute algo como “list all accounts”, para confirmar a comunicação de ida e volta.

Observe o que você fez não fazer: sem External Client App, sem Connected App, sem Client ID ou Secret, sem escopos OAuth, sem URL de retorno.

Como a autenticação realmente funciona

O TrueFoundry separa aautenticação de entrada— como um cliente se autentica no gateway — daautenticação de saída, como o gateway se autentica no Salesforce.

Entrada — os clientes se autenticam no AI Gateway com uma das seguintes opções:

Uma ressalva é mais importante aqui do que na maioria dos servidores: um token de Conta Virtual concede acesso idêntico a todas as solicitações, portanto, não pode oferecer suporte à visibilidade de CRM por usuário. Use um PAT ou o fluxo OAuth da IDE para conexões de entrada.

Saída — o Código de Autorização OAuth2 fluxo. Cada usuário autoriza sua própria conta Salesforce; a TrueFoundry gerencia o consentimento, o armazenamento de tokens e a atualização. Como um MCP gerenciado, o URI de redirecionamento é sempre o callback gerenciado centralmente pela TrueFoundry:

https://auth.truefoundry.com/mcp/oauth2/callback

É isso que torna a proposta do Salesforce robusta. Como a identidade de saída é o usuário individual, cada ação é executada como esse usuário autenticado e respeita as permissões de CRUD, a segurança em nível de campo e as regras de compartilhamento da sua organização. O representante cujo perfil não consegue ver campos exclusivos de Finanças? O agente dele também não consegue. O agente de suporte limitado a uma região? O agente dele vê apenas uma região.

Seu modelo de permissão não é ignorado, duplicado ou aproximado no gateway — ele é a camada de imposição, porque o Salesforce avalia cada chamada como um usuário real. Os usuários se autenticam duas vezes, uma no gateway e outra no Salesforce, e é isso que torna possível a atribuição por usuário.

Escolhendo somente leitura na origem

A maioria dos servidores MCP oferece um único lugar para restringir recursos: o gateway. O Salesforce oferece dois, e o upstream é mais forte.

Ativar sobject-reads em vez de sobject-all significa que as ferramentas de gravação e exclusão não existem no servidor com o qual seu gateway se comunica. Não estão desativadas, não estão bloqueadas — estão ausentes. Não há opção para configurar incorretamente mais tarde, nenhum colaborador que possa reativá-las, nenhuma versão upstream que adicione silenciosamente uma ferramenta de gravação.

• Use sobject-reads como padrão. Relatórios de pipeline, resumos de contas, triagem de casos, resumos de previsão, agentes de pesquisa — nenhum deles grava dados.
• Ative sobject-all apenas quando um fluxo de trabalho exigir gravações, e combine isso com as opções e políticas de aprovação abaixo.

Se você já ativou o sobject-all, desativar as ferramentas de gravação e exclusão na aba Ferramentas oferece o mesmo comportamento — é apenas um controle que você precisa manter intacto.

Delimitando ferramentas antes da implementação

Uma vez conectado, a aba Ferramentas lista tudo o que o servidor ativo expõe.

Alternâncias por ferramenta. Desative uma ferramenta e ela será omitida da lista de ferramentas (tools/list) completamente — os clientes nunca a verão e ela não poderá ser invocada. Isso não é filtragem na camada de prompt: um agente que não consegue ver uma ferramenta de exclusão não pode ser convencido a chamá-la, independentemente do que uma descrição de caso maliciosa diga.

Habilitar novas ferramentas por padrão. Esquerda sobre, novas ferramentas upstream aparecem automaticamente. Desativado desativado, apenas as ferramentas que você habilitou explicitamente ficam disponíveis e qualquer novidade permanece oculta até que você a aprove. Para um sistema de registro, desativado é o padrão correto.

Ação em lote. Alterna todas as linhas para caixas de seleção com Selecionar tudo, para que você possa alterar um grande conjunto de uma só vez e Salvar.

Clique no lápis em qualquer ferramenta para alterar como ela é apresentada ao modelo:

ODescrição a substituição (até 20.000 caracteres) orienta a seleção da ferramenta quando a redação upstream é ambígua. Anotações de ferramenta MCP marca uma ferramenta Somente leituraouDestrutivo, definindo readOnlyHint ou destructiveHint — e marcar as ferramentas de escrita como Destrutivas é o que permite que as políticas de aprovação abaixo controlem toda uma classe de operações de uma só vez.

Quem pode fazer o quê: funções de colaborador

O controle de acesso é vinculado a usuários, equipes ou contas virtuais em duas dimensões: quais servidores uma identidade pode acessar e quais ferramentas ela pode invocar.

Para um CRM, a divisão natural é RevOps como Gerente, vendas e suporte como Usuário, e um líder de operações de vendas como Aprovador no caminho de escrita — o mesmo Controle de acesso MCP modelo usado por qualquer outro servidor no registro.

Ready to scope your first server?

Activate sobject-reads, add your team as Users, and ship a read-only CRM agent today.

Start free on TrueFoundry

Aprovação humana para ferramentas de escrita

Desativar escritas é uma medida drástica e, para a maioria dos agentes do Salesforce, é a abordagem correta. Mas alguns fluxos de trabalho precisam realizar escritas — como registrar atividades, avançar uma etapa ou criar uma tarefa — e você quer que isso aconteça sob supervisão humana.

Quando uma ferramenta restrita é chamada, a chamada é suspensa em vez de executada, uma solicitação de aprovação é criada e os aprovadores são notificados. Após a aprovação humana, as chamadas são bem-sucedidas por um período configurável, sendo necessária uma nova aprovação após esse tempo. Crie uma política em AI Gateway → Policies → MCP Tool Approval (marcado como Beta no console):

Cada política nomeia os servidores que ela restringe e escolhe um escopo de aprovação:

É aqui que as anotações valem a pena: marque as operações de escrita como Destructive uma vez e restrinja a classe com approval_scope: destructive. Quando os escopos se sobrepõem, o mais específico prevalece — nomeado > destrutivo > todos.

Validade é definida como Uma vez (uma única execução) ou baseada em tempo, uma duração em minutos. Quando as políticas entram em conflito, a mais restritiva prevalece: Única vence 10 minutos, que vence 30. Para qualquer coisa que envolva registros de oportunidades ou contas, escolha Uma vez — uma concessão de 30 minutos em uma ferramenta de escrita são 30 minutos nos quais um agente pode realizar um loop.

Os aprovadores são notificados por e-mail, Slack, PagerDuty ou MS Teams e realizam a análise no console:

Cada solicitação exibe a ferramenta, a política, o solicitante, a janela de validade e os argumentos reais da ferramenta — assim, um aprovador pode ver que um agente deseja definir uma oportunidade de US$ 400 mil como "Fechada Perdida" antes de autorizá-la. Essa visibilidade é o valor principal do recurso em um CRM.

Enquanto pendente, o solicitante recebe um resultado JSON-RPC bem-sucedido contendo _meta.approval_status: "pending" em vez de um erro, para que um agente bem configurado aguarde e tente novamente. As permissões são definidas por solicitante, e uma negação não bloqueia ninguém permanentemente — a próxima chamada gera uma nova solicitação.

Testando no Playground de Ferramentas

Experimente as ferramentas manualmente primeiro. Na página de detalhes do servidor, clique em O botão Testar ao lado de qualquer ferramenta, forneça as entradas — o tipo de objeto, como Conta ou Oportunidade, além de quaisquer filtros de consulta — clique em Executar Ferramentae leia o JSON. O botão Testar fica desativado para ferramentas que você desativou. Isso detecta falhas simples antecipadamente: um campo que seu perfil não consegue ler, um objeto que o pacote não expôs ou um formato de filtro que você previu incorretamente.

Usando a partir da sua IDE

Abra a aba Como Usar para obter a URL do Gateway específica do seu tenant e trechos de código prontos para copiar.

Ele abrange Claude Code, VS Code, Claude Web, Claude Desktop, Cursor, Windsurf, Codex e os SDKs MCP para Python e TypeScript; Exibir chave de API revela o token caso seu cliente precise dele em um cabeçalho. Utilize a URL desta aba em vez de montá-la manualmente — ela é específica do tenant, e um endpoint criado manualmente é a causa mais comum de clientes que se conectam, mas não listam ferramentas.

O que você obtém ao passar pelo gateway

Métricas em nível de ferramenta.OMétricas de Ferramentas a aba rastreia a contagem de invocações, latência por ferramenta e taxas de erro. Em todo o gateway, o MCP Metrics adiciona requisições por segundo, latência em P50/P75/P90/P99 e taxa de falha por tipo de erro.

Observabilidade completa da requisição. Cada chamada de ferramenta é rastreada com a identidade do chamador, nome da ferramenta, entradas e latência, exportando via OpenTelemetry para Grafana, Datadog ou Prometheus — algo que o histórico de campos da camada de atribuição, por si só, não consegue fornecer.

Diretrizes de segurança. Os hooks são aplicados em mcp_pre_tool, antes de uma ferramenta ser invocada, onde uma verificação pode bloquear a chamada imediatamente, e em mcp_post_tool, na resposta antes que ela retorne ao agente. O hook pós-ferramenta é o que importa para dados de CRM — é onde você intercepta um resultado que contém mais registros ou campos mais sensíveis do que deveriam chegar a um modelo.

Baixa sobrecarga. O gateway adiciona aproximadamente 3–4 ms de latência e processa mais de 350 RPS em uma única vCPU.

Um registro único. Assim que vários servidores são registrados, você pode expor um subconjunto curado de suas ferramentas atrás de um único endpoint com um Servidor MCP Virtual — assim, um agente de negociação obtém ferramentas de leitura do Salesforce, uma ferramenta do Slack para publicar o resumo e nada mais.

Revogando o acesso

Administradores do tenant podem apagar todas as credenciais armazenadas no servidor a partir do menu de três pontos ao lado de Editar:

Revogar todos os tokens exclui todas as substituições de autenticação e tokens OAuth armazenados para todos os usuários e contas virtuais nesse servidor, entra em vigor na próxima solicitação e é registrado nos Logs de Atividade. É irreversível e apenas administradores do tenant podem ver essa ação.

Uma limitação importante: isso limpa os tokens apenas no gateway e não revoga a concessão dentro do Salesforce. Em caso de incidente, desative o servidor na aba Servidores Salesforce também — esse é o botão que remove a capacidade, em vez da credencial.

Pontos de atenção importantes

O modo somente leitura é uma escolha de ativação, não apenas uma chave de alternância. O agente Salesforce somente leitura mais robusto é o sobject-reads ativado em sua organização, onde ferramentas de escrita nunca existem. Alternar o sobject-all no gateway é uma boa segunda linha de defesa, mas podem ocorrer desvios de configuração.

A segurança em nível de campo (FLS) é mais importante do que você imagina. Como cada chamada é executada como o usuário autenticado, uma ferramenta que "não funciona" para uma pessoa, mas funciona para outra, geralmente não está com defeito — é a FLS ou uma regra de compartilhamento funcionando corretamente.

Os limites de API são compartilhados. As chamadas de ferramentas do agente utilizam a mesma alocação de API da organização que seus trabalhos noturnos.

Leituras relacionadas

• O que é um Gateway MCP: Arquitetura e Casos de Uso — o guia arquitetural por trás desta publicação
• Controle de Acesso MCP: Protegendo Agentes de IA com um Gateway MCP — como as permissões em nível de ferramenta e de servidor funcionam na prática
• Autenticação MCP explicada — o modelo de autenticação de entrada e saída em detalhes
• Servidor MCP virtual explicado — agrupando ferramentas de vários servidores em um único endpoint
• Controle de acesso MCP corporativo — design de funções para grandes equipes

Conclusão

O servidor MCP do Salesforce é excepcionalmente adequado para ser governado corretamente, e excepcionalmente custoso se for configurado de forma errada. Adequado, porque ele é executado na sua própria organização e autoriza por usuário, de modo que o modelo de permissão que seus administradores já mantêm se torna o do agente. Custoso, porque os objetos do outro lado são aqueles nos quais sua previsão e o fechamento do trimestre são baseados.

Os controles são ordenados, e o primeiro é o mais simples: ative leituras de sobject a menos que um fluxo de trabalho realmente precise gravar. Em seguida, desative as ferramentas que você não usa e coloque o caminho de gravação sob a supervisão de um humano com Uma vez validade, e mantenha o registro de chamadas rastreadas.

Connect the Salesforce MCP server on TrueFoundry

Free to start