Documentation

Calling the REST twin

Every tool is reachable at one uniform shape — POST /api/v1/tools/{name}, with the tool's arguments as the body. There is no per-tool route dialect to learn:

Code
curl -X POST "https://dtrgbxembnbwlmpvhhms.supabase.co/functions/v1/cortex-mcp/api/v1/tools/get_performance_summary" \
  -H "Authorization: Bearer ck_your_token" \
  -H "Content-Type: application/json" \
  -d '{"start_date":"2026-07-01","end_date":"2026-07-31"}'

A success is { "ok": true, "tool": "<name>", "data": … }, where data is byte-identical to what the same tool returns over MCP.

REST body: the tool's arguments, as a JSON object. Capped at 64 KiB.
Every REST response carries an X-Request-Id — quote it in support requests and it maps to one audit row.
Errors use the flat { error, message, path?, request_id } shape — see Errors.

OpenAPI contract

Generate a client from the OpenAPI 3.1 document at https://dtrgbxembnbwlmpvhhms.supabase.co/functions/v1/cortex-mcp/api/v1/openapi.json. It is served unauthenticated and cacheable (5 minutes): the tool names, descriptions and argument schemas are public, the data behind them is not.

The same contract powers the interactive API Reference on this site.

Schema caveat

Published argument schemas are generated from the server's own validation schemas, so they are exact about property names, types and unknown-key rejection. They cannot express cross-field constraints — a .refine() rule such as "start_date must be on or before end_date" has no JSON Schema form and is not in the published contract. Those rules are still enforced, and answer with a normal 400 validation_error. Treat the published schema as necessary, not sufficient.

Last modified on October 7, 2026

Connecting an MCP client Context pack