# Connect an AI over MCP

> Create a token, register the endpoint, and connect Claude Code, a custom connector or any MCP client.

Source: https://baalda.com/docs/mcp-setup
Site: Baalda, https://baalda.com

The Model Context Protocol endpoint lets any MCP-speaking client work with a vault exactly like a person, limited by the same per-folder permissions. It is part of the same server as everything else, and it is included on every plan.

## 1. Create a token

In the app, open Vault Settings, MCP. The page shows the endpoint URL for the server you are signed in to, and a field to name a token, for example Claude Desktop. A token authenticates the client and scopes it to you in the vault you have open.

> The token is shown once, at creation. Copy it then. If it is lost, revoke it and create another.

## 2. Register the endpoint

The endpoint is your server URL plus `/api/mcp`, so `https://api.baalda.com/api/mcp` on the managed service and your own URL plus the same path when self-hosting. Authentication is a bearer token.

```bash
claude mcp add --transport http context https://api.baalda.com/api/mcp \
  --header "Authorization: Bearer mcp_…"
```

A client that cannot send headers may pass the token as a `key` query parameter instead. Prefer the header where you have the choice, since query strings are easier to leak through logs.

## 3. Check the connection

The MCP page lists each token as a connection card with the tools it can reach and when it was last used, refreshed while the page is open, and a Revoke action. Revoking takes effect for the next call.

## OAuth connectors

Clients that support MCP's OAuth flow, such as a custom connector, do not need a hand-pasted token. Every 401 from the endpoint carries a `WWW-Authenticate` header pointing at the server's protected-resource metadata, which is what lets a client discover the authorization server and start the flow.

An OAuth access token only says who the caller is, so the vault is chosen by the person on the consent screen and remembered for that client. Consenting again can retarget the same client at a different vault. Everything downstream, including every permission check, is identical to a hand-made token.

## Transport

| Request | Behaviour |
|---|---|
| `POST /api/mcp` | The endpoint itself. JSON-RPC 2.0 over Streamable HTTP, answering with a single JSON reply |
| `GET /api/mcp` | 405. There is no server-to-client event stream |
| `DELETE /api/mcp` | 405 |
| `GET /api/mcp/tokens` | Lists your tokens for the active vault. Session-authenticated, which is what the app's settings page uses |
| `POST /api/mcp/tokens` | Mints a token, returning the plaintext once |
| `DELETE /api/mcp/tokens/:id` | Revokes a token |

## What to connect it to

The tool catalog is the same for every token, since the per-folder ACL is what decides what a call may touch. The reference page lists all of it, with parameters and the refusals each tool can return.

- [MCP tool reference](/docs/mcp-tools): All 22 tools, their parameters, and what refuses a write.
- [Access control](/docs/access): What a token's owner can reach is what the token can reach.