Skip to main content
O Sailer MCP deixa Claude, ChatGPT, Cursor e qualquer outra coisa que fale MCP chamar tools contra um workspace ao vivo. Você adiciona uma URL, entra e pergunta em linguagem natural. O modelo faz o resto. Dois servidores, não um: jogar os dois num modelo faz ele escolher tools piores. Conecte o que você realmente precisa. Comece pelo CRM. Studio é para quem edita agentes. A URL precisa incluir /mcp/ antes de /crm ou /studio. /crm sozinho é um typo, e o cliente vai dizer que não consegue alcançar o servidor.

​
O que está no ar

As tools de registro do CRM recebem um resource de "contact", "organization" ou "deal". Campanhas e traces de conversa têm as suas próprias tools. Não há send numa conversa ao vivo — messages:write não está ligado. Modelos que precisam enviar fazem isso num sandbox pelo Studio. O Studio inspeciona a working copy de um agente, publica e testa num sandbox. Nada chega a conversas ao vivo até você publicar de propósito.

​
Como ele fala

JSON sem estado sobre Streamable HTTP. Não há stream SSE, não há WebSocket e não há pacote local stdio. Trabalho longo — um turno de sandbox — é start-then-poll, porque uma conexão que fica idle morre no load balancer. Você não precisa saber disso para conectar. O seu cliente precisa.

​
Comprove

Depois que um cliente está conectado, pergunte:
Which Sailer workspace am I connected to?
O modelo deve chamar whoami e nomear o workspace, a organização pai, quem autorizou a conexão e os scopes que você concedeu. Essa única resposta confirma que auth, tenancy e tool-calling funcionam.

​
Comece aqui

Conecte um cliente

Claude Code, Claude, ChatGPT ou Cursor. Cerca de dez minutos.

Autenticação

OAuth vs um token de workspace, scopes, e por que a primeira conexão não consegue escrever.

Servidor CRM

Contatos, organizations, deals, campanhas. Chame describe_schema antes de adivinhar as keys dos campos.

Agent Studio

Graphs, publish, sandbox. Draft até você fazer ship.