get_schemas
List all database schemas with their sizes and table counts.
Try it
get_tables
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.
Try it
get_table_schema
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.
Try it
execute_postgresql
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.
Try it
retrieve_migrations
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.
Try it
send_management_api_request
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.
Try it
get_management_api_spec
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.
Try it
get_auth_admin_methods_spec
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.
Try it
call_auth_admin_method
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.
Try it
live_dangerously
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.
Try it
confirm_destructive_operation
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
Try it
retrieve_logs
Retrieve logs from your Supabase project's services for debugging and monitoring.
Returns log entries from various Supabase services with timestamps, messages, and metadata.
This tool provides access to the same logs available in the Supabase dashboard's Logs & Analytics section.
AVAILABLE LOG COLLECTIONS:
- postgres: Database server logs including queries, errors, warnings, and system messages
- api_gateway: API requests, responses, and errors processed by the Kong API gateway
- auth: Authentication and authorization logs for sign-ups, logins, and token operations
- postgrest: Logs from the RESTful API service that exposes your PostgreSQL database
- pooler: Connection pooling logs from pgbouncer and supavisor services
- storage: Object storage service logs for file uploads, downloads, and permissions
- realtime: Logs from the real-time subscription service for WebSocket connections
- edge_functions: Serverless function execution logs including invocations and errors
- cron: Scheduled job logs (can be queried through postgres logs with specific filters)
- pgbouncer: Connection pooler logs
PARAMETERS:
- collection: The log collection to query (required, one of the values listed above)
- limit: Maximum number of log entries to return (default: 20)
- hours_ago: Retrieve logs from the last N hours (default: 1)
- filters: List of filter objects with field, operator, and value (default: [])
Format: [{"field": "field_name", "operator": "=", "value": "value"}]
- search: Text to search for in event messages (default: "")
- custom_query: Complete custom SQL query to execute instead of the pre-built queries (default: "")
HOW IT WORKS:
This tool makes a request to the Supabase Management API endpoint for logs, sending
either a pre-built optimized query for the selected collection or your custom query.
Each log collection has a specific table structure and metadata format that requires
appropriate CROSS JOIN UNNEST operations to access nested fields.
EXAMPLES:
1. Using pre-built parameters:
collection: "postgres"
limit: 20
hours_ago: 24
filters: [{"field": "parsed.error_severity", "operator": "=", "value": "ERROR"}]
search: "connection"
2. Using a custom query:
collection: "edge_functions"
custom_query: "SELECT id, timestamp, event_message, m.function_id, m.execution_time_ms
FROM function_edge_logs
CROSS JOIN unnest(metadata) AS m
WHERE m.execution_time_ms > 1000
ORDER BY timestamp DESC LIMIT 10"
METADATA STRUCTURE:
The metadata structure is important because it determines how to access nested fields in filters:
- postgres_logs: Use "parsed.field_name" for fields like error_severity, query, application_name
- edge_logs: Use "request.field_name" or "response.field_name" for HTTP details
- function_edge_logs: Use "function_id", "execution_time_ms" for function metrics
NOTE FOR LLM CLIENTS:
When encountering errors with field access, examine the error message to see what fields are
actually available in the structure. Start with basic fields before accessing nested metadata.
SAFETY CONSIDERATIONS:
- This is a low-risk read operation that can be executed in SAFE mode
- Requires a valid Supabase Personal Access Token to be configured
- Not available for local Supabase instances (requires cloud deployment)
Try it
