Saltar al contenido principal

Clientes

Cualquier cliente que hable MCP sobre Streamable HTTP y sepa ejecutar el flujo OAuth 2.1 de MCP puede conectarse. Solo le das la URL; el cliente descubre por su cuenta dónde autenticarse, abre el login de Kobana en el navegador y guarda el token — ver Autenticación.

Un cliente sin soporte de OAuth también se conecta, con un token personal: créalo en Cuenta Kobana → Tokens y Acceso → Nuevo Token Personal, con la app Inbox Autónomo y el uso MCP, y configura el cliente para enviarlo como Authorization: Bearer <token>. También es el camino para un agente que necesita escribir, ya que el flujo OAuth concede hoy acceso de solo lectura.

Cuando tu organización tiene más de un workspace, elige uno por conexión con el header X-Workspace-Id.

Claude Code​

claude mcp add --transport http kobana-inbox https://mcp.inbox.kobana.com.br

Después ejecuta /mcp en una sesión y elige Authenticate para iniciar sesión en Kobana.

Con un token personal, sin el flujo OAuth:

claude mcp add --transport http kobana-inbox https://mcp.inbox.kobana.com.br \
  --header "Authorization: Bearer <personal token>"

Clientes configurados por archivo​

Los clientes que leen un archivo de configuración JSON piden la URL y el transporte. Con el flujo OAuth no hay header de autenticación:

{
  "mcpServers": {
    "kobana-inbox": {
      "type": "http",
      "url": "https://mcp.inbox.kobana.com.br"
    }
  }
}

En la primera conexión, el cliente abre el navegador para que autorices. Eliges la organización en la pantalla de consentimiento, y queda registrada en el token.

Con un token personal, añade los headers — la organización es la de la cuenta donde creaste el token:

{
  "mcpServers": {
    "kobana-inbox": {
      "type": "http",
      "url": "https://mcp.inbox.kobana.com.br",
      "headers": {
        "Authorization": "Bearer <personal token>",
        "X-Workspace-Id": "<workspace-id>"
      }
    }
  }
}

X-Workspace-Id solo hace falta cuando tu organización tiene más de un workspace. Trata el archivo como un secreto: quien lo lea usa el token.

Clientes que conectan por URL​

Claude y ChatGPT conectan un servidor remoto pegando https://mcp.inbox.kobana.com.br en la configuración de conectores. El flujo OAuth se ejecuta dentro de la app.

Usando otros servidores de Kobana al mismo tiempo​

Las tools de aquí no llevan prefijo (emails_list), y los resources viven bajo kobana://inbox/; los demás servidores MCP de Kobana prefijan los suyos (billing_, finance_, kobana://billing/, kobana://finance/). Conviven en el mismo cliente sin colisionar.

Postura recomendada para agentes​

  • Autoriza con la cuenta correcta. Las tools se limitan a lo que la persona que autorizó puede hacer en el dashboard. Un cliente autorizado por un analista de solo lectura expone solo las tools de lectura, intente lo que intente el modelo del otro lado. Es la forma más fuerte de restringir un agente.
  • Mantén el token de solo lectura. Un token con scopes de recurso pero sin el verbo write físicamente no cambia nada. El flujo OAuth es de solo lectura por construcción; en un token personal, marca escritura solo en los recursos que el agente debe cambiar.
  • Token personal: validez corta, scope mínimo. Revocarlo en Kobana no corta el acceso antes de que expire — ver Revocación del token personal.
  • Deja fuera las tools destructivas a menos que las necesites. Las eliminaciones, las acciones hacia fuera (prueba y reenvío de webhook, reprocesamiento de correo), la rotación de secreto y los cambios en la lista de remitentes exigen el verbo write y un permiso que el administrador de la organización concede explícitamente, y el servidor pide al usuario que confirme cada una — solo un cliente en el protocolo 2026-07-28 con formularios de elicitation puede ejecutarlas.

Servidores stdio locales​

El repositorio también incluye siete servidores MCP stdio, uno por recurso (workspaces, inboxes, emails, agents, agent-runs, webhooks, system-events). Corren en tu máquina, hablan con la API pública por HTTPS y usan la pila completa de autenticación REST — JWT, certificado mTLS de cliente y secreto de origen.

Siguen siendo una opción válida y este servidor no los reemplaza. Úsalos cuando ya tengas un certificado de cliente y quieras el scope mínimo garantizado por ejecutar solo el servidor que necesitas; usa el servidor remoto cuando no puedas distribuir un certificado al cliente.