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.

Update your AI’s tools without the surprise I built a free tool related to this. You approve an MCP server once, then it updates. The maker can add tools, reword what the AI reads, or change what a tool accepts, and many setups pick it up automatically. What “without the surprise” looks like: before you move to a new version, you see exactly what changed, in two minutes and not two hours. A real example (server not named): I started two versions of one MCP server, twice each, in a sandbox with no internet. Its tool list went from 278 to 311: 33 added, none removed. 8 existing tools changed a description or input schema, and the README didn’t change. I called no tool, so I can’t say what any of it does, and nothing says the maker did anything wrong. The point is that you’d never have seen it. Free, now: paste two tool lists and see added, removed and changed tools, with old and new description text. It runs in your browser: mcp.brydge-ai.com/diff.html Two questions: which servers do you run, and what would make this worth paying for?

You approve an MCP server once, then it updates. The maker can add tools, reword what the AI reads, or change what a tool accepts, and many setups pick it up automatically. What “without the surprise” looks like: before you move to a new version, you see exactly what changed, in two minutes and not two hours. A real example (server not named): I started two versions of one MCP server, twice each, in a sandbox with no internet. Its tool list went from 278 to 311: 33 added, none removed. 8 existing tools changed a description or input schema, and the README didn’t change. I called no tool, so I can’t say what any of it does, and nothing says the maker did anything wrong. The point is that you’d never have seen it. Free, now: paste two tool lists and see added, removed and changed tools, with old and new description text. It runs in your browser: mcp.brydge-ai.com/diff.html If you’d like me to do it for you: send the servers you run and the versions you approved. When one updates, I send you the diff within a day, by hand for now. It’s free the first month, then $19/month for up to 10 servers. What it can’t do: it doesn’t test what a tool does when called, and it doesn’t block anything. Two questions: which servers do you run, and what would make this worth paying for?

A week ago I posted what 67 MCP servers do at startup. The comments weren’t about my numbers. They were about updates: what happens when a server changes after I approve it? Several of you check this by hand. So I built it. Here’s your list, and where each item stands. ✅ “Tell me what changed between versions.” Both versions start twice in a sandbox with no internet. I compare tools, websites reached, programs started and the README. ✅ “Don’t guess.” If a version’s two runs disagree, it says can’t tell. “No change” only prints if both versions started and returned a real tool list, with the counts shown (46 and 46 tools, both runs agreeing). ✅ “Hash the descriptions, not just the names.” Real example from one server’s update: a tool kept its name, but its description grew from 157 to 265 characters and gained a new instruction. A name-only diff says “no change.” This one shows the old and new text. ✅ “Don’t call build noise a change.” My first run said 55 tools changed. 47 were a build stamp in a UI link. It’s now labelled as noise. ✅ “Give me a list I can enforce.” You approve a version, and I save what it offered. On the next update, anything new is labelled “new, not on your list.” I don’t block anything, so your own tools do the enforcing. ✅ “Keep an audit log.” (first version) Every comparison is saved, and a per-package timeline shows each change in order. It shows gaps as unknown, since I only know the versions I measured. Four version pairs it refused to record, because their order couldn’t be known. 🟡 “It has to fire on every version bump.” An hourly job now checks npm for new versions and tells me. Scheduled runs can be late, so I’d say “within a few hours.” I still run the diff and send it by hand. 🟡 “My server isn’t on npm.” Send me two tool-list files from any server and I’ll diff them. I did the same for a maker, from her source. ⬜ “A clean startup isn’t a clean server.” Not built yet. One harmless call on fake data is next. ⬜ “What can it reach once it’s running?” Not built yet.

Every MCP server you add runs on your machine, and every update can change what it does. Here’s the routine I use now, built from what people in this group taught me. Copy it, and it takes five minutes per server. Step 0: Allow by tool name, never by server (Claude Code). mcp__myserver pre-approves everything that server will ever ship, including tools added in an update. mcp__myserver__get_post approves one tool, so a new one still asks first. (Thanks, Aurel.) Heads up: the server name in the rule is the key from your config, not the npm package name. Step 1: Pin the version in the config that starts the server, not only in your notes. "args": ["-y", "[email protected]"], not "args": ["-y", "name"]. A config with no version can run something other than the version you approved, so everything after this step may describe the wrong thing. Step 2: Write the approval down the day you approve it. ServerVersionDateTools offered (names)Websites it reached at startupWho approved Step 3: On every new version, diff before you move up. Check for a newer version with npm view name version. Then compare the two tool lists: new or removed tools, and changed descriptions and input schemas. A name-based rule never re-prompts on those, and the model reads that text to choose a tool. My free page does this comparison in your browser: mcp.brydge-ai.com/diff.html. Paste two lists and it shows old and new text. Step 4: Keep anything new off until someone says yes. Step 5: Try the first run on fake data or a throwaway account. A diff compares what a server says about itself and what it did at startup. It doesn’t test what a tool does when called, so a version can match and still behave differently. (Thanks, Wasilis and Dylan.) Real example, so you know why step 3 matters: I compared two versions of one MCP server, each started twice in a sandbox with no internet. Its tool list went from 278 to 311 (33 added, none removed). 8 existing tools changed a description or schema. The README didn’t change. I called no tool, so I can’t say what any of it does, and nothing says the maker did anything wrong.