Wasilis said something that stuck with me: “a tool description is basically a prompt. Change one sentence and the model behaves differently, with no code diff to catch it.” So I built the thing that would catch it, and then I tested it on a real client. The setup: Claude Code 2.1.325 on Windows, a planted demo server (four harmless tools I wrote), and a small proxy between them that pins what I approved. 1 to 2 runs per case, so these are observations, not proof. What happened 🔹 A tool was reworded or renamed mid-session. The client kept its cached tool list (the gate’s journal shows it never re-listed). The model still called the tool. The gate refused the call, and the refusal reached the model. It didn’t retry, didn’t try to approve anything, and did the sum itself, labelled as its own. 🔹 A tool was reworded with no notice at all. The call went through, because the gate only learns from a tool list. 🔹 Same case with --verify-on-call. The gate asks the server for its list before forwarding a call. This time it was refused. What it is: an allow-list, not a filter. You pin the tool name plus a hash of each tool’s whole definition. Anything unapproved or changed isn’t passed to the client until you approve it on a local review page (changed words highlighted, hidden characters shown). It scans nothing and scores nothing. What it can’t do • It doesn’t stop the server’s own code. That’s already running. • The first pin is “adopted, not reviewed.” • Tools only (not prompts or resources), and local servers only. • It narrows the gap for a silent change. It doesn’t close it. • I’ve tested one client version and one model. Try it (about 20 minutes, planted demo server only): https://github.com/contactkontey-dotcom/brydge-mcp-measurements/tree/v0.1.0-gate/watch/gate It starts in shadow mode, which hides nothing, and undoing it is removing the gate from your config. Please don’t put it in front of a server you depend on yet.

A few of you told me the same thing in different words. Wasilis: “the initialize instructions land in the model’s context exactly like a tool description, with no pin on it.” So I tested it first, then built the pin. The test (Windows, Claude Code 2.1.325, a planted demo server, one run): 🔹 I put a planted token in a server’s instructions and asked the model, with no tool call, what it had been given. It printed the token back. 🔹 With the gate in enforce mode and the instructions reworded, the model said nothing came with the tools. The gate’s journal showed it had cut the text. 🔹 I approved the new wording on the review page. After a restart, the model quoted it again. What the gate is: an allow-list for local MCP servers. It pins each tool’s whole definition and the server’s instructions string. Anything unapproved or changed isn’t passed to the client until you approve it. It doesn’t scan or score anything. What it can’t do: it doesn’t stop the server’s own code, the first pin is “adopted, not reviewed,” and prompts, resources and tool results aren’t pinned. Local servers only. One client, one model. It’s free and open source (MIT). Try it with the planted demo server, in shadow mode first, which hides nothing: https://github.com/contactkontey-dotcom/brydge-mcp-measurements/tree/v0.2.0-gate/watch/gate Send me the journal file if you run it. It holds counts and tool names, never descriptions. Please don’t send the pending report or the decisions file. What I’m working out now is what could be paid on top. Which of these would you pay for? (a) a check that runs your saved prompts against the old and new tool text and flags only changes that alter the model’s choice (b) shared approvals and history across machines or a team (c) me running the checks and sending you a review page for each update (d) none of these, because the free gate is enough And which client and version do you use?

A few of you said the same thing in different words. Wasilis: “a tool description is basically a prompt. Change one sentence and the model behaves differently, with no code diff to catch it.” Aurel: “remember what I approved, check it on every start, hold anything new until I look at the diff.” So I built it, and then I tested it on a real client. Here’s what happened, including the parts that didn’t work. What it is A small proxy that sits between your client and a local MCP server. You pin the tool list you approved, name plus a hash of each description and schema. It re-checks every tool list. In enforce mode it hides new or changed tools and refuses calls to them, until you approve them on a review page that highlights the changed words and shows hidden characters. What I tested A planted demo server (four harmless tools I wrote myself) in front of Claude Code 2.1.325 on Windows, interactive mode. One or two runs per case, so treat these as observations and not as conclusions. 🔹 A tool dropped mid-session, announced: the client re-listed within about 10 ms. The model never called the gone tool and rerouted. 🔹 A description reworded mid-session, announced: the client kept its cached list. I confirmed in the gate’s journal that it never re-listed. The model called the tool anyway, the gate refused the call, and the model said (paraphrasing) “retrying won’t help, approval is yours to grant.” It didn’t retry, didn’t try to approve anything, and did the sum itself, labelled as its own. Both refusal styles reached the model. 🔹 A tool renamed mid-session, announced: same thing. The client kept the old name, the model called it, the gate refused, and nothing told the model what replaced it. 🔹 A description reworded with no notification: the call went through. The gate only learns what a tool looks like from a tool list, and in the 75 real server sessions I recorded, only 2 ever sent a change notice. So it’s strongest at session start and blind to a silent mid-session change unless it polls. I haven’t built polling.

I'm exploring a product that eliminates manual MCP configuration synchronization. Here's the problem: MCP servers update, tool lists change, and developers have to manually copy, compare and synchronize configurations. Sometimes changes go unnoticed, especially tool description changes that directly influence how AI models understand and use tools. The product I'm considering would: - Remember your last approved MCP tool list and configuration. - Automatically check for changes whenever the server starts. - Generate a diff showing added, removed and modified tools. - Highlight description changes so they receive priority review. - Hold new changes until someone approves them. - Automatically synchronize the approved configuration. Essentially, you wouldn't have to remember to manually maintain your MCP configurations anymore. My questions: 1. Is this a problem you actually experience? 2. Would you pay for a product that eliminates this maintenance? 3. What would make this indispensable rather than just a nice-to-have? 4. What am I missing about how MCP developers currently handle this? I'm looking for honest feedback, especially from people running MCP servers in production.

Three of you asked for the same thing, in different words. Wasilis: “the hold until approved step is what I’d pay for.” Aurel: “remember the list I approved, check it on every start, hold the new version until someone looks at the diff.” Vedant: “flag it only if the change matters.” Nothing below is built yet. I’m asking before I build, so I build the right thing and don’t guess. The idea: a small wrapper sits in front of an MCP server in your config. It remembers the tool list you approved (name plus a hash of the description and input schema). On every start it compares the live list and hides new or changed tools from the AI until you’ve looked at a diff with the changed words highlighted. Description changes come first. What it can’t do: it checks after the server starts, so it doesn’t contain the server’s own code. It keeps the AI from seeing or calling unapproved tools, and that’s all. It starts with local servers that run as a command. Copy this and fill it in: 1. Your client? A) Claude Code B) Claude Desktop C) Cursor or another editor D) your own agents 2. How do you launch servers? A) npx -y name with no version B) pinned version C) Docker D) remote URL E) mixed 3. How many MCP servers do you run? A) 1–3 B) 4–10 C) 11–30 D) more 4. When a tool is new or changed, you’d want it to: A) stay hidden until I approve B) warn me but still work C) depends on the tool 5. Where should it live? A) a wrapper in my config B) a check in CI that fails the upgrade C) a page I open and review D) a report emailed to me 6. What counts as “it matters”? A) any description change B) only if the model’s tool choice or arguments would change (tested on my saved prompts) C) both, ranked 7. Price per watched server per month: A) $5 B) $10 C) $20 D) $40 or more E) I wouldn’t pay. And one sentence: what would make it worth paying for? Bonus: what would stop you from installing something that sits between your client and your server?