> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chatsailer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sailer MCP

> Dos servidores hospedados. Uno para las personas de tu CRM, otro para los agentes que les hablan.

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.

| Servidor                | URL                                     | En vivo hoy                                                                      |
| ----------------------- | --------------------------------------- | -------------------------------------------------------------------------------- |
| **Sailer CRM**          | `https://mcp.chatsailer.com/mcp/crm`    | Identity, schema, contacts, organizations, deals, campaigns, conversation traces |
| **Sailer Agent Studio** | `https://mcp.chatsailer.com/mcp/studio` | Identity, agent graphs, sandbox                                                  |

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í

<CardGroup cols={2}>
  <Card title="Conecta un cliente" icon="plug" href="/es/mcp/connect">
    Claude Code, Claude, ChatGPT o Cursor. Unos diez minutos.
  </Card>

  <Card title="Autenticación" icon="key" href="/es/mcp/auth">
    OAuth vs un token de workspace, scopes, y por qué la primera conexión no puede escribir.
  </Card>

  <Card title="Servidor CRM" icon="address-book" href="/es/mcp/crm">
    Contactos, organizations, deals, campañas. Llama `describe_schema` antes de adivinar las keys de los campos.
  </Card>

  <Card title="Agent Studio" icon="diagram-project" href="/es/mcp/studio">
    Graphs, publish, sandbox. Draft hasta que hagas ship.
  </Card>
</CardGroup>