MCP server
Point any MCP client at your app and the agent's permitted tools appear.
Every app is a Model Context Protocol server. There is no separate MCP configuration and no tool list to maintain — the tools an MCP client sees are the same policy-derived surface the agent itself uses.
POST /{appUid}/mcp
Authorization: Bearer plak_...JSON-RPC 2.0. initialize, tools/list, and tools/call are supported.
One key, one server
An api key is bound 1:1 to an agent, so a key is an MCP server scoped to that agent. Issue two keys for two agents and a client can connect to each with different reach. Revoke a policy and the tool disappears from every connected client.
Connecting a client
Most MCP clients take a URL and a header. The exact configuration file differs per client, but the two values are always the same:
| Field | Value |
|---|---|
| URL | https://your-api-host/{appUid}/mcp |
| Header | Authorization: Bearer plak_... |
Trying it by hand
# List the tools this key may use
curl -X POST "$AUTHORIC_URL/$APP_UID/mcp" \
-H "Authorization: Bearer $AGENT_KEY" \
-H "Content-Type: application/json" \
-d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }'
# Call one
curl -X POST "$AUTHORIC_URL/$APP_UID/mcp" \
-H "Authorization: Bearer $AGENT_KEY" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": { "name": "tickets_create", "arguments": { "subject": "Card declined" } }
}'Halts over MCP
A high-risk tool behaves here exactly as everywhere else: it does not execute. The call returns a run handle and waits for a human. An MCP client is not a trusted context, and nothing about connecting over MCP relaxes the boundary.
Because MCP has no notion of "come back later for this answer", the practical pattern is to treat a pending result as a normal outcome: report to the user that the action needs approval, and check the run afterwards.
Transport notes
POST only. GET /{appUid}/mcp returns 405 — there is no SSE transport on this endpoint.