Headless 360 MCP Server: quando o Setup deixa de ser tela e passa a ser skill
Salesforce coloca em Beta um servidor MCP que transforma tarefas de admin em ações que um agente executa sozinho, respeitando FLS, sharing rules e permission sets. Vale entender antes de liberar acesso.
O Headless 360 MCP Server entrou em Beta em julho com cerca de 100 skills, a maioria focada em Setup. A ideia não é mais expor cada API como uma tool isolada, mas dar ao agente quatro operações (Discover, Describe, Dispatch e Dispatch Read Only) para ele descobrir e executar tarefas que hoje exigem múltiplos cliques no Setup. Isso muda a forma como pensamos governança de acesso em projetos com IA.
Toda vez que um cliente me pergunta "dá para o agente criar usuário, resetar senha e atribuir permission set sozinho?", minha resposta sempre foi a mesma: dá, mas alguém decidiu terceirizar governança para um prompt. Pois bem, a Salesforce acabou de formalizar isso como produto, e formalizou de um jeito mais interessante do que eu esperava.
O Headless 360 MCP Server entrou em Beta no começo de julho. Ele é a evolução dos hosted MCP servers que ficaram GA em abril, só que em vez de expor cada funcionalidade da plataforma como uma tool MCP separada (o que rapidamente vira um pesadelo de contexto para o modelo, imagine um LLM tendo que escolher entre milhares de descrições de tool antes de agir), a Salesforce resolveu o problema de um jeito mais elegante: quatro tools fixas que servem de porta de entrada para uma biblioteca de skills que cresce por trás.
As quatro tools que fazem tudo funcionar
Esse é o ponto que separa esse lançamento de "mais um MCP server bonito" e o transforma em decisão de arquitetura de verdade:
- Discover: recebe a interpretação do agente sobre o que você pediu e faz busca semântica num índice vetorial com todas as APIs e skills disponíveis. Retorna candidatos ranqueados, sem o agente precisar varrer tool por tool.
- Describe: traz o contrato técnico da skill escolhida, parâmetros, dependências e a ordem dos passos. É aqui que o agente confirma se o Discover acertou e entende o que precisa fazer antes de agir.
- Dispatch: executa a skill de fato, roteando para o endpoint certo e aplicando os guardrails de acesso do usuário antes de qualquer chamada.
- Dispatch Read Only: mesma lógica do Dispatch, mas restrita a operações de leitura, útil quando você quer deixar o agente explorar sem risco de escrita.
Essa separação entre descobrir, descrever e executar é o que evita o problema clássico de context window: o modelo não precisa carregar milhares de descrições de tool na memória, ele navega pelo índice, confirma o contrato e só então dispara a ação.
O que já está liberado (e por que começa pelo Setup)
A Beta chegou com cerca de 100 skills, e a maioria mira operações de Setup para admin, essencialmente estendendo para clientes MCP headless o que o Agentforce for Setup já fazia dentro do próprio Salesforce. Alguns exemplos de tarefas de alto volume que já funcionam:
- Gestão de usuários: criar, desativar, congelar e descongelar, resetar ou definir senha, atribuir permission sets e permission set licenses. Basicamente toda a superfície que hoje você acessa manualmente na página de detalhe do usuário.
- Gestão de Apex triggers: ler, escrever e fazer deploy de triggers.
- Integrações orientadas a evento: definir platform events, configurar Change Data Capture e gerenciar event relays.
- Named credentials: definir mecanismo de autenticação, endpoint e tratamento de certificado.
O exemplo que a própria Salesforce usa para ilustrar o fluxo completo é bom: pedir ao agente para "planejar uma integração que envia eventos para a AWS quando um registro de Account é atualizado". Hoje isso significa navegar por pelo menos três páginas diferentes de Setup, entender a ordem de dependência (o named credential precisa existir antes do event relay) e configurar cada peça manualmente. Com o Discover, Describe e Dispatch, o agente resolve a sequência inteira, incluindo a parte de saber que uma coisa depende da outra.
Durante a Beta, a promessa é expandir para skills específicas de cada nuvem, cobrindo também tarefas de usuário de negócio, não só admin. E o volume prometido é grande: milhares de skills novas estão sendo criadas por trás dessas quatro tools.
A parte que interessa para quem desenha arquitetura
Aqui está o detalhe que separa curiosidade de decisão de projeto: toda transação do MCP Server rodando de forma hosted acontece como o usuário autenticado, através de um External Client App com o scope mcp_api. Isso significa que CRUD, FLS, sharing rules, permissões de profile e permission sets se aplicam integralmente. Se o usuário não pode fazer algo dentro do Salesforce, o agente não consegue fazer isso através do MCP server. E o audit trail atribui a ação a você, não a uma entidade genérica de "agente".
Ou seja: não existe bypass de segurança por trás da mágica. O que existe é uma nova superfície de execução que herda exatamente o modelo de acesso que você já configurou. Isso é ótimo, porque significa que toda a base de trabalho de arquitetura de segurança que você já fez (role hierarchy bem desenhada, sharing rules sem gambiarra, profiles enxutos) continua valendo. E é péssimo se essa base estiver mal feita, porque agora um agente vai executar em escala tudo que um perfil mal configurado permite.
Para quem vive projeto, isso muda a pergunta que você faz antes de ativar qualquer coisa relacionada a IA agentiva. Não é mais "o agente pode fazer isso?", é "o usuário por trás desse token tem permissão pra fazer isso, e eu confio na minha própria governança de permission set o suficiente para deixar um agente operar nesse nível?". Times que já vinham empurrando problema de FLS mal configurada para debaixo do tapete vão sentir o esse acúmulo de dívida técnica na cara, só que agora em velocidade de agente, não de humano clicando devagar.
Também muda o discurso comercial com o cliente que quer Agentforce antes de arrumar a casa. Setup automatizado por agente é sedutor, mas só funciona bem em org com modelo de dados e de acesso maduro. Vender isso para quem ainda tem profile genérico dando acesso a tudo é dar corda para o próprio problema.
Este é um recurso em Beta, então espere instabilidade, mudança de comportamento e expansão de skills nas próximas semanas. Trate qualquer teste como exploração em sandbox, não como decisão definitiva de arquitetura ainda.
Se você é admin ou arquiteto, o primeiro passo não é ativar o servidor, é auditar profiles, permission sets e sharing rules do usuário que vai autenticar as chamadas MCP. Faça isso antes de qualquer coisa, porque o agente herda exatamente esse nível de acesso.
Depois, teste em sandbox pedindo tarefas reais e repetitivas do seu backlog de Setup (criação de usuário em massa, configuração de named credential, ajuste de permission set) e observe se o Discover está trazendo a skill certa antes de confiar no Dispatch. Configure o tool-level approval no seu cliente MCP para exigir confirmação manual em cada execução até você ganhar confiança no comportamento, principalmente se quem vai operar tiver permissão ampla no org.
Cuidado com o efeito "parece mágica, então deve estar tudo certo". O fato de o agente respeitar FLS e sharing rules não significa que sua governança atual está adequada para automação em escala, só significa que os buracos que já existem vão ser explorados mais rápido.
Outro ponto de atenção: essa é uma Beta com cerca de 100 skills hoje, cobrindo majoritariamente Setup. Não espere paridade com todos os fluxos de Revenue Cloud, CPQ ou Billing ainda. Se seu caso de uso é de negócio e não de admin, monitore a evolução antes de prometer isso em proposta de projeto.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.