This server exposes 4 tools via the mcp-use framework, wrapping Supabase's official MCP server. Tool definitions are present with basic schemas and descriptions, but multiple critical gaps prevent production readiness. All tools have descriptions (10-50 chars, meeting the >10 minimum but falling short of the 50-200 char LLM-optimized baseline). Schemas are present but inconsistently detailed. The server properly uses toolAnnotations (readOnlyHint) to mark all tools as read-only, which is correct. However, parameter descriptions are sparse, error handling is minimal, and tool composition lacks idempotency guarantees. The list-tables tool accepts a 'schemas' parameter with description 'Schemas to include (default: all)' but the code hardcodes ['public'], contradicting the schema. The execute-sql tool lacks any constraint on query syntax (e.g., no enforcement of SELECT-only). The show-table tool constructs SQL dynamically without demonstrating input sanitization. The get-project-url tool has no schema definition visible, only a description, making it difficult to assess parameter handling. Per-tool scores average 48.

• Add explicit input schema to get-project-url; document if it accepts any parameters or is parameter-less.
• Enforce read-only SQL in execute-sql by adding a regex pattern requirement (e.g., 'Query must start with SELECT, not INSERT/UPDATE/DELETE') and validate server-side with a clear error message: 'Only SELECT queries allowed. Got: <query>'. Alternatively, use an SQL parser to block destructive statements.
• Fix list-tables to respect the 'schemas' parameter, remove the hardcoded ['public'] and pass the user-provided schemas array to the underlying Supabase client. If the intent is to always list public schema only, remove the parameter from the schema and update the description.
• Add input sanitization to show-table: use parameterized queries or a SQL builder (e.g., knex) to safely construct the SELECT statement instead of template literals. Validate tableName and schema against an allowed-list or regex pattern before interpolation.
• Expand tool descriptions to 50-200 chars, explaining WHEN to call each tool vs. others. Example for execute-sql: 'Execute read-only SQL SELECT queries to retrieve custom data. Use show-table for simple table browsing, or this tool for complex joins and aggregations.'
• Document the output schema for each tool. For list-tables, define: { tables: [{ name: string, schema: string, rowCount?: number }] }. For show-table: { tableName: string, schema: string, columns: string[], rows: any[], totalRows: number }.
• Enhance error messages to classify errors and suggest recovery. Example: 'Query syntax error: <details>. Did you mean to use SELECT? Check syntax at https://... and retry.' Or 'Table not found: <tableName>. Available tables: <list>. Try show_table with one of these.',

Inferred effective spec: 2026-07-28+.

• Current-spec patterns present: tool annotations