[Idea] MCP server for clash-verge-rev — let AI agents manage proxies and profiles

[bob798]

I've been using clash-verge-rev for around six months. The thing that's worn me down most is orchestrating multiple subscriptions — figuring out merge profiles, getting rule precedence right across them, and editing those profile chains when something doesn't behave the way I expected. Honestly, the only way I get the more advanced parts working at all is by pasting YAML into Claude and asking it to walk me through what's wrong. Doing it from scratch on my own takes longer than I'd like to admit. That experience is what got me thinking about this proposal — if I'm already going to an LLM to help me drive verge, the LLM might as well be able to talk to verge directly.

Most of the decisions I'm actually trying to make — which HK node unlocks Netflix tonight, why github.com is going DIRECT, which JP node has bearable latency right now — are the kind of fuzzy judgment LLMs are genuinely good at. And the operations they'd need to perform (list/select proxy, test delay, query the rule that matched a target, add/update a profile) are exactly the shape MCP is built for.

So I'd like to float an idea: an opt-in, native MCP server inside the Tauri process, so any MCP-compatible client (Claude Desktop, Claude Code, etc.) can drive verge through structured tool calls.

Rough shape I have in mind:

• New src-tauri/src/mcp/ module behind a Cargo feature. Default at runtime is off; nothing happens unless the user flips a switch.
• Streamable HTTP on 127.0.0.1:9099/mcp. Three layers of defense: bearer token (generated on first enable) + Origin allowlist + hard-coded localhost bind. No host field exposed in config so users can't accidentally open it to LAN.
• v1 scope around 22 tools covering proxies, profile CRUD, rule queries, and connection inspection. System-level operations (system proxy, TUN, service install) deliberately deferred to a separate proposal after v1 lands and proves out — those need more careful threat modeling.
• Two new crates: rmcp (official Rust MCP SDK) and schemars, both MIT-licensed. Existing warp is reused, so HTTP server cost is roughly zero. With --no-default-features the module compiles to nothing for users who don't want it.

I wrote a longer design document with the full tool catalog, security model, milestone breakdown, alternatives I considered, and a list of things I'm not sure about. I didn't want to drop a long document on the board without first checking whether this is something the project would consider at all, so it's not linked yet — happy to share as a Gist or push to my fork if the direction has any interest.

Some context on me: I'm a software engineer working mostly in Java and Python, picking up Rust on the side. Not a maintainer. If the direction gets any traction, I'm willing to put together a small PoC patch on my fork (around 200 lines, just list_proxies and select_proxy) as a credibility check before any larger PR work.

A few things I'd genuinely like input on:

• In-process MCP server vs. a separate sidecar binary or external tool. My reasoning for in-process is that subscription management and other verge-specific state isn't reachable from the mihomo external-controller, so an external wrapper can only do half the job. Curious if maintainers see it differently.
• Is "default-off opt-in toggle" the right friction level, or too cautious? Or not cautious enough given the proxy/connection visibility the API would expose locally?
• Anything in the v1 scope above that feels wrong — too much, too little, the wrong tools?

Thanks for reading. Happy to iterate however maintainers prefer.

[Dragon1573]

NO. We won't do this.

• Related 提供面向 Agent 的本地控制接口与使用 Skill #7006
• Related [Feature] 期望为文档增加 MCP 接口，便于大模型结构化读取 #6127

[bob798]

Thanks for the quick response and for pointing me to #7006 and #6127 — I should have searched those before posting, and I see the reasoning is settled. Going to take the fork route instead: building an external MCP server on top of mihomo's external-controller as a community tool, which I think matches the direction suggested in #7006. Appreciate the time, closing this on my end.