[BUG] Remote MCP servers can add outward-facing tools to a trusted connector with no notification or re-consent

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported
• [x] This is a single issue (not multiple)

Problem Statement

A remotely-hosted MCP server can add tools to a connector the user already trusts, including tools in a fundamentally more dangerous effect class, with no notification, no re-consent, and nothing to diff against. The user's permission configuration was written against the toolset as it existed when they configured it, and goes stale silently.

This turns "I approved this connector" into an open-ended grant over whatever that server decides to expose later.

What happened to us. A Gmail connector had been in use for reading threads and creating drafts. At some point it gained send_message. No in-product notice reached the user: no prompt, no changelog surfaced in session, no /mcp diff, and it did not arrive with a client update the user chose to install. The capability simply appeared server-side.

The user had separately enabled bypassPermissions, having formed a mental model of the blast radius — read threads, write drafts — that was accurate when they formed it and silently stopped being accurate.

A session then spent an hour iterating on three client emails, saving each revision as a draft. The user wrote:

Make sure these have smart quotes and let's ship

The assistant read "ship" as authorization, loaded send_message, and was one tool call from sending three emails to external recipients, with a step queued to trash the local drafts afterward. The user interrupted in time. Nothing went out. Under bypassPermissions there was no prompt; the interrupt was the only gate.

Why existing controls don't cover this

alwaysAsk, permissions.deny, and PreToolUse hooks all work — and all are useless here, because every one of them requires naming a tool you know exists. Permission config is written in the past tense against a toolset that can change underneath it.

Wildcards don't rescue it either. mcp__*__send_* catches send_message only if you anticipated that name; it misses forward, dispatch, reply, publish. You cannot pattern-match your way to safety against capabilities that haven't been invented yet.

And there is no local record of a server's tool list anywhere in ~/.claude — only mcp-needs-auth-cache.json, which tracks auth state. So a diligent user who wanted to audit what changed has nothing to compare against.

Notably, tools/list_changed support has been actively improved (#24195, #66869, #62844, #60538) — all aimed at making dynamic tool addition more seamless, with no reconnect required. The delivery mechanism for silent capability change was built and hardened. The consent surface never caught up.

Proposed Solution

In rough priority order:

1. Surface a tool-list diff when a connected server's tools change — at session start and on tools/list_changed. "Gmail added: send_message, forward." Even a one-line notice would have prevented this entirely.
2. Newly-appeared tools default to ask, including under bypassPermissions, until acknowledged once. This solves the unknown-unknown by construction rather than asking users to predict it: a tool nobody has seen yet is exactly the thing that should stop and check.
3. Re-consent when a new tool crosses effect classes — read-only to write, local to outward-facing — rather than inheriting the original grant. Approving a reader is not approving a sender.
4. /mcp shows what changed since last acknowledgment, so an audit is possible after the fact.

(1) and (2) together are probably sufficient. (2) alone would have caught this.

Related

• #85607 (open) — hook ask prompts default to Yes, so a stray Enter publishes. Adjacent: that's a prompt whose default runs the wrong way; this is a capability that never prompted because nobody knew to configure it.
• #10944 (closed, auto-closed after 60 days, no maintainer response) — model widened a Slack target from a DM to #general and messaged a whole company.
• #24195, #66869, #62844, #60538 — the tools/list_changed work that makes silent capability addition function well.

Priority

High - Security and trust

Feature Category

MCP and connectors