Introduction
The Magic Dashboard MCP server is a remote Model Context Protocol server that exposes the operations of the public API — organization, portal users and team — 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.dashboards.kobana.com.br, with Streamable HTTP transport in stateless mode and Bearer token authentication. No client certificate is involved.
:::info Availability
The server and its 292 tools are implemented, and authentication goes through the Kobana authorization server: via the OAuth 2.1 flow, where the client is given only the URL and signs in on its own, or via a personal token created in your Kobana account. The dedicated edge (the mcp.dashboards.* distribution, WAF and DNS) is still being provisioned.
:::
When to use it
REST API (/v1) | MCP server (this) | |
|---|---|---|
| Consumer | your backend | an AI client (Claude, ChatGPT, an IDE) |
| Setup | a token, out of band | one URL |
| Transport | HTTPS/REST | Streamable HTTP (JSON-RPC 2.0) |
| Auth | Bearer token issued for the API | OAuth 2.1 or a personal token, always issued for MCP |
| Surface | 177 routes | 292 tools over the same endpoints |
The MCP server does not replace the REST API. Every tool dispatches in-process to the endpoint that implements the operation, so filters, upsert matching, validation, proration and tenant isolation are exactly the same. If you are writing code, use the REST API. If you are connecting an assistant, use this.
The principle
A capability exists in MCP only if it exists in the public API.
There is no second implementation of anything. The tool calls the endpoint's handler with the identity the caller's token already proved — the same person, the same organization — so it runs the way it would for any HTTP request, and the audit trail it writes is attributed to whoever authorized the client. A tool does what the endpoint does over REST — never more.
The practical consequence: what exists only in the dashboard today does not become a tool before it becomes an endpoint.
What you see is narrower than the catalogue
tools/list returns only the tools this caller can actually run, filtered by the dashboard permissions of whoever authorized the client. An agent is not told about capabilities that would only earn it a refusal. The rules are in Authentication.
Getting started
-
Point your client at the server URL — see Endpoints and Clients.
-
Authorize. The client opens the Kobana sign-in; sign in with an account of the organization and authorize access. See Authentication.
-
List the tools to confirm what your access reaches — ask the assistant, or, with a token issued for MCP at hand:
curl https://mcp.dashboards.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" }' -
Explore the documentation — the full catalogue is in Tools.
Next steps
- Authentication — the OAuth flow, the personal token, the scope and permissions applied, and the failure modes.
- Endpoints — URLs per environment and the routes served.
- Transport — JSON-RPC, headers and methods.
- Resources and prompts — documents by URI, ready-made prompts, autocomplete, and the confirmation of destructive tools.
- Clients — connecting Claude Code and file-configured clients.
- Listing, sorting and fields —
page,sort_by,fields. - Errors — the two failure channels, and why the difference matters.
- Tools — the catalogue of all 292 tools.