A Salesforce abriu o Beta do Headless 360 MCP Server em 14 de julho de 2026, exatamente 48 horas antes desta publicação. E aqui vai o que me chamou atenção: em vez de expor milhares de ferramentas MCP, eles optaram por apenas quatro. A escolha é contraintuitiva, mas o raciocínio por trás dela é o que torna este lançamento genuinamente diferente de tudo que veio antes no Summer ’26.
Este artigo é para quem já leu nosso texto sobre Hosted MCP Servers com Claude e ChatGPT e quer entender como o Headless 360 muda a conversa. São produtos diferentes, complementares, e tratá-los como se fossem a mesma coisa é um erro comum que vejo gente cometendo desde o anúncio.
A nova superfície da Salesforce para agentes de IA
A Salesforce vem empurrando a ideia de Headless 360 há meses. O conceito é simples de enunciar e trabalhoso de implementar: a plataforma inteira, com seus milhares de recursos, deve ficar acessível a partir de clientes MCP. Cursor, Claude Code, ChatGPT, Copilot, qualquer um deles poderia, em tese, configurar sua org, criar automações, gerenciar usuários, disparar eventos.
Na prática, expor cada recurso como uma ferramenta MCP separada cria um problema de escala. Um modelo de IA precisa raciocinar sobre o catálogo inteiro de tools antes de tomar uma ação. Cada tool description consome tokens. Cada decisão custa tempo. Some isso a uma plataforma que adiciona APIs novas todos os releases e o resultado é um beco sem saída.
O Headless 360 MCP Server responde a esse problema com uma escolha de design que eu só consegui apreciar depois de reler o anúncio do Tyson Read três vezes: a interface fica pequena e estável, e a superfície de ação escala por baixo.
Por que apenas quatro ferramentas, e não milhares
O time de produto liderou o raciocínio pelo avesso. Em vez de empurrar ferramentas individuais para cada capability de Salesforce, eles reduziram o ponto de contato a quatro operações fundamentais que cobrem todo o ciclo de uso:
- Discover: faz busca semântica em um índice vetorial de todas as APIs e skills geradas. Retorna candidatos ranqueados.
- Describe: puxa o contrato técnico de uma skill. Parâmetros, dependências, ordem de execução.
- Dispatch: executa a skill escolhida, roteando para o endpoint correto e aplicando as guardrails de permissão.
- Dispatch Read Only: idêntico, mas restrito a ações de leitura.
Por trás desses quatro pontos de entrada vive uma biblioteca de skills que continua crescendo. O agente vê quatro botões. A Salesforce mantém a casa inteira crescendo nos bastidores.
Isso é, na minha leitura, a primeira vez que alguém aplica o pattern de “small surface, big back end” de forma explícita a um MCP server corporativo. Vale observar como isso vai se sustentar quando o catálogo de skills passar de algumas centenas para os milhares prometidos.
A diferença que ninguém comenta: Hosted MCP x Headless 360 MCP
Vou repetir aqui porque o ponto é importante. Muita gente no LinkedIn está tratando os dois servidores como sinônimos. Não são.
| Aspecto | Hosted MCP Servers (Summer ’26) | Headless 360 MCP Server (Beta) |
|---|---|---|
| Estilo de exposição | Tools CRUD diretas por recurso (SObject, Data 360, Tableau) | Quatro tools genéricas sobre biblioteca de skills |
| Como o agente escolhe | Lista de tools explícita | Busca semântica por intenção |
| Customização | Você adiciona Apex @InvocableMethod, Flows, métodos @AuraEnabled | Você consome skills prontas; skills novas aparecem conforme a Salesforce publica |
| Quando usar | Quando você quer expor lógica de negócio sua para agentes externos | Quando você quer dar a um agente a capacidade de operar o Salesforce setup como um admin faria |
Se você já publicou Apex como ferramenta MCP no Hosted Server, mantenha. As duas superfícies convivem. O Headless 360 entra quando o requisito é “o agente precisa configurar a plataforma por mim, sem eu ter escrito a integração antes”.
Guardrails: o que impede um agente mal calibrado de quebrar sua org
Uma das partes que merecem destaque no anúncio do Tyson Read diz respeito a segurança. Toda transação do Headless 360 MCP roda como o usuário autenticado, com escopo mcp_api em um external client app. CRUD, FLS, sharing rules, permission sets, tudo se aplica.
Em outras palavras, se o seu usuário não pode fazer pela UI, o agente também não pode fazer pelo MCP server. O log de auditoria continua atribuindo as ações a você, com o nome do usuário humano no campo de quem executou.
Isso reduz, mas não elimina, o risco. O anúncio recomenda explicitamente que admins e developers configurem restrições a nível de tool no cliente MCP. A ideia é fazer o agente pedir aprovação humana cada vez que uma tool sensível for invocada. Em produção, eu ativaria isso desde o primeiro dia, mesmo durante o Beta. A chance de um modelo chamar Dispatch com os parâmetros errados é baixa, mas não é zero, e a chance de você descobrir o erro só depois do deploy é exatamente 100%.
Outro detalhe que me chamou atenção: a Salesforce recomenda mudanças de configuração primeiro em sandbox ou developer org. A frase está no meio do anúncio como se fosse óbvia, mas vale repetir. Beta é Beta. Sandbox é o lugar certo.
As ~100 skills do lançamento (e os milhares que estão vindo)
O Beta sai com aproximadamente 100 skills atrás do servidor. O objetivo público é chegar aos milhares durante o Beta, à medida que feature teams da Salesforce revisam e contribuem.
As áreas de maior tráfego de skills no lançamento:
- Gestão de usuários: criar, desativar, congelar, descongelar, resetar senha, atribuir permission sets e permission set licenses. Cobre a superfície completa do detail page de User.
- Gestão de Apex triggers: ler, escrever e deployar triggers. Esse ponto é o que me animou mais ao ler.
- Integrações orientadas a evento: definir platform events, gerenciar Change Data Capture e event relays.
- Named credentials: mecanismo de autenticação, endpoints e tratamento de certificado.
A Salesforce está usando IA interna para gerar boa parte dessas skills. Existe uma ferramenta interna chamada Headless 360 Factory que varre o Setup do Salesforce, identifica features que ainda não têm API, e gera APIs e skills sob medida. Os times de produto revisam, validam e contribuem com as suas.
Esse modelo me lembra o que a GitHub fez com o Copilot para código: a IA acelera a expansão do catálogo, humanos fazem o controle de qualidade. Resta saber se a qualidade se sustenta quando a fábrica estiver publicando milhares de skills por release.
Como ativar o Beta na sua org
A ativação é direta, mas convém fazer em sandbox primeiro.
- Acesse Setup no seu org.
- Navegue até a seção Salesforce Hosted MCP Servers.
- Localize o card Headless 360 na lista.
- Clique em Activate.
- Configure o external client app com o escopo
mcp_api. - Em um cliente MCP compatível (Claude Code, Cursor, Cline), aponte a configuração para o endpoint do seu org, usando OAuth Authorization Code para fluxos interativos ou JWT Bearer para cenários headless.
Estrutura mínima de configuração em um cliente MCP padrão:
{
"mcpServers": {
"salesforce-headless-360": {
"url": "https://sua-org.my.salesforce.com/services/mcp/headless360",
"auth": {
"type": "oauth",
"flow": "authorization_code",
"client_id": "SEU_CONNECTED_APP_CONSUMER_KEY",
"scopes": ["mcp_api", "api", "refresh_token", "offline_access"]
}
}
}
}Para o ambiente Headless, equivalente seria JWT Bearer com chave privada assinada pelo Connected App. A configuração em si não muda entre os dois cenários; o handshake inicial é que difere.
Depois de ativado, vale o teste mais simples: peça ao seu cliente MCP “liste as 10 últimas oportunidades perdidas no mês de junho com motivo de perda”. Se o agente conseguir percorrer Discover, Describe e Dispatch em menos de 5 segundos, a integração está saudável.
Um cenário real: agente configurando Change Data Capture e Event Relay sozinho
A Salesforce usou um exemplo no anúncio que vale reproduzir com mais detalhe, porque ele mostra bem o poder da nova superfície.
Imagine que você precise “planejar uma integração que envia eventos para AWS quando registros de Account mudarem”. Pelo método tradicional, são pelo menos três telas de Setup:
- configurar Change Data Capture para o objeto Account
- criar uma named credential apontando para o endpoint AWS
- configurar o event relay consumindo a named credential
Você, como admin, faria isso em dez minutos se já soubesse o caminho. Um agente MCP sem o Headless 360 faria isso em horas, navegando tentativa e erro.
Com o Headless 360, o agente começa invocando Discover para localizar as skills de Change Data Capture, Named Credentials e Event Relay. Em seguida, Describe para inspecionar os contratos de cada uma, incluindo a ordem em que precisam ser chamadas. Isso porque existe uma dependência: event relay precisa de named credential pré-existente. Sem essa ordem, a configuração quebra.
Por fim, Dispatch executa cada chamada na ordem correta. O resultado é uma integração funcional montada em segundos, com o agente tendo decidido o desenho e o humano só tendo aprovado o plano.
Eu testaria esse fluxo com integração para um S3 simples antes de mandar para produção. A sensibilidade aqui não é técnica, é de governança: descobrir onde o agente está tomando decisões que você não revisou.
O que muda para o desenvolvedor brasileiro
Três pontos práticos.
Primeiro, o catálogo de skills. O foco inicial do Beta está em Setup operations. Conforme a Headless 360 Factory expandir, skills específicas de produto vão aparecer: Sales Cloud, Service Cloud, Marketing Cloud, Field Service, Industries. O desenvolvedor brasileiro que atende múltiplos clouds precisa ficar de olho no que está sendo publicado em cada release semanal. Acompanhar o repositório do Salesforce Hosted MCP é a forma mais barata de receber atualizações.
Segundo, a barreira de entrada para automações com IA caiu. O Headless 360 transforma um setup que exigiria 30 minutos de clicks em uma frase em linguagem natural. Times pequenos, que historicamente dependiam de um admin dedicado para configurar Change Data Capture, agora conseguem pedir ao Claude Code que faça isso em uma conversa. O ganho de produtividade é real, e desigual: empresas com pouca capacidade técnica de administração se beneficiam mais do que empresas com times de Salesforce maduros.
Terceiro, a conversa sobre governança vai esquentar. Aqui no Brasil, temas como LGPD e auditoria de acesso sempre foram sensíveis. Quando parte das ações administrativas começa a ser executada por agentes de IA em nome de usuários humanos, os controles precisam se adaptar. Perguntas que parecem óbvias agora vão virar pedido de auditoria:
- Quem aprovou essa mudança de permission set feita pelo agente?
- O log de auditoria distingue entre ação humana e ação agentic?
- O agente pode executar ações em horário não comercial, em fim de semana, em feriado?
- Como revogar uma ação feita por agente depois que ela já foi commitada?
A Salesforce ainda não publicou um playbook detalhado de governança para o Headless 360. Vale acompanhar o Trailhead e os release notes do Winter ’27 para ver o que aparece.
O que esperar até o GA
O anúncio não crava uma data de GA. As três apostas mais prováveis:
- Expansão do catálogo de skills para além de Setup, cobrindo clouds específicas.
- Ferramentas de governança e auditoria mais profundas, provavelmente acompanhando releases de Winter ’27.
- Integração direta com recursos que hoje são cobertos pelo Hosted MCP Server, possivelmente fundindo as duas superfícies.
Quem está planejando bet longo em MCP corporativo precisa tratar o Headless 360 como o pivô arquitetural do Summer ’26. Não porque o Beta de hoje mude o jogo. Porque o pattern de quatro tools com biblioteca escalável é o que provavelmente vai definir os próximos dois anos de integrações agentic na Salesforce.
Conclusão
O Headless 360 MCP Server Beta não é mais um servidor MCP. É a Salesforce dizendo, na prática, que o futuro da configuração de plataforma cabe em quatro botões e um índice semântico. Para o desenvolvedor brasileiro, isso significa três coisas concretas:
- Catálogo de skills crescendo a cada semana vale a pena ser monitorado.
- Automações internas podem sair em minutos em vez de horas, mas precisam de sandbox antes de produção.
- A conversa sobre governança e auditoria agentic precisa começar agora, antes que vire problema em vez de decisão.
O Beta está aberto. Ativar leva cinco minutos. Antes de colocar em produção, exercite o agente em fluxos de baixa criticidade até confiar no desenho. E quando confiar, documente.
E se você encontrar alguma skill que promete algo e não cumpre, poste no GitHub do Salesforce Hosted MCP Servers. O time do Tyson Read está lendo.