Loading ToolBench
MCP server for interacting with Supabase CLI commands and managing Supabase projects
This server demonstrates significant gaps in definition quality. While tool names follow verb_noun conventions and all tools have basic descriptions, the descriptions are frequently copied/duplicated (e.g., get_supabase_status and list_supabase_projects both claim 'Returns a list of supabase projects that are associated with the logged in user'), parameter descriptions are sparse or missing entirely, and there is no documented output schema. Input schemas are present but incomplete, many parameters lack type information beyond 'string'. The help command implementation has a logic error (command != "" but then uses {command} placeholder). Critical security issue: credentials (dbPass, token) are passed as tool parameters rather than being injected server-side. No error classification, recovery guidance, or structured output documented. The tool set conflates concerns (e.g., login_supabase handles authentication AND credential naming). Per-tool scores average to 32.
Creates a new supabase project on the remote Supabase instance
Get supabase CLI usage information
Returns a list of supabase projects that are associated with the logged in user
Initializes Supabase project configuration
Links a Supabase project from the Supabase platform to the current project's working directory
Returns a list of supabase projects that are associated with the logged in user
Credentials exposed as tool parameters (dbPass, token). These should never be passed as parameters, they end up in agent logs and traces. Use server-side secret injection via environment variables.
Duplicate/incorrect tool descriptions. get_supabase_status and list_supabase_projects both claim 'Returns a list of supabase projects that are associated with the logged in user', clearly copy-pasted and inaccurate for get_supabase_status (should describe status of a specific project). This confuses LLMs about which tool to use.
No documented output schema. Tools return a dict with 'success', 'output', 'exit_code' (from execute_supabase_command), but this is never documented. LLMs cannot plan downstream tool calls or extract specific fields without schema documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Authenticate using an access token
Fetch migration files from history table
List local and remote migrations
Create an empty migration script
Repair the migration history table
Squash migrations to a single file
Apply pending migrations to local database
Pushes local DB changes to the linked project's remote database
Missing parameter descriptions. Most tools have parameters with no description field, e.g., 'workingDir' in get_supabase_status has no description of what working directory means or how to provide it. Parameter names alone are insufficient for LLM reasoning.
No error handling or recovery guidance. Raw command output (stdout/stderr) is returned as 'output' with no parsing, categorization, or actionable next steps. A failed command returns exit_code=-1 with a generic message, the LLM cannot determine if it should retry, ask the user, or fail gracefully.
Destructive operations (create_supabase_project_remote, migration_repair, migration_squash, login_supabase) lack confirmation/dry-run patterns. An LLM could irreversibly damage a database without user approval.
Logic error in get_supabase_help: condition checks 'command != ""' but then unconditionally tries to format '{} --help' with no interpolation, causing command to be malformed.
Tool descriptions under 20 characters or too generic. 'Get supabase CLI usage information' (40 chars) is minimal; 'Returns a list of supabase projects that are associated with the logged in user' does not explain WHEN to use this tool vs others, or what makes it distinct.
No input validation or constraints. Parameters accept free-form strings with no regex, enum, or length limits. An LLM could pass an invalid region or org ID with no guardrails.
No pagination or result limiting documented. If migration_list returns hundreds of migrations, the output would blow the context window. No mention of limits or pagination support.
Tool composition concern: login_supabase conflates authentication (setting credentials) with token naming. This combines two concerns. Consider splitting into login_with_token and optionally set_token_name.