RowAttest

API & MCP

RowAttest MCP server

RowAttest runs an eight-stage isolation test against your staging Supabase and issues a signed attestation. The MCP server gives your AI assistant the same seven actions a RowAttest API key has: list your projects, start a run, follow it, read the findings and the signed report, and check another site's published attestation. Projects are connected on the website only. The server cannot connect projects, change settings, or pay for anything.

Endpoint

URL
https://app.rowattest.com/mcp
Transport
Streamable HTTP. The endpoint accepts POST; GET answers 405.
Authentication
Authorization: Bearer rak_… — a RowAttest API key, created on the API keys page in the app.
Accept header
Clients send Accept: application/json, text/event-stream. Standard MCP clients do this on their own.

Open handshake, keyed tools

initialize, tools/list and server/discover answer without a key, so clients and directories can see what the server offers before a key is configured. Every tools/call needs a key. Without a valid one the server answers 401 with:

This request needs a valid RowAttest API key in the Authorization header.

Connect your assistant

Claude Code:

claude mcp add --transport http rowattest https://app.rowattest.com/mcp --header "Authorization: Bearer rak_your_key"

Clients that read an mcpServers block (Cursor and others):

{
  "mcpServers": {
    "rowattest": {
      "url": "https://app.rowattest.com/mcp",
      "headers": { "Authorization": "Bearer rak_your_key" }
    }
  }
}

VS Code:

Install in VS Code. VS Code asks for your API key the first time the server starts.

The API keys page in the app shows ready-to-paste settings for Claude Code, Cursor and mcp-remote.

The seven tools

list_projects

Lists the Supabase projects connected to this account with id, name, connection state and whether each is ready to run. Call this first to get a project_id.

Input: none

run_review

Starts an authorization test run on a connected project and returns the run_id and status. If the project already has a run waiting to start, returns that run instead of starting another. Runs that do not fail count against the monthly allowance. With attest set to true it asks for a signed proof up front and is refused with code proof_not_included when the account's plan does not include one; then no run starts.

Input: project_id, label (optional), attest (optional)

get_run_status

Returns a run's status (queued, running, complete or failed), its current stage, timestamps and, when a signed report exists, its verify_url.

Input: run_id

wait_for_run

Waits up to timeout_seconds (1 to 60) for a run to finish, then returns the same information as get_run_status. Call it again while the status is still queued or running.

Input: run_id, timeout_seconds (optional)

get_findings

Returns the cells that did not pass in a complete run that has a signed report — verdict, surface, operation, boundary, identity, layer outcomes and notes — plus tenancy flags, blocking findings and, when the report includes catalog hygiene checks, the hygiene block (the checks run, each finding's check, severity, object, detail and hint, and any check not run). For a complete run with no signed report, while one can still be bought on the run page, it returns the run's unverified result instead: the verdict, surface, operation and principal of each cell that did not pass, the run page's finding lines, the counts, the coverage lines, the access model summary and the same hygiene block. The list of cells is empty when every tested cell passed. Cell results contain no fix suggestions: the engine records only what it observed. Hygiene findings are catalog observations, never verdicts; each carries the engine's one-line hint for the project owner's review.

Input: run_id

get_report

Returns the full signed report of a complete run as the exact stored JSON, with its verify_url and report_sha256 (sha256 of the canonical signed bytes, the fingerprint shown on the verify page). Use get_findings for the compact view.

Input: run_id

verify_attestation

Checks an attestation another site or MCP server has published. Give it an origin; it fetches that origin's /.well-known/rowattest.json, follows the first entry to the signed summary, verifies the signature offline against RowAttest's key list and tells you whether the proof is valid, when it was issued, its totals, whether findings were present, and whether it is bound to the project ref you pass. Public data only; no run starts.

Input: origin, project_ref (optional), fingerprint (optional)

A typical session: list_projects → run_review → wait_for_run until the status is complete or failed → get_findings, get_report when a signed report exists, and verify_attestation to check a proof another site publishes.

A prompt for your assistant

Paste this into Claude Code, Codex or Cursor once the rowattest server is connected. Replace the project name with the one list_projects shows.

After you apply a database migration to my staging Supabase project, run a RowAttest isolation check through the rowattest MCP server.

1. Call list_projects and pick the project named "<staging project name>".
2. Call run_review with its project_id. If it returns a run that is already waiting, follow that run instead of starting another.
3. Call wait_for_run until the status is complete or failed.
4. Call get_findings. Tell me in plain words which tables or buckets let a test user reach another user's or another organization's rows, and repeat the finding lines it returns. If the list of cells is empty, say that every tested cell passed.
5. Start at most one run per migration. My free allowance is 10 runs a month; if run_review says the allowance is used up, stop and tell me instead of retrying.

Never ask me for Supabase credentials. A RowAttest key cannot connect projects or change settings.

What a key can and cannot do

Create a key on the API keys page. A key can list your projects, start runs, follow them, and read findings and the signed report. It cannot connect projects, change settings, or pay for anything. Keys and agents never hold your project's credentials. A key can also check another site's published attestation with verify_attestation, which reads public data only.

Allowance

Runs started through MCP count against the account's monthly allowance, the same as runs started in the dashboard or through the REST API. Failed runs do not count. A run refused with proof_not_included was never started and does not count.

Unsigned and signed

Free runs show their results on the run page and through the API, labelled as unverified; get_findings returns that unverified result. Buying the signed report for a run adds the signed PDF, a public verify link, and the signed JSON, which get_report returns. Anyone can check a signed report at its verify link on rowattest.com/verify.

Requests without a key

Requests that need a key but carry no valid one are rate-limited. The privacy policy describes what is recorded for that and for how long.

Also available

← Back to RowAttest