Supabase MCP Server

Execute PostgreSQL statements against your Supabase database.

IMPORTANT: All SQL statements must end with a semicolon (;).

OPERATION TYPES AND REQUIREMENTS:

1. READ Operations (SELECT, EXPLAIN, etc.):

   • Can be executed directly without special requirements

   • Example: SELECT * FROM public.users LIMIT 10;

2. WRITE Operations (INSERT, UPDATE, DELETE):

   • Require UNSAFE mode (use live_dangerously('database', True) first)

   • Example: INSERT INTO public.users (email) VALUES ('user@example.com');

3. SCHEMA Operations (CREATE, ALTER, DROP):

   • Require UNSAFE mode (use live_dangerously('database', True) first)

   • Destructive operations (DROP, TRUNCATE) require additional confirmation

   • Example: CREATE TABLE public.test_table (id SERIAL PRIMARY KEY, name TEXT);

MIGRATION HANDLING: All queries that modify the database will be automatically version controlled by the server. You can provide optional migration name, if you want to name the migration.

• Respect the following format: verb_noun_detail. Be descriptive and concise.

• Examples:

  • create_users_table

  • add_email_to_profiles

  • enable_rls_on_users

• If you don't provide a migration name, the server will generate one based on the SQL statement

• The system will sanitize your provided name to ensure compatibility with database systems

• Migration names are prefixed with a timestamp in the format YYYYMMDDHHMMSS

SAFETY SYSTEM: Operations are categorized by risk level:

• LOW RISK: Read operations (SELECT, EXPLAIN) - allowed in SAFE mode

• MEDIUM RISK: Write operations (INSERT, UPDATE, DELETE) - require UNSAFE mode

• HIGH RISK: Schema operations (CREATE, ALTER) - require UNSAFE mode

• EXTREME RISK: Destructive operations (DROP, TRUNCATE) - require UNSAFE mode and confirmation

TRANSACTION HANDLING:

• DO NOT use transaction control statements (BEGIN, COMMIT, ROLLBACK)

• The database client automatically wraps queries in transactions

• The SQL validator will reject queries containing transaction control statements

• This ensures atomicity and provides rollback capability for data modifications

MULTIPLE STATEMENTS:

• You can send multiple SQL statements in a single query

• Each statement will be executed in order within the same transaction

• Example: CREATE TABLE public.test_table (id SERIAL PRIMARY KEY, name TEXT); INSERT INTO public.test_table (name) VALUES ('test');

CONFIRMATION FLOW FOR HIGH-RISK OPERATIONS:

• High-risk operations (DROP TABLE, TRUNCATE, etc.) will be rejected with a confirmation ID

• The error message will explain what happened and provide a confirmation ID

• Review the risks with the user before proceeding

• Use the confirm_destructive_operation tool with the provided ID to execute the operation

IMPORTANT GUIDELINES:

• The database client starts in SAFE mode by default for safety

• Only enable UNSAFE mode when you need to modify data or schema

• Never mix READ and WRITE operations in the same transaction

• For destructive operations, be prepared to confirm with the confirm_destructive_operation tool

WHEN TO USE OTHER TOOLS INSTEAD:

• For Auth operations (users, authentication, etc.): Use call_auth_admin_method instead of direct SQL The Auth Admin SDK provides safer, validated methods for user management

• For project configuration, functions, storage, etc.: Use send_management_api_request The Management API handles Supabase platform features that aren't directly in the database

Note: This tool operates on the PostgreSQL database only. API operations use separate safety controls.