Refactor dynamic tool provider lifecycle out of AgentLoop

[chengyongru]

Problem

MCP is currently modeled directly in AgentLoop through MCP-specific state and lifecycle methods such as _mcp_servers, _mcp_stacks, _connect_mcp(), and close_mcp(). This works for the immediate reconnect/crash fix in #4843, but it leaks a tool-specific provider lifecycle into the core agent loop.

MCP is not a single static tool. It is a tool provider: it connects to external servers, dynamically registers multiple tools/resources/prompts, supports reconnect and hot reload, and owns long-lived async transport cleanup. Those responsibilities are closer to nanobot/agent/tools/mcp.py or a general tool-provider runtime layer than to AgentLoop.

Why this matters

• AgentLoop should coordinate turns, sessions, tasks, and shutdown, not know MCP transport details.
• MCP-specific cleanup concerns such as retired stacks, AnyIO cancel-scope behavior, and streamable-http teardown should stay behind the MCP/tool boundary.
• Future dynamic tool providers will likely need similar lifecycle hooks; copying MCP-style special cases into AgentLoop would make the core path harder to maintain.

Desired direction

Introduce a small tool-provider lifecycle abstraction, or an equivalent local boundary, so providers can own their own runtime state and cleanup:

• provider start/connect against a ToolRegistry
• provider close/drain cleanup
• provider reload/hot-reload hook where applicable
• provider runtime-context lines where applicable
• grouping/ownership of dynamically registered tools

MCP can then become the first implementation, with _mcp_servers, _mcp_stacks, retired stacks, reconnect, reload, and cleanup owned outside AgentLoop.

Scope notes

This should be a follow-up refactor after #4843, not part of the production crash fix. #4843 should stay focused on #4302 and its regression coverage.

[flyzstu]

Hi @chengyongru! I've been looking into this refactoring and came up with a concrete design to clean up the AgentLoop boundary.

Proposed Approach

Instead of having AgentLoop hold raw MCP fields (_mcp_servers, _mcp_stacks, _mcp_connecting), we can extract a dedicated MCPManager (in nanobot/agent/tools/mcp_manager.py) to own that runtime state and transport lifecycle.

Here's how the responsibilities split up:

1. MCPManager State & Lifecycle:

   • Owns _mcp_servers (config snapshot), _mcp_stacks (live connection handles), _mcp_connecting (connect guard), and _mcp_closing (shutdown flag).
   • Exposes clean lifecycle methods: async def connect(self, registry: ToolRegistry), close(), and reload(registry).
   • Free functions in mcp.py (connect_missing_servers, close_mcp_servers, reload_servers) accept MCPManager as state rather than duck-typing AgentLoop.

2. AgentLoop Simplification:

   • AgentLoop only holds self._mcp_manager = MCPManager(mcp_servers or {}).
   • AgentLoop._connect_mcp() and close_mcp() delegate directly to self._mcp_manager.
   • AgentLoop no longer leaks any internal _mcp_* fields.

3. Runtime Control & Security:

   • agent_context.handle_runtime_control forwards to self._mcp_manager for hot-reloads.
   • MyTool (self.py) BLOCKED list updates to block _mcp_manager instead of raw _mcp_* fields.

Future Extensibility

This immediately decouples MCP transport/connection details from AgentLoop. If we want to support other dynamic tool providers in the future (e.g., A2A or remote RPC tool sources), we can formalize a DynamicToolProvider protocol (connect, close, reload) that MCPManager implements.

What do you think of this approach? Happy to open a PR if this aligns with the vision!

[chengyongru]

@flyzstu
Thanks for looking into this. I think extracting an MCPManager would make the current code cleaner, but it does not fully match the
architectural goal I had in mind.

If AgentLoop still owns an MCPManager and calls its connect, close, or reload methods, then AgentLoop still knows that MCP is a special case.
The implementation is more organized, but the dependency boundary remains the same.

My goal is for MCP tools to look like regular tools from AgentLoop's perspective. MCP should be a provider that creates and manages tools,
while AgentLoop should only work with the ToolRegistry.

The ideal dependency direction would be:

The application startup and shutdown layer owns MCPProvider.
That layer creates AgentLoop and injects the ToolRegistry into it.
AgentLoop only depends on ToolRegistry.
MCPProvider registers its tools in ToolRegistry.

In this design, AgentLoop would not contain MCP-specific fields or methods, and it would not connect or close MCP servers. MCPProvider would own connection, reconnection, reload, and cleanup outside AgentLoop.

If we later have another dynamic tool provider, we can introduce a small generic lifecycle abstraction at the application runtime level. For
now, I would prefer keeping the scope focused on extracting MCPProvider without making AgentLoop aware of it.