pi-echo-mcp-bridge
Connects to configured MCP servers over stdio and registers their tools as regular Pi tools, gated by pi-echo-permissions like any other tool
Package details
Install pi-echo-mcp-bridge from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:pi-echo-mcp-bridge- Package
pi-echo-mcp-bridge- Version
0.1.0- Published
- Aug 13, 2026
- Downloads
- 127/mo · 127/wk
- Author
- hegdesumanth.dev
- License
- unknown
- Types
- extension
- Size
- 12.1 KB
- Dependencies
- 3 dependencies · 1 peer
Pi manifest JSON
{
"extensions": [
"."
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
pi-echo-mcp-bridge
Connects to configured MCP (Model Context Protocol) servers over stdio and registers each of their tools as a regular Pi tool.
Design note
Built directly on the official @modelcontextprotocol/sdk, not an unreviewed third-party bridge package — a deliberate choice, since any Pi package (and any dependency it pulls in) runs with full system access.
Composition with pi-echo-permissions is automatic, not something this package builds. Every bridged tool is registered via the ordinary pi.registerTool(), and Pi's tool_call event fires for every tool call regardless of who registered it — verified against the installed package's type declarations (CustomToolCallEvent.toolName: string covers any name), not assumed. What is genuinely NOT covered: pi-echo-core's protected-path check only extracts a path from the native write/edit tools' path field and scans bash's command string — it has no way to know that some mcp__filesystem__write_file tool's arguments.path is a filesystem write. An MCP server capable of writing files is gated only by whatever rule matches its tool name, not by the protected-paths list. Add an explicit rule (e.g. /permissions ask mcp__filesystem__write_file) for any such tool. See SECURITY.md.
A real bug found and fixed during manual testing, not just type-checked: the initial version connected to MCP servers on session_start but never closed those connections. Verified live against a real MCP test server: pi -e ./packages/pi-echo-mcp-bridge --mode json -p "..." printed its output correctly but then hung indefinitely instead of exiting — the lingering child-process pipes from the open MCP connection kept Node's event loop alive. Fixed by tracking active connections and closing them both on session_shutdown and before reconnecting on any subsequent session_start (which can fire more than once per process, e.g. on /reload — without closing first, each reload would leak the previous run's connections and spawned processes).
Usage
Configure servers in .pi/echo/mcp-servers.json (project scope) and/or ~/.pi/agent/echo/mcp-servers.json (global scope; project entries with the same name override global ones):
{
"servers": [
{ "name": "example", "command": "npx", "args": ["-y", "some-mcp-server"], "env": {} }
]
}
Each server's tools are registered as mcp__<server>__<tool>. /mcp shows connection status and tool counts. A server that fails to connect (10s timeout) is skipped with a warning — it does not block the others or crash startup.
A persistent footer status (⚡ N/M mcp, color reflecting all/some/none connected) also appears once the initial connection phase completes, so connection health is visible at a glance without running /mcp — set once at session_start, not refreshed per-turn, since MCP connections don't change mid-session the way pi-echo-git-status/pi-echo-test-status's indicators do.