Add runtime-configurable tool support to ToolNode

[AydarDD]

Feature Request: Runtime-Configurable Tools for ToolNode

Proposed PR: #5467

Problem
Currently, ToolNode requires its tool list at graph compilation time. Changing tools means rebuilding and recompiling the entire graph. This is inefficient in dynamic environments like multi-agent platforms, where:

Different agents may need different tool subsets (e.g., user-specific permissions).
Tools vary by tenant in multi-tenant apps.
Features are toggled via flags without restarting services.
Recompiling graphs repeatedly wastes resources, increases latency, and complicates deployment (e.g., hot-swapping tools for A/B tests).

Proposed Solution
Add support for injecting/merging tools at runtime via the config parameter:

New optional constructor arg: config_tools_key (default: "tools").
At invocation, merge tools from config["configurable"][config_tools_key] with any compile-time tools.
Make compile-time tools optional (require at least one source).

Example:

Compile once without fixed tools
tool_node = ToolNode(config_tools_key="tools")

Runtime: provide tools per call
graph.invoke(inputs, config={"configurable": {"tools": [tool_a, tool_b]}})
Merging prefers runtime tools on name conflicts. No changes to existing workflows.

Benefits
Efficiency: Compile once, reuse graph with varying tools – ideal for multi-agent systems serving diverse users.
Flexibility: Enables per-request customization without overhead.
Scalability: In platforms like chatbots or APIs, swap tools dynamically (e.g., enable premium tools for paid users).
This aligns with LangGraph's runtime config philosophy, extending it to tools.

Potential Drawbacks
Slight runtime overhead for merging (negligible).
Users must ensure tool name uniqueness to avoid unexpected overrides.
Alternatives Considered
Recompile graphs on-the-fly: Slower, more resource-intensive.
Subclass ToolNode: Works but fragments ecosystem; better as core feature.

What do you think? Is this worth prioritizing? Happy to discuss implementation details or provide a PoC PR.

[alankpax]

I agree to this idea as it would suit some use cases.