feat(mcp): bring stdio transport to parity with http streamable and sse#181
Conversation
Document the STDIO MCP transport option alongside http_streamable and sse transports. STDIO spawns a local child process per request and is designed for client-side sidecars rather than server deployments. Clarify that HTTP transports support authentication and scratchpad configuration, while STDIO uses cmd, args, and env fields. Relates to: PR #181
|
Promptless prepared a documentation update related to this change. Triggered by PR #181 Updated the quickstart guide to document the new STDIO transport alongside HTTP streamable and SSE, including guidance that STDIO spawns a local child process per request and is designed for client-side sidecars rather than server deployments. Review: Document all MCP transport options in quickstart guide |
945b6cf to
71fdceb
Compare
| // Collect from STDIO tools | ||
| for tools in mcp_manager.stdio_tools.values() { | ||
| for tool in tools { | ||
| names.push(tool.name.to_string()); |
There was a problem hiding this comment.
I see there is a check for duplicate tool names below. Should we add some sort of warning that we have ambiguous tool names to invoke or should things be namespaced by a schema name? This situation may not be common, but certainly a foot-gun we can run into.
There was a problem hiding this comment.
This is a great point and something I've considered tackling. The code your seeing is a pre-existing pattern with the other server types but I think the idea of namespacing could be interesting but isn't something that should be done without a bit of strategy. Many system prompts have verbatim tool usage guidelines "run 'x' before 'y'" so there is some backwards compat concerns. We also have mcp filter by explicit tool names that this would effect. The upshot is that it would prevent collisions and give us something easier to glob match on when writing mcp filters - 'mezmo_' or 'k8_get_' for example. The problem is that we might need to consider how the namespaces are defined in our config to keep the tool names from getting to long. My proposal is we leave this pattern as is for now and file an issue around re-exploring the namespace idea. I'm going to audit to see if there is a good place to make this more clear in the README
There was a problem hiding this comment.
Filed #186 and added a README warning about the conflict behavior
Add STDIO as a first-class MCP transport alongside HTTP streamable and SSE. Spawns a local child process per request using rmcp's native TokioChildProcess transport. Ref: #163
71fdceb to
ef65697
Compare
Fixes #163 - stdio isn't a huge priority for big production backend systems but having it available makes evaluating and playing with AURA a lot more accessible