Dynamic MCP Proxy - Deep Dive

From the project's own description (README and setup on GitHub), here's how it works: The proxy starts with only a small, fixed set of **management / meta tools** (like `proxy_handshake`, `proxy_activate_server`, etc.) exposed to the AI agent/IDE. This keeps the initial tool count very low and avoids dumping everything into context upfront. When the agent needs more capabilities, it calls **`proxy_handshake`** and passes in context info: - `tech_stack` (e.g., languages, frameworks, services in use) - `task_description` (what the current goal or prompt is about) The proxy then: - Looks at its **`catalogue.json`** (which lists ~45 public MCP servers out-of-the-box, plus any in your private `user.catalogue.json` overlay) - Each catalogue entry has metadata like `name`, `description`, `tags`, `tech_stack` to help with matching - It runs a **scoring/matching process** to rank how relevant each available MCP server is to the provided tech stack + task - Selects the **top 5** (or a small configurable number) most relevant ones to stay safely under tool limits - **Lazily activates** those servers — typically as stdio subprocesses or via SSE — only when selected - Once activated, their actual tools appear dynamically in the `tools/list` endpoint/resource, so the agent sees and can use them from then on This is all **on-demand / context-triggered**, not pre-loaded. If the context changes significantly later (e.g., new task), another handshake can trigger loading different/more servers. To manage the overall budget long-term (default hard limit: 50 tools total): - It uses **LRU (Least Recently Used) eviction** — when approaching the limit, the proxy automatically deactivates the least-recently-used servers (freeing their tools from context) - You can also manually control this via tools like `proxy_deactivate_server(name)` or `proxy_list_active_servers()` to monitor and adjust Additional helpers: - `proxy_list_available_servers(filter_tag?)` — lets the agent browse/discover what's possible without activating anything - Hot-plug support: drop new MCP servers into `./plugins/`, and the proxy auto-detects/registers them live So in short: **relevance scoring** based on catalogue metadata + the handshake's tech_stack/task_description → top-k selection → lazy activation → LRU for eviction when needed. This keeps context noise low even if you have access to hundreds of potential tools across many servers. https://github.com/SPhillips1337/DynamicMCPProxy