Skip to main content
Toda requisição MCP carrega uma credencial bearer. Não há header de workspace — a credencial é o workspace. Dois tipos. Escolha o que combina com quem está chamando. whoami reporta credential: oauth ou credential: api_token, e reads_company_wide: true quando não há usuário para filtrar. Pergunte isso quando você não tiver certeza de que tipo de conexão está olhando.

​
OAuth

É isso que os tutoriais de cliente percorrem. O cliente descobre o authorization server da Sailer, você entra com o seu email da Sailer, escolhe um workspace se pertencer a mais de um, aprova. Três telas, nesta ordem:
  1. Auth0 sign-in — o email que é membro de um workspace da Sailer. Já está logado? Este passo é pulado.
  2. Consent — qual workspace, e quais permissões. Um workspace por conexão, pela vida do grant. Nada numa URL ou num argumento de tool pode mudar isso.
  3. Done — feche a aba. O cliente agora tem tokens.
Deixe Client ID e Client Secret em branco. A Sailer registra o cliente ela mesma. Colar credenciais que você inventou, ou de algum outro app OAuth, é como isso falha.

​
A primeira conexão é só leituras

O primeiro consent pede identity (openid, profile, offline_access) mais cada scope *:read que o seu papel realmente consegue conceder. Sem writes. Ninguém deveria aprovar “atualiza o meu CRM” antes de ter lido um só registro. Se você pedir ao modelo para criar ou atualizar algo, a tool vai dizer que a conexão está sem um scope e que tentar de novo não vai ajudar. Desconecte, reconecte e aprove o write quando o consent pedir — contacts, organizations, deals ou campaigns, o que a tarefa precisar.

​
Scopes são uma interseção

O consent mostra o que o seu papel naquele workspace consegue conceder. Permissões riscadas não são bug — o seu papel não pode ceder elas. Peça a um admin para ampliar o papel se você precisar delas. Um scope é <resource>:<access>. Tools que você não consegue chamar não aparecem em tools/list. Uma conexão somente leitura não deveria ver create_record de jeito nenhum.

​
Um servidor por grant

Um token OAuth é emitido para exatamente um resource: /mcp/crm ou /mcp/studio. Usar um token de CRM no Studio é 401, não 403. Descompasso de audience não é scope faltando. Reconecte no outro servidor; não tente de novo.

​
Tokens de workspace

Um token estático sk_live_… / sk_test_… é o caminho de máquina. O mesmo formato da API REST. Envie como Authorization: Bearer sk_live_…. Ele não tem usuário, então o ACL de visibilidade do CRM não se aplica: o token lê cada registro do workspace que os seus scopes permitirem. Trate-o como acesso a todo o workspace. Um token por integração, nunca no controle de versão.

​
Trocar de workspace

Uma conexão fica ligada a um workspace pela vida dela. Para usar outro, tire o conector e adicione de novo, depois escolha o outro workspace no consent. A mesma reconexão é como você concede writes. Você não consegue apontar uma URL para dois workspaces ao mesmo tempo.