Skip to main content
Cada petición MCP lleva una credencial bearer. No hay header de workspace — la credencial es el workspace. Dos tipos. Elige el que coincida con quién llama. whoami reporta credential: oauth o credential: api_token, y reads_company_wide: true cuando no hay usuario por el que filtrar. Pregúntalo cuando no estés seguro de qué tipo de conexión estás viendo.

​
OAuth

Esto es lo que recorren los tutoriales de cliente. El cliente descubre el authorization server de Sailer, inicias sesión con tu email de Sailer, eliges un workspace si perteneces a más de uno, apruebas. Tres pantallas, en este orden:
  1. Auth0 sign-in — el email que es miembro de un workspace de Sailer. ¿Ya estás con sesión iniciada? Este paso se salta.
  2. Consent — qué workspace, y qué permisos. Un workspace por conexión, durante la vida del grant. Nada en una URL o en un argumento de tool puede cambiarlo.
  3. Done — cierra la pestaña. El cliente ahora tiene tokens.
Deja Client ID y Client Secret en blanco. Sailer registra el cliente él mismo. Pegar credenciales que inventaste, o de alguna otra app OAuth, es cómo esto falla.

​
La primera conexión es solo lecturas

El primer consent pide identity (openid, profile, offline_access) más cada scope *:read que tu rol realmente puede otorgar. Sin writes. Nadie debería aprobar “actualiza mi CRM” antes de haber leído un solo registro. Si le pides al modelo crear o actualizar algo, la tool va a decir que a la conexión le falta un scope y que reintentar no va a ayudar. Desconecta, vuelve a conectar y aprueba el write cuando el consent lo pida — contacts, organizations, deals o campaigns, lo que la tarea necesite.

​
Los scopes son una intersección

El consent muestra lo que tu rol en ese workspace puede otorgar. Los permisos tachados no son un bug — tu rol no puede cederlos. Pídele a un admin que amplíe el rol si los necesitas. Un scope es <resource>:<access>. Las tools que no puedes llamar no aparecen en tools/list. Una conexión de solo lectura no debería ver create_record para nada.

​
Un servidor por grant

Un token OAuth se emite para exactamente un resource: /mcp/crm o /mcp/studio. Usar un token de CRM en Studio es 401, no 403. Un desajuste de audience no es un scope faltante. Vuelve a conectar al otro servidor; no reintentes.

​
Tokens de workspace

Un token estático sk_live_… / sk_test_… es el camino de máquina. El mismo formato que la API REST. Envíalo como Authorization: Bearer sk_live_…. No tiene usuario, así que el ACL de visibilidad del CRM no aplica: el token lee cada registro del workspace que sus scopes permitan. Trátalo como acceso a todo el workspace. Un token por integración, nunca en el control de versiones.

​
Cambiar de workspace

Una conexión está ligada a un workspace durante su vida. Para usar otro, quita el conector y agrégalo de nuevo, luego elige el otro workspace en el consent. La misma reconexión es cómo otorgas writes. No puedes apuntar una URL a dos workspaces a la vez.