Question: Support dynamic runtime registration of existing MCP servers?

[tomek-i]

Hi, this project looks really cool and promising. From the examples, it seems especially useful when you’re creating your own tools as small JS apps.

I’m wondering about a slightly different use case: dynamically wrapping existing MCP servers instead of building new ones.

For example, there is already a GitHub MCP server available. Normally, you would register it conventionally and load all of its tools into the LLM context up front.

Instead, is it possible to do something like this:

• Initially register only a lightweight “meta” tool with the LLM that says:

  “There is a GitHub MCP available. If you need to perform GitHub-related actions, dynamically register it.”

• Then, when the user prompt is something like:

  “Create an issue on GitHub…”

  The system would:

  1. Dynamically register/connect to the GitHub MCP at runtime
  2. Trigger its OAuth flow (popup authentication handled already by the GitHub MCP)
  3. Fetch its available tools after authentication
  4. Invoke the appropriate tool (e.g., create issue)

In other words, can dynamic-mcp act as a lazy loader or runtime registry for already-existing MCP servers, instead of preloading all tools into the LLM context?

Is this supported today? Are there any examples of this pattern?

[unadlib]

Great question, and thank you for the thoughtful use case.

Short answer: this is not supported out of the box today.

dynamic-mcp currently focuses on runtime creation/execution of dynamic JS tools (stored in its own registry), not on acting as a runtime mount/lazy-loader for other MCP servers.

For the pattern you described (lazy attach GitHub MCP only when needed), a few key pieces are missing right now:

1. A first-class concept of an upstream MCP server registry (not just tool code records).
2. Runtime attach/discover/mount/unmount lifecycle for upstream MCP servers.
3. Robust session and tool synchronization between this server and mounted upstream servers.
4. End-to-end OAuth pass-through and callback handling (especially for interactive auth flows).

So today, there is no official example of this exact pattern in this repo.

That said, we agree this is a strong direction:

• It can reduce initial tool injection/context size.
• It can improve UX by loading capability only when needed.

A pragmatic near-term approach is to implement targeted proxy tools for common GitHub actions.
A fuller solution would be a new “upstream MCP lazy-mount” layer (meta-tool + runtime attach + tool projection + auth bridge).

If helpful, we can open a dedicated design issue and sketch an API shape (e.g. upstream.mcp.attach, upstream.mcp.list_tools, upstream.mcp.mount, upstream.mcp.unmount) for discussion.

[tomek-i]

@unadlib Thanks for the detailed reply. I thought that this was the case at the moment.

Docker Desktop has an experimental feature that uses an MCP gateway and interacts with their MCP registry / Catalog. It does make sense that this will be the next step or at least steer in that direction.

If helpful, we can open a dedicated design issue and sketch an API shape (e.g. upstream.mcp.attach, upstream.mcp.list_tools, upstream.mcp.mount, upstream.mcp.unmount) for discussion.

If you believe that it would beneficial to this library and worth experimenting with, then it makes sense.

I came across this library when I started doing some research on dynamically registering MCP's on runtime - there isn't much documentation yet :-D

[unadlib]

@tomek-i We now support an experimental first step toward this pattern(v0.4.0). In enterprise mode (feature-flagged), dynamic-mcp can upstream.mcp.attach to an existing MCP server at runtime (stdio/http), fetch its listTools, and upstream.mcp.detach to release resources. This is guarded by admin token requirements and an attach limit.

What’s still missing: runtime tool mount/projection (mount/unmount), upstream tool invocation proxying, and full OAuth pass-through/callback handling. So it’s a discovery/attachment foundation today, not full lazy-loading of upstream MCP tools yet. If helpful, I can open a design issue for the next phase API and lifecycle.