: Offers clear methods with proper validation and error handling

Response format:
- All methods return structured Python objects instead of raw dictionaries
- Object attributes can be accessed using dot notation (e.g., user.id instead of user["id"])
Edge cases and limitations:
- UUID validation: Many methods require valid UUID format for user IDs and will return specific validation errors
- Email configuration: Methods like invite_user_by_email and generate_link require email sending to be configured in your Supabase project
- Link types: When generating links, different link types have different requirements:
- signup links don't require the user to exist
- magiclink and recovery links require the user to already exist in the system
- Error handling: The server provides detailed error messages from the Supabase API, which may differ from the dashboard interface
- Method availability: Some methods like delete_factor are exposed in the API but not fully implemented in the SDK

Automatic Versioning of Database Changes

"With great power comes great responsibility." While execute_postgresql tool coupled with aptly named live_dangerously tool provide a powerful and simple way to manage your Supabase database, it also means that dropping a table or modifying one is one chat message away. In order to reduce the risk of irreversible changes, since v0.3.8 the server supports: - automatic creation of migration scripts for all write & destructive sql operations executed on the database - improved safety mode of query execution, in which all queries are categorized in: - safe type: always allowed. Includes all read-only ops. - writetype: requires write mode to be enabled by the user. - destructive type: requires write mode to be enabled by the user AND a 2-step confirmation of query execution for clients that do not execute tools automatically.

Universal Safety Mode

Since v0.3.8 Safety Mode has been standardized across all services (database, API, SDK) using a universal safety manager. This provides consistent risk management and a unified interface for controlling safety settings across the entire MCP server.

All operations (SQL queries, API requests, SDK methods) are categorized into risk levels: - Low risk: Read-only operations that don't modify data or structure (SELECT queries, GET API requests) - Medium risk: Write operations that modify data but not structure (INSERT/UPDATE/DELETE, most POST/PUT API requests) - High risk: Destructive operations that modify database structure or could cause data loss (DROP/TRUNCATE, DELETE API endpoints) - Extreme risk: Operations with severe consequences that are blocked entirely (deleting projects)

Safety controls are applied based on risk level: - Low risk operations are always allowed - Medium risk operations require unsafe mode to be enabled - High risk operations require unsafe mode AND explicit confirmation - Extreme risk operations are never allowed

How confirmation flow works

Any high-risk operations (be it a postgresql or api request) will be blocked even in unsafe mode. Every high-risk operation is blocked You will have to confirm and approve every high-risk operation explicitly in order for it to be executed. Explicit approval is always required

Changelog

📦 Simplified installation via package manager - ✅ (v0.2.0)
🌎 Support for different Supabase regions - ✅ (v0.2.2)
🎮 Programmatic access

Categories

Current Category: cursor windsurf

Supabase MCP Server