Skip to main content
Glama
Sign In

VibeScale

by io.github.Ranqint
OverviewDiscussionsAdmin

Check Supabase SQL for row level security gaps

lint_supabase_rls
Read-onlyIdempotent

Reads Supabase SQL (migrations or a schema dump) as text and lists tables in exposed schemas without row level security, RLS with no policy, policies that allow everything or read user_metadata, policies without a role, write grants to anon, SECURITY DEFINER functions and views, new tables without a grant, and public storage buckets, each with SQL that fixes it. Use when someone asks whether their Supabase database is locked down, or before launching an app that uses Supabase. The SQL is never executed or stored; policy logic (who should see what) is not judged. Findings are in Hebrew.

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": "lint_supabase_rls"
  }
}

Input Schema

NameRequiredDescriptionDefault
sqlYesThe SQL text: one or more migration files or a schema dump

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, but the description adds material context the annotations cannot: the SQL is never executed or stored, policy intent is explicitly not judged, and findings are delivered in Hebrew. Those are exactly the behavioral details an agent needs before promising an outcome.

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?

The lead sentence front-loads the verb and resource, but the finding enumeration is long and runs the sentence well past a comfortable length. The caveats and usage trigger that follow are short and each carries real information, so little is 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?

For a single-parameter, no-output-schema analyzer, the description covers what goes in, what comes out (findings with remediation SQL, in Hebrew), and the key limitation (no policy judgment, no execution or storage). Nothing an agent needs in order to call it and set expectations is missing.

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?

There is a single required parameter already documented at 100% schema coverage, including the 200000 maxLength. The description only paraphrases the input as "migrations or a schema dump," adding slightly on multi-file input but nothing on format or encoding beyond what the schema states.

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 opens with a specific verb and resource ("Reads Supabase SQL... and lists tables in exposed schemas without row level security") and then enumerates the exact finding categories it produces. This is far more than a restatement of the name and lets an agent distinguish it from check_env_exposure or scan_app_launch_readiness without opening any schema.

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

Usage Guidelines4/5

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

It gives two concrete triggering situations: someone asking whether their Supabase database is locked down, or pre-launch of a Supabase app. It does not name an alternative tool or state when not to use it, so the routing guidance is clear but not exhaustive.

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

All VibeScale toolsInspect
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