Repository navigation
M1. stdio transport for the MCP server #153
Description
Why
MCP is HTTP-only today (default port 6128). The most common MCP client integration pattern (Claude Desktop, many IDE agents, sandboxed hosts) launches servers over stdio. HTTP-only is a hard compatibility wall and forces port management. With adoption growing across 60+ accounts, broadening client reach is the highest-leverage agent investment.
Proposed behavior
--mcp-stdio(or--mcp --transport stdio) starts the server on stdio; keep HTTP as an option.- Document both transports in
docs/mcp.md.
Acceptance criteria
- Server usable from a stdio MCP client end-to-end.
- HTTP behavior unchanged.
- Tests cover transport selection.
- Docs updated.
Filed from the Agentic & Automation Roadmap (docs/agentic-roadmap.md), item M1, Wave 1. Priority P0.
Activity
mkrueger commentedon Jul 7, 2026
Where did you get the recommendation for stdio transport? An AI? Just wondering about the intention/use case about that.
It's a strategic thing:
Should the shell be agent infrastructure at all, or is it a human tool that points agents at Azure MCP Server for Cosmos access?
We're a CLI tool so stdio can't be reused as communication pipeline easily - surely I can implement a non REPL mode but basically - what should that offer what let's say Azure MCP isn't better at?
The stateful, composable operational surface of the shell is ment for user interaction I don't see a mcp scenario can benefit from that - it would make things only harder in my opinion. So before implementing it - we should make the decision if the shell should be an infrastructure component as well.
The MCP sevrer today is a "buddy" that helps you to type commands in the repl - that's a complete different thing.
Emit structured (JSON) content for MCP tool results (#154) (#168)