Community Supabase MCP server that enables Cursor and Windsurf to end-to-end manage your Supabase project, execute SQL queries, and more.
Server has 12 tools with complete input schemas and descriptions, but quality is inconsistent. Naming follows verb_noun convention well (get_*, execute_*, retrieve_*, send_*, call_*, confirm_*). However, descriptions are often generic or lack actionable context for LLM selection. Critical security issue: live_dangerously and confirm_destructive_operation expose dangerous state-mutation patterns without proper guardrails. Parameters lack detailed constraints (ranges, formats, enums where applicable). Output schemas are not documented in the source. Error handling guidance is absent. Average tool description ~120 chars, below the 194-char baseline for A+ tools.
Call an Auth Admin method from Supabase Python SDK.
Execute a destructive operation after confirmation. Use this only after reviewing the risks with the user.
Execute PostgreSQL statements against your Supabase database.
Get Python SDK methods specification for Auth Admin.
Get the Supabase Management API specification.
List all database schemas with their sizes and table counts.
live_dangerously and confirm_destructive_operation expose dangerous state-mutation patterns without proper confirmation flow or audit trail. These tools enable irreversible operations (schema changes, data deletion) with minimal guardrails. No dry-run support, no transaction rollback guidance, no audit logging visible in code.
Output schemas are not documented. Tools like get_tables, get_schemas, and retrieve_migrations return complex nested structures, but the response format is not visible in the source. LLMs cannot plan downstream tool calls or extract required fields without documented return types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
Get detailed table structure including columns, keys, and relationships.
List all tables, foreign tables, and views in a schema with their sizes, row counts, and metadata.
Toggle between safe and unsafe operation modes for API or Database services. This function controls the safety level for operations, allowing you to enable write operations for the database (INSERT, UPDATE, DELETE, schema changes) and enable state-changing operations for the Management API.
Retrieve logs from Supabase.
Retrieve a list of all migrations a user has from Supabase.
Execute a Supabase Management API request.
Parameter descriptions lack actionable constraints. 'limit' and 'offset' parameters have no min/max bounds. 'query' parameter in execute_postgresql has no guidance on SQL injection prevention, transaction handling, or result size limits. 'method' in send_management_api_request accepts free-form strings with no enum constraint.
No error recovery guidance. Tools lack descriptions of failure modes, retryability, or next steps. E.g., execute_postgresql offers no guidance on handling connection timeouts, permission errors, or syntax errors. Agents cannot self-correct without explicit error classification.
Naming ambiguity in tool pairs. 'get_management_api_spec' and 'send_management_api_request' are similar but serve different purposes (discovery vs. execution). LLMs may conflate them. Similarly, 'get_auth_admin_methods_spec' and 'call_auth_admin_method' could benefit from clearer distinction (e.g., 'list_auth_admin_methods' vs 'invoke_auth_admin_method').