Clients
Any client that speaks Streamable HTTP MCP and can run the MCP OAuth 2.1 flow can connect. You only give it the URL; the client finds where to authenticate on its own, opens the Kobana login in the browser and keeps the token — see Authentication.
A client without OAuth support connects too, with a personal token: create it in Kobana Account → Tokens and Access → New Personal Token, with the app Autonomous Inbox and the use MCP, and configure the client to send it as Authorization: Bearer <token>. It is also the way for an agent that needs to write, since the OAuth flow grants read-only access today.
When your organization has more than one workspace, pick one per connection with the X-Workspace-Id header.
Claude Code
claude mcp add --transport http kobana-inbox https://mcp.inbox.kobana.com.br
Then run /mcp in a session and choose Authenticate to log in to Kobana.
With a personal token, without the OAuth flow:
claude mcp add --transport http kobana-inbox https://mcp.inbox.kobana.com.br \
--header "Authorization: Bearer <personal token>"
Clients configured by file
Clients that read a JSON configuration file take the URL and the transport. Through the OAuth flow there is no authentication header:
{
"mcpServers": {
"kobana-inbox": {
"type": "http",
"url": "https://mcp.inbox.kobana.com.br"
}
}
}
On the first connection the client opens the browser for you to authorize. You pick the organization on the consent screen, and it is recorded in the token.
With a personal token, add the headers — the organization is the one of the account where you created the 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 is only needed when your organization has more than one workspace. Treat the file as a secret: whoever reads it uses the token.
Clients that connect by URL
Claude and ChatGPT connect a remote server by pasting https://mcp.inbox.kobana.com.br into their connector settings. The OAuth flow runs inside the app.
Using other Kobana servers alongside
Tools here are unprefixed (emails_list), and resources live under kobana://inbox/; the other Kobana MCP servers prefix theirs (billing_, finance_, kobana://billing/, kobana://finance/). They sit in the same client without colliding.
Recommended posture for agents
- Authorize with the right account. Tools are narrowed to what the person who authorized can do in the dashboard. A client authorized by a read-only analyst exposes only the read tools, whatever the model on the other side tries. It is the strongest way to restrict an agent.
- Keep the token read-only. A token carrying resource scopes but not the
writeverb physically cannot change anything. The OAuth flow is read-only by construction; in a personal token, tick write only on the resources the agent must change. - Personal token: short validity, minimum scope. Revoking it in Kobana does not cut access before it expires — see Personal token revocation.
- Keep the destructive tools out unless you need them. Deletes, outbound actions (webhook test and replay, e-mail reprocess), secret rotation and allow-list changes require the
writeverb and a permission that an organization administrator grants explicitly, and the server asks the user to confirm each one — only a client on protocol2026-07-28with elicitation forms can run them.
Local stdio servers
The repository also ships seven stdio MCP servers, one per resource (workspaces, inboxes, emails, agents, agent-runs, webhooks, system-events). They run on your machine, talk to the public API over HTTPS and use the full REST authentication stack — JWT, mTLS client certificate and origin secret.
They remain a valid option and are not replaced by this server. Use them when you already hold a client certificate and want the minimum scope enforced by running only the server you need; use the remote server when you cannot distribute a certificate to the client.