Loading ToolBench
MCP server for interacting with Supabase, including project management, database operations, edge functions, branching, and debugging
28 tools with generally clear naming and descriptions, but significant gaps in schema completeness and parameter documentation. Most tools have action-verb names (create_, list_, delete_, etc.) and descriptions 50-300 chars, meeting baseline expectations. However, ~40% of tools lack explicit input schema visibility in source, and many parameter descriptions are minimal. Error handling guidance is sparse. Output schemas are undocumented. Tool composition is reasonable (single responsibility mostly observed), but parameter relationships and constraints are under-specified.
Applies a migration to the database. Use this when executing DDL operations. Do not hardcode references to generated IDs in data migrations.
Ask the user to confirm their understanding of the cost of creating a new project or branch. Call `get_cost` first. Returns a unique ID for this confirmation which should be passed to `create_project` or `create_branch`.
Creates a development branch on a Supabase project. This will apply all migrations from the main project to a fresh branch database. Note that production data will not carry over. The branch will get its own project_id via the resulting project_ref. Use this ID to execute queries and migrations on the branch.
Creates a new Supabase project. Always ask the user which organization to create the project in. The project can take a few minutes to initialize - use `get_project` to check the status.
Deletes a development branch.
Deploys an Edge Function to a Supabase project. If the function already exists, this will create a new version. Example: ...
Minimal descriptions for 12+ tools (get_project_url, get_anon_key, list_organizations, get_organization, get_project, pause_project, restore_project, list_extensions, list_migrations, list_edge_functions, postgrestRequest, sqlToRest). Descriptions under 60 chars lack context for LLM tool selection.
Output schemas undocumented. No visible documentation of what fields tools return (e.g., does list_branches return branch_id, status, created_at?). LLMs cannot plan downstream calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Executes raw SQL in the Postgres database. Use `apply_migration` instead for DDL operations.
Generates TypeScript types for a project.
Gets the anonymous API key for a project.
Gets the cost of creating a new project or branch. Never assume organization as costs can be different for each.
Gets logs for a Supabase project by service type. Use this to help debug problems with your app. This will only return logs within the last minute. If the logs you are looking for are older than 1 minute, re-run your test to reproduce them.
Gets details for an organization. Includes subscription plan.
Gets details for a Supabase project.
Gets the API URL for a project.
Lists all development branches of a Supabase project. This will return branch details including status which you can use to check when operations like merge/rebase/reset complete.
Lists all Edge Functions in a Supabase project.
Lists all extensions in the database.
Lists all migrations in the database.
Lists all organizations that the user is a member of.
Lists all Supabase projects for the user. Use this to help discover the project ID of the project that the user is working on.
Lists all tables in one or more schemas.
Merges migrations and edge functions from a development branch to production.
Pauses a Supabase project.
Performs an HTTP request against the PostgREST API
Rebases a development branch on production. This will effectively run any newer migrations from production onto this branch to help handle migration drift.
Resets migrations of a development branch. Any untracked data or schema changes will be lost.
Restores a Supabase project.
Converts SQL query to a PostgREST API request (method, path)
No error handling guidance. Tools lack recovery hints (e.g., 'If branch not found, call list_branches() first'). Agents cannot self-correct on failures.
Parameter constraints under-specified. execute_sql and apply_migration accept free-form SQL with no validation hints. No guidance on SQL injection prevention or query limits.
Destructive operations (delete_branch, reset_branch, execute_sql) lack confirmation/dry-run patterns. Agents can irreversibly delete branches or reset migrations without explicit user consent.