read-only stdio mode still exposes mutating tools in tools/list

[EmersonZh]

Hi Supabase team,

While testing MCP server safety and CI-linting checks, I noticed a possible mismatch between the documented read-only behavior and the stdio tools/list output.

The README says read_only=true disables mutating tools such as apply_migration, deploy_edge_function, delete_branch, and update_storage_config:

• https://github.com/supabase-community/supabase-mcp/blob/main/README.md#read-only-mode

When running the npm stdio package with --read-only, tools/list still exposes mutating tools. For example, apply_migration appears in the tool list and is annotated with readOnlyHint: false / destructiveHint: true.

Reproduction

Run the stdio server in read-only mode:

SUPABASE_ACCESS_TOKEN=sbp_mock_for_schema_only \
  npx -y @supabase/mcp-server-supabase@0.8.1 --read-only

Then connect with an MCP client or the MCP Inspector and call tools/list.

Observed tool names include:

apply_migration
deploy_edge_function
create_branch
delete_branch
merge_branch
reset_branch
rebase_branch

apply_migration appears with annotations like:

{
  "name": "apply_migration",
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true
  }
}

Expected

If stdio --read-only is intended to mirror remote read_only=true, mutating tools should probably be removed from tools/list, not only rejected at call time.

If the current behavior is intentional, it would be helpful to document the distinction:

• remote read_only=true filters mutating tools from the visible inventory;
• stdio --read-only exposes mutating tools but rejects them when called.

Why this matters

For MCP clients and CI linting, tools/list is the main machine-readable source of truth. If destructive tools are visible in a read-only profile, agents may still plan around them even if the server rejects the call later.

mcp-lint context

V0 of mcp-lint is ready at https://github.com/agentsnative/mcp-lint. It is a CI linter for MCP servers that checks installability, tool schemas, annotations, read-only profiles, secret handling, and high-risk tool configuration. This finding is the kind of signal mcp-lint is designed to catch automatically before releases.

Would you be interested in trying the V0 mcp-lint report for this repo? I would be happy to run it against the server and share the output in an issue or PR.

[gregnr]

Hey @EmersonZh thanks for the issue. The current behaviour is expected but (I agree) confusing. Right now the mutating tools are exposed but reject the operation when invoked. Originally we wanted to continue exposing them so that LLMs were aware that they exist, giving them more information about what was possible (e.g. if the user didn't realize they were in read only mode). I agree this is confusing though and omitting the tools entirely is a better default.

Looks like #283 addresses this. At first glance we may need to tweak the approach, but regardless this is on the radar.