Skip to main content
Sailer MCP deja que Claude, ChatGPT, Cursor y cualquier otra cosa que hable MCP llame tools contra un workspace en vivo. Agregas una URL, inicias sesión y preguntas en lenguaje natural. El modelo hace el resto. Dos servidores, no uno: tirarle ambos a un modelo hace que elija peores tools. Conecta el que realmente necesitas. Empieza con CRM. Studio es para quien edita agentes. La URL debe incluir /mcp/ antes de /crm o /studio. /crm solo es un typo, y el cliente te va a decir que no puede alcanzar el servidor.

​
Qué está en vivo

Las tools de registros del CRM toman un resource de "contact", "organization" o "deal". Las campañas y los traces de conversación tienen sus propias tools. No hay send en una conversación en vivo — messages:write no está cableado. Los modelos que necesitan enviar lo hacen a un sandbox a través de Studio. Studio inspecciona la working copy de un agente, la publica y la prueba en un sandbox. Nada llega a conversaciones en vivo hasta que publiques a propósito.

​
Cómo habla

JSON sin estado sobre Streamable HTTP. No hay stream SSE, no hay WebSocket y no hay paquete local stdio. El trabajo largo — un turno de sandbox — es start-then-poll, porque una conexión que se queda idle muere en el load balancer. No necesitas saber eso para conectar. Tu cliente sí.

​
Compruébalo

Una vez que un cliente está conectado, pregunta:
Which Sailer workspace am I connected to?
El modelo debería llamar whoami y nombrar el workspace, la organización padre, quién autorizó la conexión y los scopes que otorgaste. Esa sola respuesta confirma que auth, tenancy y tool-calling funcionan.

​
Empieza aquí

Conecta un cliente

Claude Code, Claude, ChatGPT o Cursor. Unos diez minutos.

Autenticación

OAuth vs un token de workspace, scopes, y por qué la primera conexión no puede escribir.

Servidor CRM

Contactos, organizations, deals, campañas. Llama describe_schema antes de adivinar las keys de los campos.

Agent Studio

Graphs, publish, sandbox. Draft hasta que hagas ship.