Dynamic MCP tool list updates without rebuilding the compiled graph?

[Yashwanth (yash025)]

We're running a LangGraph agent that loads MCP tools once at startup via MultiServerMCPClient.get_tools(), classifies them, and compiles them into a StateGraph with bind_tools() on the LLM. The graph is long-lived across many requests.

When the MCP server adds or removes tools, we currently need to rebuild and recompile the entire graph — which means re-binding the LLM, recreating all middleware nodes, and swapping the graph reference. This feels heavy.

Is there a pattern in LangGraph / the new langchain[mcp] MCPAdapter to handle tool list changes without a full graph recompile? Specifically we're wondering:

1. Can the ToolNode (or a custom node) resolve tools dynamically at call-time from a mutable registry, while the LLM's tool binding is handled separately per-turn?
2. Is there a supported way to re-bind tools to the LLM on each invocation without recompiling the graph (e.g., via RunnableConfig / configurable)?

We saw issue #33808 which seems to be the right ask, but wanted to check if there's a recommended workaround in the meantime.

Transport: streamable_http. Using langchain-mcp-adapters==0.3.1.

[Ryu (ryux1)]

Yes — the graph topology does not need to be rebuilt just because the MCP tool registry changes. What must change together is (1) the tools exposed to the model and (2) the tool implementation used when the resulting call is executed.

For current LangChain agents, runtime tool registration is the supported route: use model-call middleware to load the current MCP snapshot and return request.override(tools=tools), then tool-call middleware to resolve the requested name from that same snapshot and return handler(request.override(tool=resolved_tool)). This lets the underlying ToolNode execute a tool that was not in the original static list. The relevant docs are under dynamic tools in the agents guide, and the implementation support is in ToolNode.

For a manually assembled StateGraph, the equivalent pattern is:

• model node: fetch an immutable/versioned registry snapshot, then call model.bind_tools(snapshot.tools)
• execution node: resolve the tool call against that exact snapshot/version, not an independently refreshed registry
• refresh layer: atomically replace snapshots on TTL, polling, or explicit invalidation

That last point prevents a race where the model sees schema v1 but the executor runs a same-named v2 tool (or the tool disappears). If a call references a removed/stale version, fail explicitly and send the refreshed tool list through another model turn.

RunnableConfig is useful for passing a tenant/registry key, but it is not itself a mutation API for an already-created static ToolNode. If you retain a ToolNode(tools=[...]) built once, it remains static; use the middleware route or a custom dynamic resolver node.

Also, with langchain-mcp-adapters==0.3.1, do not assume server-pushed tool-list invalidation. Notification/progress support is still tracked in langchain-mcp-adapters#435, so a practical implementation should cache per server/auth scope and refresh by TTL/polling/manual signal. Handle name collisions and prevent one tenant or untrusted server from replacing another tenant tool.

So: rebind per invocation (or per cached registry version), keep compilation, and make model exposure + execution resolution use one atomic snapshot.

[Gautam Vhavle (GautamVhavle)]

You do not need to recompile the StateGraph when the MCP server adds or drops tools. The compiled topology (model node, tool node, edges) can stay put. What has to stay in sync, on each turn, is:

1. the tool schemas you bind on the model for that call
2. the implementation the tool node uses when the model emits a call

langchain-mcp-adapters==0.3.1 + a long-lived compiled graph is the older shape. Two options.

Stay on StateGraph (closest to what you have)

Keep a process-wide registry. Refresh it on a timer or on MCP list_changed. Bind at call time, not at compile() time.

registry: dict[str, Any] = {}

async def refresh():
    tools = await client.get_tools()
    registry.clear()
    registry.update({t.name: t for t in tools})

# per request / per turn
bound_llm = llm.bind_tools(list(registry.values()))

bind_tools returns a new runnable. It does not mutate the compiled graph, so you should not call graph.compile() again. For execution, build ToolNode(list(registry.values())) from the same snapshot you just bound, or a tiny custom node that does registry[name].ainvoke(args). If bind and execute drift, you get "tool X not found" on a name the model just picked.

Current LangChain agents path

If you can move the agent to create_agent, runtime MCP tools are a documented middleware pair: wrap_model_call adds the current snapshot with request.override(tools=...), and wrap_tool_call resolves the name with request.override(tool=resolved). That is the "Runtime tool registration" section here: https://docs.langchain.com/oss/python/langchain/tools#dynamic-tool-selection

MCPAdapter.list_tools() from langchain[mcp] is meant to feed that pattern. Issue langchain-ai/langchain#33808 is still the right feature request for "adapter handles list_changed for you." Until that lands, refresh the snapshot yourself.

I have not run this exact refresh loop against langchain-mcp-adapters==0.3.1 over streamable_http. If list_changed is not forwarded on that transport, poll get_tools() on a timer instead of waiting for a notification.