[docs] Plan Pi MCP parity with pi-mcp-adapter#5299
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🤖 The AI agent says: This is the Pi MCP parity design requested after #5296 and #5297. Please focus review on two decisions:
The public MCP object, service secret resolution, frontend UI, and future gateway boundary do not change. |
Context
Pi cannot currently use the remote MCP servers configured on an agent. The shared service path already resolves those servers for every harness, but
pi-acpstores ACP MCP entries without forwarding them into Pi. The latest checkedpi-acp@0.0.31still documents that limitation and points users topi-mcp-adapter.Changes
This design keeps the existing saved and resolved MCP objects unchanged and reuses
pi-mcp-adapteronly for Pi's harness-specific last mile.Before:
Proposed:
The first implementation slice uses the adapter's default proxy tool because it works on the first process start. Cache-backed direct tools, OAuth, public stdio, MCP UI, probing, compatibility logic, and the future gateway remain out of scope. Local and Daytona use the same renderer and asset path.
Tests / notes
pi-acp@0.0.29and Pi0.80.6.pi-acp@0.0.31still does not wire MCP into Pi.pi-mcp-adapter@2.11.0HTTP, header, proxy, and direct-tool behavior.big-agentscontains only the seven design files.Review focus: whether proxy-first is the right MVP presentation, and whether the temporary secret-bearing adapter-config lifecycle matches the intended harness boundary.