This Supabase MCP server provides 8 database-oriented tools with consistent naming (verb_noun pattern: db_select, db_insert, db_update, db_delete, db_upsert, db_get_by_id, db_rpc, smoke_ping) and reasonable descriptions. All tools have documented input schemas with parameter types and descriptions. However, several dimensions fall short of A-grade quality: (1) descriptions are generic and lack context about when to use each tool vs alternatives (e.g., db_select vs db_get_by_id distinction unclear), (2) output schemas are completely undocumented, no indication of what fields are returned, (3) parameter descriptions lack concrete constraints (e.g., 'PostgREST filter string' mentions a format but gives no validation rules or examples of what happens on malformed input), (4) error handling guidance is absent, no indication of retryable vs fatal errors, (5) no pagination guidance for tools that could return large result sets (db_select with limit parameter is present but no documentation of max results or truncation behavior). The server is functional and safe (READ_ONLY and WRITE operations properly classified), but lacks the polish and LLM-optimization expected of production-grade agent tools.

• Document output schema for all tools. For each, specify: what fields are returned? Are IDs included? Are timestamps returned as ISO 8601 or Unix? Example: 'db_select returns an array of objects with the selected columns plus any computed fields. Each object includes: {id, column_1, column_2, created_at (ISO 8601), ...}'.
• Add explicit constraint documentation to 'filters' parameter. Example: 'PostgREST filter string using syntax: column=operator.value (operators: eq, gt, lt, gte, lte, like, ilike, in, is). Example: age=gt.18&status=eq.active. Invalid filters return a 400 error with the constraint violation.'
• Document max result limits and pagination strategy. Example: 'db_select returns up to 1000 rows by default. For larger datasets, use limit and offset parameters. Omit limit for unbounded results (use with caution on large tables).'
• Add error handling guidance to each tool description. Example for db_delete: 'If filters match zero rows, no error is raised (idempotent). If filters are ambiguous (e.g., deleted table), returns 400 Bad Request. This operation is irreversible, no rollback is available.'
• Clarify when to use each tool. Example: 'Use db_get_by_id when you have a primary key value (faster, simpler). Use db_select for complex filtering, ordering, or multi-row lookups.'
• For db_rpc, add a discovery mechanism or document the available functions. Example: 'Available RPC functions are defined in your Supabase project. Call db_select on the information_schema.routines table to list functions, or consult your Supabase dashboard. Pass function name and parameters as a JSON object.'