Reconcile the two MCP client stacks (tui/src/mcp vs crates/mcp)
- Dominant language
- Rust
- Stars
- 41k
- Forks
- 3.6k
- Avg merge
- 13h 59m
- Merged PRs (30d)
- 299
Description
From the 0.9.14 refactor backlog.
`tui/src/mcp/` (~13.2k lines: `McpPool`, config load/save, oauth, stdio/http/sse clients, `external_import`) and `crates/mcp` (~4.5k: `McpManager`, same-named `stdio_client`/`http_client`/`sse`/`wire`/`oauth`). app-server uses the crate; the engine uses its own. One MCP stack should exist.
Sequence with #6033 (lazy connection at point of use) and #6131 (one negotiated protocol adapter) so the lifecycle work lands once. Size: L.
Contributor guide
Research direction
Begin by comparing the MCP implementations under tui/src/mcp/ and crates/mcp/, including their pool or manager, transport clients, OAuth, wire, and external-import components. Trace which stack the app-server and engine use, while accounting for the sequencing with #6033 and #6131. Done means one MCP stack remains and the relevant consumers use it without duplicating lifecycle or protocol work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend-api-design, cli
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100