[FEATURE] pi coding-agent package: one-command install registering MCP server, skill, and extension

[pikujs]

🚀 Feature Request

Is your feature request related to a problem?

The pi coding agent (badlogic pi-mono lineage) has no built-in MCP support — MCP servers reach it through the pi-mcp-adapter extension, which reads MCP configs plus package-contributed configs. This repo documents Claude Code (install-claude-mcp.sh), Codex (codex mcp add), and a generic skill copy (cp -r skills/debugging ~/.agents/skills/), but a pi user has to hand-wire all three pieces: the stdio server entry, the skill, and any glue. There is no declarative package they can install.

Describe the solution you'd like

Ship a pi package manifest so the repo installs into pi with everything registered. In package.json:

"pi": {
  "extensions": ["./pi-extension/index.ts"],
  "skills": ["./skills"],
  "mcp": ["./pi.mcp.json"]
}

The skills entry discovers skills/debugging/ directly (no copy); the mcp entry is a stdio server entry picked up by pi-mcp-adapter.

After pi install <path>, pi loads the extension, discovers the mcp-debugger skill, and the adapter lazily spawns npx -y @debugmcp/mcp-debugger stdio on first tool use — all 28 tools plus the session-output resources, with no MCP client code to maintain.

Describe alternatives you've considered

• Manual setup docs (paste-this-mcp.json plus copy-the-skill): works but rots, and duplicates the skill.
• Self-contained extension with a native MCP client (spawn stdio, re-register all tools via pi.registerTool): no third-party dependency, but reimplements transports, lazy start, and schema mapping the adapter already handles — and burns context on 28 tool definitions where the adapter's proxy costs ~200 tokens.
• Dedicated packages/pi-debugger/ subpackage instead of a root manifest: required for npm:/git: distribution (pi install runs plain npm install, which fails on this root's workspace:* deps — verified EUNSUPPORTEDPROTOCOL), at the cost of a skill copy that can drift. Root manifest is local-path-install only.

💡 Use Case

A pi user debugging a Python script end-to-end (verified working against a fork branch):

mcp({ tool: "create_debug_session", args: { language: "python" } })
mcp({ tool: "set_breakpoint", args: { sessionId: "…", file: "/abs/cart.py", line: 40 } })
mcp({ tool: "start_debugging", args: { sessionId: "…", scriptPath: "/abs/cart.py" } })
// step / inspect / evaluate_expression … restart_debugging to confirm the fix

🔧 Implementation Ideas

• pi.mcp.json holding the mcp-debugger stdio server entry (command npx, args -y @debugmcp/mcp-debugger stdio).
• pi-extension/index.ts: thin factory (default export per pi's extension contract — note this deliberately diverges from this repo's no-default-exports convention) registering a session-start hint; tools come from the adapter.
• No new MCP tools or API changes required — the existing server, skills/debugging/, and debugging-workflow prompt are consumed as-is.

📊 Impact

• Who would benefit: pi coding-agent users (and any pi-mono-fork users with pi-mcp-adapter)
• Priority: Low
• Complexity: Simple (3 small files, no server changes)

🤝 Are you willing to contribute?

• Yes, I'd like to implement this feature — working branch exists (pikujs/mcp-debugger, pi-extension), PR to follow
• Yes, I'd like to help test it

📝 Additional Context

Verified end-to-end on Linux (node 24, Python 3.14 + debugpy): pi install <path> → skill discovered → adapter lazy-connect → real list_debug_sessions round-trip. Open question for maintainers: root manifest (minimal diff, local-path only) vs packages/pi-debugger/ subpackage (npm-distributable, skill copy) — happy to go either way.

[debugmcpdev]

Landing via #715, reshaped: the published @debugmcp/mcp-debugger package now carries the pi manifest and ships skills/debugging/, so pi install npm:@debugmcp/mcp-debugger registers the server (through pi-mcp-adapter) and the skill with no clone, from 0.25.0. The root-manifest shape was dropped because it is local-clone-only and ran the published server via npx regardless; the reasoning is in the PR thread.