Hi! I’m working on audit-mcp, a local CLI that reviews MCP tool surfaces for discoverability issues: overlapping tools, unclear primary vs follow-up actions, weak trigger language, and places where agents may not have enough signal to pick the right tool.
I ran it against the Supabase MCP tools/list surface locally from this repo. I used a dummy PAT only to list tools; no tool calls were executed.
This is not a bug report. It’s a tool-surface audit in case the feedback is useful.
Summary
- Tools exposed: 29
- Default-visible tools recommended by audit: 22
- Admin/destructive tools recommended out of default surface: 7
- Average discoverability score: 50.2
- Top recommendation: clarify trigger/safety language around project/branch/database mutation tools.
Findings that looked actionable
The audit flagged these tools as candidates for admin/explicit-action surfaces rather than competing in the ordinary default tool set:
apply_migrationexecute_sqldeploy_edge_functiondelete_branchmerge_branchrebase_branchreset_branch
I know Supabase already supports read_only, project_ref, and features, so this may already be partially addressed by configuration. The audit’s point is more about the “default/no-query-param” activation surface: agents may see a broad set of account, database, branching, function, and debugging tools at once.
A few specific patterns the audit noticed:
- Branching tools overlap heavily in naming and descriptions:
create_branch, list_branches, delete_branch, merge_branch, reset_branch, rebase_branch.
execute_sql and apply_migration are well-distinguished in the description, but both are high-impact and may benefit from even stronger safety/confirmation language in the tool description or annotations.pause_project / restore_project scored poorly because the names are clear but the descriptions are short for high-impact actions.get_advisors has a long description and may be harder for models to scan compared with a tighter Use when / Returns / Safety structure.
Possible direction
The report’s suggested shape was:
- Core/default: read/search/discovery tools like docs search, list/get project info, table/schema inspection, logs/advisors.
- Admin/destructive: migrations, raw SQL writes, edge function deploys, branch mutation, project lifecycle actions.
- Contextual/follow-up: confirmation/cost tools that only need to appear once the agent is already in a creation workflow.
Example rewrite pattern:
Use when: the agent needs to inspect database schema before proposing a change.
Returns: table names and compact schema metadata.
Do not use when: the task requires executing SQL or applying migrations.
Safety: read-only; use before `execute_sql` or `apply_migration`.
Why I’m sharing
I’m trying to learn whether MCP maintainers find this kind of tool-surface feedback useful or noisy. If this is off-base because the hosted/default configuration differs from the local tools/list, I’d love to know. If useful, I’m curious whether a warn-only CI/report artifact would fit your workflow.
Hi! I’m working on
audit-mcp, a local CLI that reviews MCP tool surfaces for discoverability issues: overlapping tools, unclear primary vs follow-up actions, weak trigger language, and places where agents may not have enough signal to pick the right tool.I ran it against the Supabase MCP
tools/listsurface locally from this repo. I used a dummy PAT only to list tools; no tool calls were executed.This is not a bug report. It’s a tool-surface audit in case the feedback is useful.
Summary
Findings that looked actionable
The audit flagged these tools as candidates for admin/explicit-action surfaces rather than competing in the ordinary default tool set:
apply_migrationexecute_sqldeploy_edge_functiondelete_branchmerge_branchrebase_branchreset_branchI know Supabase already supports
read_only,project_ref, andfeatures, so this may already be partially addressed by configuration. The audit’s point is more about the “default/no-query-param” activation surface: agents may see a broad set of account, database, branching, function, and debugging tools at once.A few specific patterns the audit noticed:
create_branch,list_branches,delete_branch,merge_branch,reset_branch,rebase_branch.execute_sqlandapply_migrationare well-distinguished in the description, but both are high-impact and may benefit from even stronger safety/confirmation language in the tool description or annotations.pause_project/restore_projectscored poorly because the names are clear but the descriptions are short for high-impact actions.get_advisorshas a long description and may be harder for models to scan compared with a tighterUse when / Returns / Safetystructure.Possible direction
The report’s suggested shape was:
Example rewrite pattern:
Why I’m sharing
I’m trying to learn whether MCP maintainers find this kind of tool-surface feedback useful or noisy. If this is off-base because the hosted/default configuration differs from the local tools/list, I’d love to know. If useful, I’m curious whether a warn-only CI/report artifact would fit your workflow.