Provides tools to audit Supabase projects for security vulnerabilities, preview and apply SQL fixes, and re-audit to verify fixes.
The only Supabase security tool that closes the loop in your AI agent. Audit, preview the fix, and apply it — without leaving Claude / Cursor / Cline.
You: audit my supabase project rkmrsefraqssuyuniyco
Claude: Found 17 critical leaks. Want me to apply all SQL fixes?
Run preview_fix on each first?
You: preview them all, then apply if safe.
Claude: [previews each]
All 17 fixes preview cleanly. Applying...
Done. Re-audited: 0 critical findings remaining.Other Supabase scanners (SupaExplorer, AuditYourApp, Vibe App Scanner) report. None of them remediate. This one does.
Tool | What it does |
| Scan a project. Returns JSON findings. Caches for follow-up tools. |
| List cached findings, optionally filter by severity. |
| Wrap the fix SQL in |
| Actually apply one finding's fix. Requires |
| Bulk-apply at or above a severity. Single transaction — all or nothing. |
Related MCP server: postgresql-mcp
Add to your MCP config (~/.claude.json or claude_desktop_config.json):
{
"mcpServers": {
"supabase-security": {
"command": "npx",
"args": ["-y", "@perufitlife/supabase-security-mcp@latest"],
"env": {
"SUPABASE_ACCESS_TOKEN": "sbp_your_personal_access_token"
}
}
}
}Get a token at https://supabase.com/dashboard/account/tokens (read+write to your projects).
Settings → MCP → Add new MCP server → paste the same JSON object as above.
Anything that supports MCP stdio servers will work — point it at npx -y @perufitlife/supabase-security-mcp@latest with the env var set.
Never auto-applies. Every apply_fix and apply_all_fixes call requires confirm: true.
Preview before apply. preview_fix runs the SQL inside BEGIN; ... ROLLBACK; so you see if it would error before touching state.
All-or-nothing bulk apply. apply_all_fixes runs everything in a single transaction. If any statement fails, the entire change rolls back.
Re-audit after apply. Every apply_fix re-runs the audit and reports whether the finding is actually gone — protects against fix-that-doesn't-fix.
Read-only by default for audit_project. Token can be a read-only PAT if you only want to scan, never remediate. (For apply_fix, you need write access.)
Inherits all checks from supabase-security-skill:
Tables with RLS disabled and direct anon grants
SECURITY DEFINER functions executable by anon
Public storage buckets
Default privileges still granting CRUD to anon
Auth signups with autoconfirm enabled
Defense-in-depth: RLS-locked tables with stale anon grants
CLIs are great. They're not in your AI agent's context. When you're vibing with Claude in your IDE, asking "is my supabase tight?" should get an actual scan, not a "you should run this command on your laptop."
The flow this enables:
"Add a subscriptions table to my schema." → agent does it
"Now scan for security issues." → agent calls audit_project
Agent notices the new table has no RLS.
"Want to fix?" → preview_fix, then apply_fix after you say yes.
That round-trip is the actual product. The audit is just step 2.
Cron job audit (pg_cron)
Edge function secrets scan
Storage object-level RLS scan
HTML report generation as a tool (returns base64 + filename)
CORS configuration check
MIT.
Bulk-apply all SQL fixes from last audit, optionally filtered by severity. Wraps everything in a single transaction — if any statement fails, everything rolls back. Always preview the count and list before confirming.
| Name | Required | Description | Default |
|---|---|---|---|
| project_ref | Yes | ||
| severity_min | No | Minimum severity to apply (default 'high'). Use 'critical' for safest. | high |
| confirm | Yes | Must be true to actually apply. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the transactional behavior (wraps in single transaction, rolls back on failure) beyond the absent annotations. This is key behavioral information, though permissions or side effects are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, transaction behavior, and usage advice with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and advice but omits return value details (no output schema) and does not reference sibling tools like 'list_findings' or 'preview_fix' for previewing, which is part of the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% with descriptions for severity_min and confirm. The description adds context for severity filtering ('optionally filtered by severity'), but the 'project_ref' param lacks explanation, and the description does not fully compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'bulk-apply' and resource 'all SQL fixes', clearly distinguishing from sibling 'apply_fix' for individual fixes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises to 'Always preview the count and list before confirming', providing a clear usage guideline. However, it does not explicitly state when to use this tool versus alternatives like 'apply_fix'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ACTUALLY APPLY a fix SQL to the project. Requires confirm=true. Always run preview_fix first. Re-runs audit afterward to verify the finding is gone.
| Name | Required | Description | Default |
|---|---|---|---|
| project_ref | Yes | ||
| finding_index | Yes | ||
| confirm | Yes | Must be true to actually apply. Set to false to abort. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool applies changes (destructive), requires confirmation, and triggers an audit. More detail on side effects or permissions could improve, but current transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information: purpose, requirement, and process. No fluff, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the key context: prerequisite (preview_fix), requirement (confirm), and postcondition (audit). It lacks detail on return values or error states but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33% with only confirm described). The description reinforces the confirm requirement but does not add meaning to project_ref or finding_index. While the description adds some value, it does not fully compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'ACTUALLY APPLY a fix SQL to the project' with a strong verb and resource. It distinguishes itself from sibling tools like preview_fix and apply_all_fixes by implying it's for a single fix and requiring a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidelines: requires confirm=true, always run preview_fix first, and re-runs audit afterward. This provides clear when-to-use instructions and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a Supabase project for security issues: RLS gaps, exposed SECURITY DEFINER functions, public buckets, default-privilege leaks, and unsafe auth config. Returns findings JSON. Caches result for use by apply_fix tools.
| Name | Required | Description | Default |
|---|---|---|---|
| project_ref | Yes | Supabase project ref, e.g. 'abcdefghijklmnopqrst' | |
| token | No | Personal Access Token (sbp_...). Optional if SUPABASE_ACCESS_TOKEN env var is set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses caching and output type, but does not mention whether the operation is read-only, auth requirements beyond token, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first defines purpose with concrete examples, second notes output and caching. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes output format vaguely ('findings JSON') and mentions caching for apply_fix tools, but lacks detail on return structure (no output schema) and does not explain how list_findings relates to cached results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal value beyond schema descriptions (e.g., token optional with env var is already in schema). No additional parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it scans a Supabase project for security issues and lists specific categories (RLS gaps, etc.), clearly distinguishing from sibling tools that apply fixes or list findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions caching for use by apply_fix tools, hinting at a workflow, but does not explicitly state when to use versus siblings like list_findings, nor when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List findings from the last audit of a project, optionally filtered by severity. Use after audit_project to inspect specific issues.
| Name | Required | Description | Default |
|---|---|---|---|
| project_ref | Yes | ||
| severity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It conveys that only findings from the 'last audit' are listed, implying a session context. However, it does not describe behavior in edge cases (e.g., no prior audit, multiple audits, result format, pagination, or idempotency). The basic intent is clear but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first sentence defines the operation, second sentence provides usage guidance. No unnecessary words or repetition. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 2 parameters and no output schema, the description covers the basic purpose and usage context. However, it omits details about the expected output (list of findings? fields?), error conditions (no audit found), and what constitutes 'last audit'. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds that 'severity' is an optional filter, which clarifies its purpose. However, 'project_ref' (the required parameter) is not explained; the description only mentions 'a project' without specifying what format or identifier is expected. Partial but insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List findings') and the resource ('from the last audit of a project'), with an optional filter on severity. This distinguishes it from sibling tools like 'audit_project' (which creates the audit) and 'apply_fix' (which applies fixes), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool after 'audit_project' to inspect specific issues. This provides clear sequencing and context, helping the agent decide when to invoke this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview what a fix would change WITHOUT applying it. Wraps the fix SQL in BEGIN; ... ROLLBACK; and returns what would have happened. Safe to call for any finding.
| Name | Required | Description | Default |
|---|---|---|---|
| project_ref | Yes | ||
| finding_index | Yes | 0-based index from list_findings output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool does not apply changes (wrapped in rollback) and is safe. With no annotations, it adequately covers the non-mutating behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple preview tool, but lacks explanation of return format or what 'returns what would have happened' means. No output schema provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, but description adds no meaning for parameters. 'project_ref' lacks description in both schema and description, missing opportunity to explain its role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool previews changes without applying, wrapping fix SQL in BEGIN...ROLLBACK. It distinguishes from siblings like apply_fix by focusing on preview-only behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is safe to call for any finding, implying usage for testing/reviewing. Does not explicitly exclude scenarios or name alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0apply_all_fixesapply_fixaudit_projectlist_findingspreview_fixScored across 5 tools
Each tool has a clear, distinct purpose: auditing, listing findings, previewing fixes, applying a single fix, and bulk-applying fixes. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., audit_project, list_findings, preview_fix, apply_fix, apply_all_fixes), making the API predictable and easy to navigate.
With 5 tools, the server is well-scoped for its purpose of security auditing and fix application. Each tool is necessary, and the count is neither too few nor excessive.
The tool set covers the full workflow: audit, inspect findings, preview fixes, apply individual fixes, and bulk apply. There are no obvious missing operations for this domain.
MCP server for interacting with the Supabase platform
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
