RTMP Integration Plan for Stack 2.9
Objective: Replace the legacy MCP‑based tool layer with a native Python‑centric tool system while preserving existing functionality and enabling easier extension.
1. Architecture Overview (text diagram)
+-------------------+ +--------------------+ +-------------------+
| Stack 2.9 Core | <----> | Tool Registry | <----> | Python Tool Impl |
| (models, prompts) | | (register/unregister) | | (functions) |
+-------------------+ +--------------------+ +-------------------+
^ ^ ^
| | |
| | |
| +--------------------+-----------------------+
| | Tool Invocation Layer (async) |
| | - validates input (zod -> pydantic) |
| | - checks permissions |
| | - streams progress & result |
| +----------------------------------------+
|
v
+-------------------+ +--------------------+ +-------------------+
| MCP Bridge | (legacy) | MCP Integration | (keep for backward) |
+-------------------+ +--------------------+ +-------------------+
The new system runs entirely in Python, mirroring the API surface of the existing MCPTool class but using native classes.
2. Implementation Phases
Phase 0 – Prep & Tool Discovery
- Add a
tools/package understack-2.9/src/(e.g.src/tools). - Create a base
Toolabstract class defining:name,description,input_schema(pydantic),output_schema.call(self, **params) -> Any(may be async).- Optional hooks:
validate,check_permissions,is_destructive,summary.
- Add a
tool_registry.pysingleton with:register(tool: Tool)unregister(name: str)get(name: str) -> Toollist() -> List[Tool]
- Implement auto‑loader that scans
src/tools/**for subclasses ofTooland registers them at import time (mirrors RTMP'sloadAgentsDir). - Write unit tests for registry behavior.
Phase 1 – Core Tool System
- Define schema handling using pydantic (lightweight, validates JSON schemas). Provide a helper
zod_to_pydanticif needed for future port‑over. - Implement
ToolInvokerclass:async invoke(name, params, context)- Performs input validation, permission check, runs
tool.call(). - Streams progress via async generator (
yield progress).
- Add permission framework similar to RTMP's
checkPermissions:- Global policy file
tools/permissions.yaml(allow/deny patterns). PermissionCheckerreads the policy, supportsalways_allow,always_deny,ask_user.
- Global policy file
- Create example native tools mirroring MCP built‑ins:
ReadFileTool,WriteFileTool,WebSearchTool,RunCommandTool,GitTool.- Each lives in its own module under
src/tools/.
- Update Stack entrypoint (
stack-2.9/stack.pyor CLI) to import the registry and expose the new tool list to the LLM prompt (replace MCPlist_tools).
Phase 2 – Migration Layer (MCP Compatibility)
- Keep the existing
MCPIntegrationclass but make it a thin wrapper around the new registry:- On
register_tool, forward totool_registry.register. - On
call_tool, forward toToolInvoker.invoke.
- On
- Add adapter classes for each legacy MCP tool that simply subclass the new
Tooland delegate to the original implementation (e.g.,LegacyReadFileAdapter). This ensures any existing agent definitions continue to work. - Write migration script
scripts/migrate_mcp_tools.pythat:- Loads all legacy MCP tools (from
RTMP/tools). - Generates stub Python classes in
src/tools/with matching signatures. - Updates
enhancements/collaboration/mcp_integration.pyto use the new registry.
- Loads all legacy MCP tools (from
- Run integration tests to confirm both legacy and native tools are discoverable.
Phase 3 – Full Cut‑over & Cleanup
- Update prompt generation (
agentToolUtilsetc.) to pull tool definitions from the Python registry instead of MCP metadata. - Deprecate the MCP client in
collaboration/mcp_integration.py:- Mark as
deprecatedwith warning logs. - Remove automatic auto‑registration of MCP tools.
- Mark as
- Remove the
RTMP/toolsdirectory from the repo (or archive it underlegacy/). - Extend documentation and add migration guide for developers.
- bump version to
2.9.1.
3. File Structure for New Tool System
stack-2.9/
├─ src/
│ ├─ tools/
│ │ ├─ __init__.py # registers all tools on import
│ │ ├─ base.py # abstract Tool class
│ │ ├─ registry.py # singleton registry implementation
│ │ ├─ invoker.py # ToolInvoker handling validation & permissions
│ │ ├─ permissions.yaml # policy file (allow/deny patterns)
│ │ ├─ read_file.py # native ReadFileTool
│ │ ├─ write_file.py # native WriteFileTool
│ │ ├─ web_search.py # native WebSearchTool (uses web_search tool)
│ │ ├─ run_command.py # native RunCommandTool (subprocess)
│ │ └─ git_tool.py # native GitTool (uses GitPython or subprocess)
│ └─ enhancements/
│ └─ collaboration/
│ ├─ __init__.py
│ ├─ mcp_integration.py # thin wrapper -> registry
│ └─ conversation_state.py
├─ docs/
│ └─ rtmp-integration-plan.md # <-- this file
└─ scripts/
└─ migrate_mcp_tools.py # migration helper
4. Migration Path
| Step | Action | Outcome |
|---|---|---|
| 1️⃣ | Add native registry & base classes | Core infrastructure ready |
| 2️⃣ | Implement native equivalents of all built‑in MCP tools | Feature parity |
| 3️⃣ | Wrap legacy tools with adapters & register them via the new registry | Zero‑breakage for existing agents |
| 4️⃣ | Switch list_tools calls to registry.list() |
Prompt now reflects native tools |
| 5️⃣ | Deprecate MCP client, remove old RTMP/tools folder |
Clean codebase |
| 6️⃣ | Update documentation & version bump | Done |
5. Security & Permissions
- Schema validation via pydantic ensures only expected fields reach the implementation.
- PermissionChecker reads
tools/permissions.yaml:always_allow: - read_file - web_search always_deny: - run_command: "*" ask_user: - write_file - git_operation - Hooks can raise
PermissionDeniedwhich bubbles up to the LLM as a tool‑use error message. - All destructive tools (
write_file,git_operation,run_commandwithsudo) must be markedis_destructive=Trueto trigger explicit user confirmation.
6. Documentation & Testing
- Add docstrings to each tool class (auto‑generated API reference via
pydoc). - Write pytest suites covering:
- Registry CRUD
- Input validation failures
- Permission matrix (allow/deny/ask)
- End‑to‑end invocation through
ToolInvoker.
- Update
README.mdwith a “Native Tool System” section describing how to add new tools.
7. Risks & Mitigations
| Risk | Impact | Mitigation |
|---|---|---|
| Regression of existing agents relying on MCP metadata format | Breaks user workflows | Keep adapter layer until next major release; run full suite of agent integration tests. |
| Permission policy mis‑configuration causing silent denial | User confusion | Fail fast with clear error messages; add a startup sanity check that all tools have a permission rule. |
| Performance regression due to Python validation overhead | Slower turn latency | Cache compiled pydantic models; benchmark against MCP’s JSON‑schema validation (expected to be comparable). |
8. Next Steps
- Commit the skeleton (
src/tools/with base classes & registry). - Implement
ReadFileToolandWriteFileToolas proof‑of‑concept. - Run the migration script to generate adapters for the remaining MCP tools.
- Update the Stack entrypoint to expose the new tool list.
- Iterate on tests and documentation.
Prepared by the sub‑agent tasked with RTMP integration.