What
Add a transport adapter so ACP can import tools from MCP servers that speak stdio (the default mode for Claude Desktop and Cursor MCP integrations) in addition to the HTTP tools/list envelope already supported in v0.1.
Why
Today the importer at internal/sources/mcp speaks the MCP HTTP envelope only. But the most common MCP servers in the wild — chrome-devtools-mcp, flyctl mcp server, the official filesystem / GitHub / Slack reference servers — are stdio processes spawned by the client. Without stdio support, ACP can't ingest the largest existing population of MCP servers without users wrapping each one behind an HTTP shim.
Proposed shape
sources:
- name: filesystem
type: mcp-stdio
command: npx
args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/sunny/work"]
env:
LOG_LEVEL: warn
- name: chrome
type: mcp-stdio
command: npx
args: ["-y", "chrome-devtools-mcp@latest"]
Each mcp-stdio source is launched as a subprocess by acp-server at boot, then sent the standard MCP JSON-RPC initialize + tools/list framing over stdin/stdout. The discovered tools are normalized into the same registry.Tool shape the HTTP importer produces.
Acceptance
Why v0.2, not v0.1.1
Stdio is a meaningfully different transport (process lifecycle, framing, exec routing). Forcing it into the v0.1.1 patch release alongside the --mcp-source flag (#13) makes both ship slower. Cut #13 first; #14 follows in v0.2.
Out of scope
- Per-tool fan-out across multiple stdio replicas of the same server.
- WebSocket or SSE MCP transports (tracked for later).
What
Add a transport adapter so ACP can import tools from MCP servers that speak stdio (the default mode for Claude Desktop and Cursor MCP integrations) in addition to the HTTP
tools/listenvelope already supported in v0.1.Why
Today the importer at
internal/sources/mcpspeaks the MCP HTTP envelope only. But the most common MCP servers in the wild —chrome-devtools-mcp,flyctl mcp server, the official filesystem / GitHub / Slack reference servers — are stdio processes spawned by the client. Without stdio support, ACP can't ingest the largest existing population of MCP servers without users wrapping each one behind an HTTP shim.Proposed shape
Each
mcp-stdiosource is launched as a subprocess byacp-serverat boot, then sent the standard MCP JSON-RPCinitialize+tools/listframing over stdin/stdout. The discovered tools are normalized into the sameregistry.Toolshape the HTTP importer produces.Acceptance
internal/sources/mcp_stdiopackage implementingImporteragainst a JSON-RPC stdio framing (the exact framemcp-goand@modelcontextprotocol/sdkagree on)./v1/exec/<source>.<tool>, the proxy must forward the call over the same stdio process (not over HTTP), preserving JSON-RPCidcorrelation.@modelcontextprotocol/server-filesystemreference server.Why v0.2, not v0.1.1
Stdio is a meaningfully different transport (process lifecycle, framing, exec routing). Forcing it into the v0.1.1 patch release alongside the
--mcp-sourceflag (#13) makes both ship slower. Cut #13 first; #14 follows in v0.2.Out of scope