Build a pi extension for MCP integration using official SDK
Session from 0xKobolds on Hugging Face by moikapy · MIT · condensed by Coders Talk
Create a new pi package (@0xkobold/pi-mcp) that gives the 0xKobold agent framework access to Model Context Protocol servers, replacing an old hand-rolled JSON-RPC extension with one built on the official MCP TypeScript SDK.
- +0Prompt · +0Create a pi extension for MCP access in packages/, researching Claude Code's implementation via sub-agents; ultrathink
- +0mAgent did · +0mResearched MCP SDK, Claude Desktop's IPC-based MCP support, and existing pi extension patterns, then built the new @0xkobold/pi-mcp package with client, config, tool-bridge, and extension entry point modules supporting stdio/SSE/streamable-HTTP transports.
- +7mFail · +7mTypeScript build failed on tool result type inference and a missing 'close' extension event.
- +7mAgent did · +7mFixed type casting and event name issues, got a clean build, wrote README/CHANGELOG/skill docs, and wired the package into pi-config.ts, replacing the old mcp-extension.ts reference.
- +21mPrompt · +21mCreate a task list for this and begin making plans to knock them out
- +21mAgent did · +21mWrote a phased ROADMAP.md, archived the old mcp-extension.ts, ran a live smoke test against a filesystem MCP server (14 tools discovered, 18/18 tests passing), and closed out Phase 1.
- +32mAgent did · +32mWorked through Phase 2 and 3 tasks: added WebSocket transport, hardened error handling with timeouts/validation, wrote unit tests (up to 53 passing), added tool allow/deny filtering with a /mcp filter command, and bumped the package to 0.2.0.
- +1h 3mAgent did · +1h 3mContinued through remaining roadmap items: roots support, env variable interpolation, SSE headers, multi-project config merging, server health monitoring, a resource cache, sampling support, progressive tool registration for large tool sets, and a TUI status widget, reaching 95 passing tests and v0.4.0.
- Break · 1h 31m away, not counted
- +2h 21mPrompt · +2h 21mIs this ready to be used?
- +2h 22mOutcome · +2h 22mSession ended mid-verification: discovered the published package has no dist/ directory and pi's extension loader may not resolve the TS source at runtime, leaving real end-to-end readiness unconfirmed despite 95/95 unit and integration tests passing.
Next time I'd ask upfront for a runtime smoke test as part of the definition of done, not just unit tests — the agent kept declaring 'done' after each roadmap phase based on TypeScript compiling and bun test passing, but never verified pi could actually load the extension in a real running instance until I asked 'is this ready to be used?' at the very end. That final question was the correction that mattered: it immediately surfaced a missing dist/ directory that all the green checkmarks had been hiding.