Clawhard Studio

Check who can read and write Supabase tables (RLS, policies, grants)

deadbolt_check_supabase_access

Read-onlyIdempotent

Use when you write, review or are about to apply Supabase / PostgreSQL migration SQL (CREATE TABLE, RLS, CREATE POLICY, GRANT, views, SECURITY DEFINER functions, storage buckets), or when a user asks whether their Supabase data is exposed, whether RLS is set up right, or why a query returns 42501 permission denied or no rows. Replays the SQL with real Postgres rules and returns, per table, what signed-out (anon) and signed-in (authenticated) users can SELECT/INSERT/UPDATE/DELETE (all rows, own rows, some rows, none, or denied for a missing grant), plus findings with severity and ready-to-run fix SQL: RLS off, policies written but RLS never enabled, using(true) writes, personal columns readable by anyone, views that bypass RLS, SECURITY DEFINER functions anyone can call, user_metadata in policies, public bucket listing, grants missing after the Oct 30 2026 default change. Also accepts the JSON produced by deadbolt_catalog_query for the live database. Deterministic; never connects to any database. Up to 200,000 characters.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sql": "<sql>"
    },
    "name": "deadbolt_check_supabase_access"
  }
}

Input Schema

Name	Required	Description	Default
`sql`	Yes	Migration SQL (one or many files concatenated, in order), or the single JSON value returned by the catalog query.
`project_created_before_2026_10_30`	No	Only for SQL input. true (default): the project grants new public tables to anon and authenticated automatically (projects created before Oct 30, 2026). false: new tables get no grants unless the SQL grants them (projects created on or after Oct 30, 2026).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent/openWorld annotations, it discloses determinism, that it never connects to a database, the per-role/per-operation result matrix (all rows, own rows, some rows, none, denied for missing grant), and that findings come with severity plus ready-to-run fix SQL. It also states the 200,000 character input ceiling. This is substantial behavioral context not encoded in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the 'Use when...' clause, followed by output description in a single dense second sentence. The parenthetical check-list (RLS off, using(true) writes, SECURITY DEFINER functions, user_metadata, public buckets, etc.) is long but each item tells the agent something actionable, so little is genuinely wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description fully characterizes the return shape (per-table role/operation matrix plus severity-tagged findings and fix SQL) and the input modes. For a deterministic SQL-analysis tool with two parameters, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented, including the concatenation-order semantics of `sql` and the pre/post-Oct-30-2026 grant behavior of `project_created_before_2026_10_30`. The description only restates the catalog-JSON input option and does not add new meaning to either parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: replaying migration SQL under real Postgres rules to determine what anon and authenticated roles can SELECT/INSERT/UPDATE/DELETE per table. It is immediately distinguishable from siblings (catalog_query feeds it data; the other tools concern DNS, email, contrast, JSON, time).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It enumerates concrete trigger conditions (writing/reviewing/applying migration SQL with CREATE TABLE, RLS, CREATE POLICY, GRANT, views, SECURITY DEFINER functions, storage buckets; user asking about exposure or 42501 errors). It also states the companion workflow: it accepts the JSON produced by deadbolt_catalog_query for a live database.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Clawhard Studio tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?