Claude dentro do seu org: como configurar o MCP Server hospedado pela Salesforce
Um passo a passo direto para conectar Claude ao Salesforce via OAuth, sem servidor local e sem abrir mão de sharing rules e FLS
Com o MCP Server hospedado pela Salesforce saindo de beta no TDX 2026, dá para plugar Claude direto no seu org e deixar ele consultar registros, montar relatório e até disparar Flow em linguagem natural. Mostro o setup completo, do External Client App até o teste final, e onde isso costuma quebrar em projeto real.
Todo cliente que já brincou com ChatGPT ou Claude em algum momento pergunta a mesma coisa: "por que eu não posso simplesmente perguntar isso pro meu Salesforce?". Até pouco tempo, a resposta envolvia MuleSoft, uma API customizada, um dev disponível e paciência. Com o MCP Server hospedado pela Salesforce (Model Context Protocol) saindo de Generally Available no TDX 2026, essa distância diminuiu bastante.
MCP é um protocolo aberto que padroniza como uma IA conversa com sistemas externos. Em vez de cada ferramenta (Claude, ChatGPT, Cursor) precisar de um conector proprietário para cada sistema, o Salesforce expõe suas capacidades uma vez como servidor MCP, e qualquer cliente compatível se conecta. O ponto que interessa para quem vive de arquitetura: o modelo de segurança nativo continua valendo. Field-level security, sharing rules, permissões de usuário, tudo isso é respeitado. Você não está abrindo um buraco na governança, está adicionando uma porta de entrada conversacional em cima do que já existe.
Pré-requisitos
Antes de sair configurando, confirme três coisas: você precisa de permissão para criar External Client App no Setup, o usuário que vai autenticar precisa ter os perfis/permission sets corretos para os objetos que o MCP vai expor, e você precisa decidir, com calma, qual servidor MCP ativar. Isso importa porque o Salesforce já vem com servidores padrão prontos, mas inativos por default: sobject-all dá acesso amplo de leitura e escrita (11 tools, 2 prompts), enquanto sobject-reads e sobject-mutations separam isso em only-read e only-write. Comece pelo mais restrito que resolve seu caso, não pelo mais permissivo.
Passo 1: criar o External Client App
O Salesforce precisa saber que o Claude tem permissão para bater na porta. Isso se faz com um External Client App:
- No Setup, procure External Client App Manager e crie um novo. Dê um nome claro, tipo "Claude MCP Client App", e informe um e-mail de contato.
- Expanda a seção API e habilite OAuth Settings. Configure a callback URL como
https://claude.ai/api/mcp/auth_callbacke adicione os scopesmcp_api,refresh_token,offline_access. - Marque as opções: exigir secret para Refresh Token Flow, exigir PKCE nos fluxos de autorização suportados, e emitir access tokens baseados em JWT para usuários nomeados.
- Em Policies, vá em OAuth Policies, defina Permitted Users como "All users may self-authorize" e relaxe as restrições de IP.
- Em Settings, anote o Consumer Key e o Consumer Secret. Você vai precisar dos dois no lado do Claude.
Passo 2: ativar o servidor MCP
Agora você decide quais ferramentas o Claude pode efetivamente usar. Dá para partir de um servidor padrão ou montar um customizado, agregando Apex actions, Apex REST, métodos AuraEnabled, Connect API, Flows e Named Query API. Para um primeiro teste, ative o sobject-all e copie a URL do servidor, você vai usá-la no Claude.
Passo 3: conectar o Claude
Essa parte acontece inteiramente do lado do Claude, não no Salesforce:
- Acesse o Claude.ai, clique em Customize na barra lateral e depois em Connectors.
- Clique em Add, depois em Add custom connector, e dê um nome, como "Salesforce MCP".
- Cole a Server URL que você copiou no passo anterior.
- Em Advanced Settings, informe Client Key e Client Secret (o Consumer Key/Secret do External Client App).
- Clique em Connect. O Claude vai pedir login no Salesforce, siga o fluxo OAuth normalmente.
Passo 4: testar
Com a conexão feita, pergunte algo em linguagem natural. Na primeira interação, o Claude pede permissão para usar o conector, escolha "Always allow" para não repetir isso toda hora. A partir daí ele responde com base nos dados reais do seu org, pode gerar visualizações a partir do resultado de uma query, e, dependendo do servidor ativado, criar registros. Um detalhe interessante: ao criar uma Account com um Contact relacionado, o próprio Claude sinalizou risco de duplicidade antes de confirmar a criação, o que mostra que ele está lendo o contexto do org, não só executando comandos cegos.
Isso muda o cálculo de custo de integrações conversacionais. Antes, expor Salesforce para um assistente de IA exigia camada de API, autenticação customizada e manutenção contínua. Agora é configuração declarativa: External Client App, ativação de servidor, conexão OAuth. Para arquitetos, o ponto crítico é que a governança de segurança do Salesforce continua no comando, FLS, sharing rules e profile decidem o que o Claude vê e faz, o que reduz bastante o risco de
Testei o fluxo descrito com base em documentação e comportamento padrão do recurso; a experiência pode variar dependendo da org, do release habilitado e de customizações do Setup do cliente. Vale validar em sandbox antes de qualquer rollout em produção.
Se você é consultor ou arquiteto, comece testando isso em uma sandbox com um servidor restrito (sobject-reads) antes de liberar qualquer coisa com escrita. Documente exatamente quais scopes, perfis e permission sets estão envolvidos, porque quando o cliente perguntar "o que o Claude pode fazer no meu org", a resposta correta é "exatamente o que você permitiu através de FLS e sharing", não "tudo". Isso também é uma ótima porta de entrada para conversas sobre Agentforce, já que a lógica de exposição de ferramentas (Apex actions, Flows, Named Query API) é a mesma usada em agentes internos.
O ponto mais perigoso aqui é a tentação de ativar sobject-all direto em produção porque "é mais rápido". Isso é decisão de arquitetura, não conveniência de setup. Também vale lembrar que o Claude vai operar com o contexto e as permissões do usuário autenticado, então um usuário com acesso amplo demais no org vira um Claude com acesso amplo demais. Antes de expor qualquer MCP Server, revise permission sets e sharing rules como se estivesse abrindo uma nova Experience Cloud para o público.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.