Supabase MCP Server

List all database schemas with their sizes and table counts.

List all tables, foreign tables, and views in a schema with their sizes, row counts, and metadata.

Provides detailed information about all database objects in the specified schema:

• Table/view names
• Object types (table, view, foreign table)
• Row counts
• Size on disk
• Column counts
• Index information
• Last vacuum/analyze times

Parameters:

• schema_name: Name of the schema to inspect (e.g., 'public', 'auth', etc.)

SAFETY: This is a low-risk read operation that can be executed in SAFE mode.

Get detailed table structure including columns, keys, and relationships.

Returns comprehensive information about a specific table's structure:

• Column definitions (names, types, constraints)
• Primary key information
• Foreign key relationships
• Indexes
• Constraints
• Triggers

Parameters:

• schema_name: Name of the schema (e.g., 'public', 'auth')
• table: Name of the table to inspect

SAFETY: This is a low-risk read operation that can be executed in SAFE mode.

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.

Retrieve a list of all migrations a user has from Supabase.

Returns a list of migrations with the following information:

• Version (timestamp)
• Name
• SQL statements (if requested)
• Statement count
• Version type (named or numbered)

Parameters:

• limit: Maximum number of migrations to return (default: 50, max: 100)
• offset: Number of migrations to skip for pagination (default: 0)
• name_pattern: Optional pattern to filter migrations by name. Uses SQL ILIKE pattern matching (case-insensitive). The pattern is automatically wrapped with '%' wildcards, so "users" will match "create_users_table", "add_email_to_users", etc. To search for an exact match, use the complete name.
• include_full_queries: Whether to include the full SQL statements in the result (default: false)

SAFETY: This is a low-risk read operation that can be executed in SAFE mode.

Execute a Supabase Management API request.

This tool allows you to make direct calls to the Supabase Management API, which provides programmatic access to manage your Supabase project settings, resources, and configurations.

REQUEST FORMATTING:

• Use paths exactly as defined in the API specification
• The {ref} parameter will be automatically injected from settings
• Format request bodies according to the API specification

PARAMETERS:

• method: HTTP method (GET, POST, PUT, PATCH, DELETE)
• path: API path (e.g. /v1/projects/{ref}/functions)
• path_params: Path parameters as dict (e.g. {"function_slug": "my-function"}) - use empty dict {} if not needed
• request_params: Query parameters as dict (e.g. {"key": "value"}) - use empty dict {} if not needed
• request_body: Request body as dict (e.g. {"name": "test"}) - use empty dict {} if not needed

PATH PARAMETERS HANDLING:

• The {ref} placeholder (project reference) is automatically injected - you don't need to provide it
• All other path placeholders must be provided in the path_params dictionary
• Common placeholders include:
  • {function_slug}: For Edge Functions operations
  • {id}: For operations on specific resources (API keys, auth providers, etc.)
  • {slug}: For organization operations
  • {branch_id}: For database branch operations
  • {provider_id}: For SSO provider operations
  • {tpa_id}: For third-party auth operations

EXAMPLES:

1. GET request with path and query parameters: method: "GET" path: "/v1/projects/{ref}/functions/{function_slug}" path_params: {"function_slug": "my-function"} request_params: {"version": "1"} request_body: {}
2. POST request with body: method: "POST" path: "/v1/projects/{ref}/functions" path_params: {} request_params: {} request_body: {"name": "test-function", "slug": "test-function"}

SAFETY SYSTEM: API operations are categorized by risk level:

• LOW RISK: Read operations (GET) - allowed in SAFE mode
• MEDIUM/HIGH RISK: Write operations (POST, PUT, PATCH, DELETE) - require UNSAFE mode
• EXTREME RISK: Destructive operations - require UNSAFE mode and confirmation
• BLOCKED: Some operations are completely blocked for safety reasons

SAFETY CONSIDERATIONS:

• By default, the API client starts in SAFE mode, allowing only read operations
• To perform write operations, first use live_dangerously(service="api", enable=True)
• High-risk operations will be rejected with a confirmation ID
• Use confirm_destructive_operation with the provided ID after reviewing risks
• Some operations may be completely blocked for safety reasons

For a complete list of available API endpoints and their parameters, use the get_management_api_spec tool. For details on safety rules, use the get_management_api_safety_rules tool.

Get the complete Supabase Management API specification.

Returns the full OpenAPI specification for the Supabase Management API, including:

• All available endpoints and operations
• Required and optional parameters for each operation
• Request and response schemas
• Authentication requirements
• Safety information for each operation

This tool can be used in four different ways:

1. Without parameters: Returns all domains (default)
2. With path and method: Returns the full specification for a specific API endpoint
3. With domain only: Returns all paths and methods within that domain
4. With all_paths=True: Returns all paths and methods

Parameters:

• params: Dictionary containing optional parameters:
  • path: Optional API path (e.g., "/v1/projects/{ref}/functions")
  • method: Optional HTTP method (e.g., "GET", "POST")
  • domain: Optional domain/tag name (e.g., "Auth", "Storage")
  • all_paths: Optional boolean, if True returns all paths and methods

Available domains:

• Analytics: Analytics-related endpoints
• Auth: Authentication and authorization endpoints
• Database: Database management endpoints
• Domains: Custom domain configuration endpoints
• Edge Functions: Serverless function management endpoints
• Environments: Environment configuration endpoints
• OAuth: OAuth integration endpoints
• Organizations: Organization management endpoints
• Projects: Project management endpoints
• Rest: RESTful API endpoints
• Secrets: Secret management endpoints
• Storage: Storage management endpoints

This specification is useful for understanding:

• What operations are available through the Management API
• How to properly format requests for each endpoint
• Which operations require unsafe mode
• What data structures to expect in responses

SAFETY: This is a low-risk read operation that can be executed in SAFE mode.

Get Python SDK methods specification for Auth Admin.

Returns a comprehensive dictionary of all Auth Admin methods available in the Supabase Python SDK, including:

• Method names and descriptions
• Required and optional parameters for each method
• Parameter types and constraints
• Return value information

This tool is useful for exploring the capabilities of the Auth Admin SDK and understanding how to properly format parameters for the call_auth_admin_method tool.

No parameters required.

Call an Auth Admin method from Supabase Python SDK.

This tool provides a safe, validated interface to the Supabase Auth Admin SDK, allowing you to:

• Manage users (create, update, delete)
• List and search users
• Generate authentication links
• Manage multi-factor authentication
• And more

IMPORTANT NOTES:

• Request bodies must adhere to the Python SDK specification
• Some methods may have nested parameter structures
• The tool validates all parameters against Pydantic models
• Extra fields not defined in the models will be rejected

AVAILABLE METHODS:

• get_user_by_id: Retrieve a user by their ID
• list_users: List all users with pagination
• create_user: Create a new user
• delete_user: Delete a user by their ID
• invite_user_by_email: Send an invite link to a user's email
• generate_link: Generate an email link for various authentication purposes
• update_user_by_id: Update user attributes by ID
• delete_factor: Delete a factor on a user

EXAMPLES:

1. Get user by ID: method: "get_user_by_id" params: {"uid": "user-uuid-here"}
2. Create user: method: "create_user" params: { "email": "user@example.com", "password": "secure-password" }
3. Update user by ID: method: "update_user_by_id" params: { "uid": "user-uuid-here", "attributes": { "email": "new@email.com" } }

For complete documentation of all methods and their parameters, use the get_auth_admin_methods_spec tool.

Toggle unsafe mode for either Management API or Database operations.

WHAT THIS TOOL DOES: This tool switches between safe (default) and unsafe operation modes for either the Management API or Database operations.

SAFETY MODES EXPLAINED:

1. Database Safety Modes:
   • SAFE mode (default): Only low-risk operations like SELECT queries are allowed
   • UNSAFE mode: Higher-risk operations including INSERT, UPDATE, DELETE, and schema changes are permitted
2. API Safety Modes:
   • SAFE mode (default): Only low-risk operations that don't modify state are allowed
   • UNSAFE mode: Higher-risk state-changing operations are permitted (except those explicitly blocked for safety)

OPERATION RISK LEVELS: The system categorizes operations by risk level:

• LOW: Safe read operations with minimal impact
• MEDIUM: Write operations that modify data but don't change structure
• HIGH: Operations that modify database structure or important system settings
• EXTREME: Destructive operations that could cause data loss or service disruption

WHEN TO USE THIS TOOL:

• Use this tool BEFORE attempting write operations or schema changes
• Enable unsafe mode only when you need to perform data modifications
• Always return to safe mode after completing write operations

USAGE GUIDELINES:

• Start in safe mode by default for exploration and analysis
• Switch to unsafe mode only when you need to make changes
• Be specific about which service you're enabling unsafe mode for
• Consider the risks before enabling unsafe mode, especially for database operations
• For database operations requiring schema changes, you'll need to enable unsafe mode first

Parameters:

• service: Which service to toggle ("api" or "database")
• enable_unsafe_mode: True to enable unsafe mode, False for safe mode (default: False)

Examples:

1. Enable database unsafe mode: live_dangerously(service="database", enable_unsafe_mode=True)
2. Return to safe mode after operations: live_dangerously(service="database", enable_unsafe_mode=False)
3. Enable API unsafe mode: live_dangerously(service="api", enable_unsafe_mode=True)

Note: This tool affects ALL subsequent operations for the specified service until changed again.

Execute a destructive database or API operation after confirmation. Use this only after reviewing the risks with the user.

HOW IT WORKS:

• This tool executes a previously rejected high-risk operation using its confirmation ID
• The operation will be exactly the same as the one that generated the ID
• No need to retype the query or api request params - the system remembers it

STEPS:

1. Explain the risks to the user and get their approval
2. Use this tool with the confirmation ID from the error message
3. The original query will be executed as-is

PARAMETERS:

• operation_type: Type of operation ("api" or "database")
• confirmation_id: The ID provided in the error message (required)
• user_confirmation: Set to true to confirm execution (default: false)

NOTE: Confirmation IDs expire after 5 minutes for security