Question: should Supabase MCP tool changes require re-approval?

[MaazAhmed47]

Hi, I hope this is okay to ask here. If this is not the right place for a design/security question, feel free to close.

Small MCP runtime-trust question:

For Supabase MCP, once a tool is approved or connected, do you treat later changes to its schema, database access, external reach, side effects, behavior, or auth scope as a re-approval event?

Examples:

• a tool gains a new required parameter
• read-only behavior expands toward mutation
• project/database access scope changes
• external reach is added
• sensitive data exposure increases

I’m trying to understand how MCP builders handle this today.

Would this usually be treated as normal versioning, client-side behavior, gateway behavior, or something Supabase MCP should signal explicitly?

[k1ng-arthur]

For Supabase MCP doesn't it gate behind feature groups instead of individual tools and then also allows restricting to read only? If there are changes to thins like the schema and what not i don't think i would have an impact to say the database tools and how they are used? Please correct me if i'm misunderstanding your point btw

[MaazAhmed47]

Good point, and I should have been clearer.

I don’t mean the database schema changing. I mean the MCP tool surface changing: input schema, required params, tool description/metadata, feature-group membership, read/write behavior, auth scope, or external reach.

Feature groups + read-only mode definitely reduce blast radius. The question I’m trying to understand is: what is the approved object?

If a user/operator approved “database tools in read-only mode,” then ordinary DB schema changes may not matter. But if the MCP tool contract itself changes, or a tool moves into a different feature group, or read-only behavior/auth scope changes, that feels like it may need re-approval or at least a runtime trust event.

So I think my question is really: in Supabase MCP, is trust anchored to the feature group/read-only setting, the individual tool definitions, or both?

[CharlesKahn]

Short answer is that trust is anchored to the feature group config and read-only toggle, both set at connection time. Individual tool definitions can change underneath without triggering re-approval.

The MCP actually does have a spec for this, notifications/tools/list_changed for when tools are added or removed, but most clients don't handle it yet (open bug Claude Code #13646 and Gemini CLI #13850, LibreChat #7117 all have open bugs for this). And even when it works, it only covers tool list changes vs behavioral changes behind the stable interface. So if a tool quietly goes from read-only to read-write but keeps the same name and schema, nothing in the protocol signals that.

Supabase's read-only mode is enforced server-side (actual read-only Postgres user, not a client hint) so that one is solid. But feature group membership and individual tool behavior can shift between sessions without re-approval.

Let me know if that answers your question?

[MaazAhmed47]

Yes, that answers it clearly,
Thanks Charlie.

The distinction you made is exactly what I was trying to get at: Supabase’s read-only mode is enforced server-side, so that part has a strong trust anchor. But feature group membership and individual tool behavior can still shift between sessions without re-approval.
The notifications/tools/list_changed point is helpful too. It seems like it covers tool inventory changes, but not contract/behavior drift behind a stable tool name or schema.
So the gap I’m thinking about is less “did the tool list change?” and more:

“Is the tool still operating inside the same approved trust boundary?”

For example:

• same tool name, but behavior changes
• same feature group, but a tool gains broader capability
• same schema, but server-side behavior changes
• same connection, but auth/data-access boundary changes

Do you think this belongs mostly in MCP clients handling re-approval, the MCP server exposing stronger tool/version metadata, or a gateway/runtime layer tracking baselines between sessions?

[CharlesKahn]

Honestly all three, but leverage is different at each layer.

Server-side metadata is really the foundation. Something like a definitionHash or behaviorVersion on each tool. The server is the only one that actually knows when its own behavior changed, so without it clients and gateways have nothing to diff against. This feels like it should live in the MCP spec itself.

Client-side re-approval is where enforcement happens. Snapshot tool definitions at approval time, diff on reconnect, prompt when something changed, etc. But that only works if the server gives you something meaningful to diff, so the server metadata has to come first.

Gateway/runtime layer is mostly a workaround for servers you don't control. Sits between client and server, tracks baselines across sessions, flags drift. An it's useful but really shouldn't be the primary answer.

The short version: servers need to expose it, clients need to enforce it, gateways are just a stopgap. Right now none of the three are doing it consistently. I'd recommend building a simple tool to audit MCP tool mutations, hash definitions, or detect behavioral drift at runtime. The pattern you're describing (same name, different behavior) is essentially a stochastic-deterministic boundary problem and I've mostly solved it that way.

If this answers your question don't forget to mark it as the answer :)

[MaazAhmed47]

Thanks Charlie, this is a really clear breakdown.

I agree with the order: server-side metadata/versioning is the cleanest long-term fix, client-side re-approval is where enforcement should ideally happen, and the gateway/runtime layer is useful when the server or client does not handle that yet.

That last gap is exactly what I’m exploring with Interlock: a self-hosted runtime trust layer that baselines MCP tools, detects post-approval tool/capability drift, and preserves audit evidence before execution.

I’m not thinking of it as a replacement for MCP-native definitionHash / behaviorVersion style metadata. More like a practical layer for today, especially with third-party MCP servers or mixed agent stacks where you can’t assume consistent server/client enforcement.

Your point about “same name, different behavior” is exactly the pattern I’m trying to make visible.

When you say you mostly solved it as a stochastic-deterministic boundary problem, do you mean combining deterministic schema/hash diffs with runtime behavior/evidence checks?

Repo for context if useful: https://github.com/MaazAhmed47/Interlock

[CharlesKahn]

Not quite runtime behavior checks, more static analysis of where the boundaries are and whether they have verifiers. Different, but similar concept, I built a tool (sdb-sigma) that takes an agent architecture config and scores every point where LLM output becomes a system action. For ex Are there deterministic gates between proposal and commit? Are they architectural or just prompt rules? Which ones are unprotected?

So the schema/hash diffing and runtime evidence stuff you're describing with Interlock is actually the piece I don't cover. Mine is like "audit your architecture before you ship," yours will be "monitor it after deploy."

The paper that got me thinking about this is Srinivasan's A Methodology for Selecting and Composing Runtime Architecture Patterns for Production LLM Agents (https://arxiv.org/abs/2605.20173). She formalizes the boundary contract as four parts (proposer, verifier, commit, reject signal) and I think the framework can map pretty directly to what you're describing with tool drift detection.

[MaazAhmed47]

Thanks, that distinction helps.

Static architecture audit vs runtime drift/evidence is a useful boundary. The proposer / verifier / commit / reject-signal framing seems to map pretty cleanly:

approved MCP tool baseline = expected contract
drift check = verifier
allow/tool execution = commit
deny/quarantine = reject signal

For third-party MCP servers that do not expose definitionHash or behaviorVersion yet, would you treat gateway-computed tool snapshots/hashes as a reasonable interim verifier, or too lossy without server-owned version metadata?

I’ll read the Srinivasan paper. Appreciate the pointer.