Supabase MCP server for per-project Supabase integration with Claude Code. Manages Personal Access Tokens in OS keychain, provides project/branch information, and handles authentication headers.
This bash MCP server has critical definition quality gaps. Tool descriptions are present but generic (avg ~60 chars, below the 194-char baseline). Input schemas are visible in the source but lack proper JSON Schema structure, parameters are documented as strings with informal descriptions rather than typed schema objects. No output schemas are documented. Parameter descriptions are minimal and lack constraints (enums, ranges, formats). Error handling is absent from tool definitions. The 'account' tool combines multiple subcommands (add|list|remove|default) into one tool, violating single-responsibility. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Keychain token handling is secure (server-side injection), but the tool interface exposes account names as free-form strings without validation hints.
Manage Supabase accounts: add, list, remove, or set default account
List branches for a project
Print Authorization header for a given account (reads token from keychain)
Install supa-mcp to PATH and check dependencies
Link current directory to a Supabase project
List all projects for an account
Show current directory's Supabase project binding and account
Fast local status line for SessionStart hook (no network)
Tool 'account' combines four subcommands (add|list|remove|default) into one tool, violating single-responsibility principle. LLMs cannot infer which subcommand to use without explicit guidance.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., project_ref from projects list). Baseline: 100% of A+ tools document return types.
Input schemas lack proper JSON Schema structure. Parameters documented as informal strings ('account name') rather than typed objects with constraints. No enums for 'mode' (ro|rw) or 'subcommand' values.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk levels. 'account' (WRITE), 'link' (WRITE), 'unlink' (WRITE) should be marked destructive; read-only tools should be annotated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Unlink current directory from Supabase project
Show current account and its projects
Parameter descriptions are minimal and lack actionable constraints. E.g., 'Account name' does not explain valid format, length, or character restrictions. Baseline: 94% of A+ tools have detailed param descriptions.