Introduction

The Autonomous Inbox MCP server is a remote Model Context Protocol server that exposes the same operations as the public REST API — inboxes, e-mails, agents, runs, webhooks and the event log — as tools an AI client can call. You connect it by URL; there is nothing to install.

It is served on its own host, mcp.inbox.kobana.com.br, with Streamable HTTP transport in stateless mode and Bearer token authentication, issued for the MCP server by the Kobana authorization server. No client certificate is involved: unlike /v1, the MCP host has no mTLS layer, and OAuth 2.1 takes its place.

:::info Availability The server, its 53 tools, the resources and the prompts are implemented, and authentication goes through the Kobana authorization server: by the OAuth 2.1 flow, where the client gets only the URL and logs in on its own, or by a personal token created in your Kobana account. The dedicated edge (mcp.inbox.* distribution, WAF and DNS) is still being provisioned. :::

When to use it

	REST API (/v1)	MCP server (this)	stdio servers
Consumer	your backend	an AI client (Claude, ChatGPT, an IDE)	an AI client on your own machine
Setup	certificate + token, out of band	one URL	local build + mcp.json
Transport	HTTPS/REST	Streamable HTTP (JSON-RPC 2.0)	stdio
Auth	mTLS + Bearer JWT issued for the API	OAuth 2.1 or personal token, always issued for the MCP server	mTLS + Bearer JWT
Surface	the /v1 endpoints	53 tools over the same endpoints, plus resources and prompts on top of them	one server per resource

The MCP server does not replace the REST API — every tool dispatches to the endpoint that owns the operation, so filters, upsert rules, validation and multi-tenant isolation are exactly the same. If you are writing code, use the REST API. If you are connecting an assistant, use this.

Getting started

1. Point your client at the server URL — see Endpoints and Clients.

2. Authorize. The client opens the Kobana login; sign in with an account of the organization and authorize the access. See Authentication.

3. List the tools to confirm what your access reaches — ask the assistant, or, with a token issued for the MCP server at hand:

   curl https://mcp.inbox.kobana.com.br/ \
     -H "Authorization: Bearer $MCP_TOKEN" \
     -H "Content-Type: application/json" \
     -H "Accept: application/json" \
     -H "MCP-Protocol-Version: 2025-06-18" \
     -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }'

4. Explore the tools — the Resources category in the sidebar documents every tool with its parameters.

What a caller sees

tools/list is filtered by what the caller can actually run, on two axes:

• the scopes (or the access level) of the presented token — the ceiling of the connected client;
• the permissions of the person the token names — what that person may do in their organization.

A token carrying only inbox/emails sees the read-only e-mail tools and nothing else. A person without emails.reprocess never sees emails_reprocess, even holding a token that would allow it. An agent is not told about capabilities it cannot use.

Next steps

• Authentication — the OAuth flow, the personal token, scopes and permissions, and the failure modes.
• Endpoints — hosts per environment and the routes served.
• Transport — Streamable HTTP, JSON-RPC methods and headers.
• Resources and prompts — documents by URI, ready-made prompts, autocomplete and the confirmation of destructive tools.
• Clients — connecting Claude, Claude Code and other MCP clients.
• Rate limiting — throttling and response headers.
• Pagination — cursor pagination in tool results.
• Idempotency — idempotency_key for safe retries.
• Errors — protocol errors and tool errors.