Allow agents/subagents to load and remove MCP servers

[szmania]

Description

Currently, MCP servers can only be managed at the primary agent level. This task aims to enable agents and subagents to dynamically load and remove MCP servers using dedicated tools.

Proposed Solution

Introduce two new tools:

1. /load-mcp: Allows agents/subagents to load MCP servers dynamically.
2. /remove-mcp: Allows agents/subagents to remove/unload MCP servers dynamically.

Requirements

• Ensure that agents/subagents can invoke these tools to manage their own MCP server connections.
• Maintain isolation and security: agents/subagents should only manage servers relevant to their scope.
• Validate that the tools work seamlessly with the existing MCP server infrastructure.
• Ensure proper error handling and feedback for invalid or unauthorized operations.

Acceptance Criteria

• Agents can load MCP servers using /load-mcp.
• Agents can remove MCP servers using /remove-mcp.
• Subagents can load MCP servers using /load-mcp.
• Subagents can remove MCP servers using /remove-mcp.
• Proper validation and error messages for invalid operations.
• Documentation updated to reflect new capabilities.

Dependencies

• Existing MCP server infrastructure in cecli.
• Agent/Subagent command handling system.

Notes

• This feature should align with the existing /load-mcp and /remove-mcp commands available at the primary level.
• Ensure backward compatibility with existing MCP server management.

[dwash96]

I would definitely recommend this more as an extension of the ContextManager tool rather than 2 new explicit tools since tools make agents pretty trigger happy. The general thing being modified here would be:

https://github.com/cecli-dev/cecli/blob/main/cecli/coders/base_coder.py#L421
https://github.com/cecli-dev/cecli/blob/main/cecli/coders/agent_coder.py#L118

Which controls which slice of the mcp_manager singleton an individual agent selects in terms of active servers and tools which get_tool_list() handles.

I actually also believe this reduction should be applied to the existing LoadSkill and RemoveSkill tools and should fold entirely into ContextManager. ContextManager (which probably should be renamed to ResouceManager_ then becomes a general API for LLMs to interact with to modify their own internal state as opposed to doing an operation on the world