MCP server
GET/POST /api/mcp implements the Model Context Protocol. No extra
wiring is needed: every collection is automatically exposed as MCP tools
(list_<collection>, get_<collection>, create_<collection>,
update_<collection>, delete_<collection>) — POST /api/mcp {"method":"tools/list"} reflects whatever collections currently exist.
An agent authenticates with an API key
like any other identity, through the same authorization path a normal
HTTP request goes through — nothing bespoke for agent traffic. What
access that gets the agent depends on which of the two key shapes you
minted:
- A record-scoped key — the recommended shape for an agent — gets exactly the rule-gated access its target record has, same as that record logging in normally. This is the shape that makes “an agent gets the same rule enforcement as a real user” literally true, and it’s the one to reach for here: a compromised or over-eager agent can only do what that one record could do.
- A superuser key is unscoped root — every rule is bypassed, on
every collection, for every tool call. Only use one for an agent you
trust with the entire database, the same caution you’d give a
Supabase
service_rolekey.
Connect Claude, Cursor, or any MCP-speaking client by pointing it at this endpoint; the dashboard’s Settings → MCP page shows the connection details and the dashboard’s Settings → API keys page is where you mint either shape of key.
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "list_posts", "arguments": { "filter": "published = true", "perPage": 10 } } }A denied rule or a validation failure inside tools/call comes back as
an ordinary JSON-RPC result with isError: true — never a protocol
error — so an agent sees the same “you don’t have access” or “missing
required field” signal a human would over plain HTTP, not a broken
connection. See Reference → REST API → MCP
for the full method table (initialize, ping, tools/list,
tools/call) and the exact tool-naming scheme.