Authentication

Platica's MCP server reuses exactly the same authentication mechanism as the REST API: a Bearer token with your API Key.

Authorization: Bearer pl_key_xxxxxxxxxxxxxxxx_yyyyyyyyyyyyyyyy

Every MCP tool you run internally makes the same authenticated call you would make to the corresponding REST endpoint, so:

• Scopes are exactly the API Key's scopes (workspace it has access to, permissions, etc.).
• Rate limits, validation, and errors are identical.
• There is no separate "MCP mode": if the API Key can call POST /v1/clients, the create_client tool works; if it can't, it returns the same 403.

Generate an API Key

API Keys are created from the Platica dashboard, not from the MCP server:

1. Open Settings → API Keys in your dashboard.
2. Create a new Key with a descriptive name (e.g. cursor-personal).
3. Copy the Key in the pl_key_KEY_ID_SECRET format. It's shown only once.
4. Paste it into the Authorization header in your MCP client's config (see Setup ).

Multi-workspace

If your API Key has access to multiple workspaces, write tools accept an optional workspace argument (the same name as the REST ?workspace= query param). If you omit it with a multi-workspace key, the API responds with 400 Must specify a valid workspace... and the tool returns that message as an error so the model can correct itself.

With single-workspace keys you can always omit the argument — the workspace is inferred automatically.

Why Bearer and not OAuth?

The MCP spec recommends OAuth 2.1, but it also allows custom authentication schemes . For integrating with the existing API, Bearer + API Key is:

• Equivalent in security to the REST API (which already uses the same mechanism).
• Natively supported by Cursor, Claude Code, mcp-remote, and modern Streamable HTTP clients.
• No extra steps for users: the same key they already generated for curl/Postman.