Skip to content

docs: add stdio Bus to MCP clients list#2545

Closed
morozow wants to merge 7 commits intomodelcontextprotocol:mainfrom
morozow:doc/stdiobus-mcp-client
Closed

docs: add stdio Bus to MCP clients list#2545
morozow wants to merge 7 commits intomodelcontextprotocol:mainfrom
morozow:doc/stdiobus-mcp-client

Conversation

@morozow
Copy link
Copy Markdown

@morozow morozow commented Apr 9, 2026

Summary

Adds stdio Bus to the MCP Example Clients page (clients.mdx), in alphabetical order between SpinAI and Superinterface.

stdio Bus is an MCP client runtime that combines multi-language SDKs with a supervised process runtime. It keeps agent and server processes healthy, preserves session continuity, and routes messages reliably across long-running workloads.

Entry details:

Field Value
Name stdio Bus
Homepage https://stdiobus.com
Source code https://github.com/stdiobus/stdiobus
Supports Resources, Prompts, Tools, Discovery, Instructions, Sampling, Roots, Elicitation, Tasks, OAuth Client Credentials
Instructions https://stdiobus.com/getting-started

Motivation and Context

stdio Bus gives developers an MCP client runtime with five transport modes, pluggable framing and protocol options, built-in process supervision, and session-aware routing. It can be deployed standalone with Docker or embedded directly into applications via the C API.

Adding it to the clients page gives MCP users visibility into this integration option.

How Has This Been Tested?

  • Verified the McpClient block renders correctly against the existing page structure.
  • Confirmed all links resolve (stdiobus.com, GitHub, npm, PyPI, crates.io, Docker Hub).
  • Checked alphabetical placement within the existing client list.

Breaking Changes

None. Documentation-only change.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

- Add stdio Bus client entry with homepage and source code links
- Include support information for Resources, Prompts, and Tools
- Document key features including worker process supervision, session-based routing, and backpressure management
- List available SDKs for Rust, Node.js, Python, C++, and Go
- Add Docker deployment information and link to official documentation
@morozow morozow requested review from a team as code owners April 9, 2026 00:18
morozow and others added 2 commits April 9, 2026 02:21
- Remove unnecessary blank line between stdio Bus and Superinterface client entries
- Improve formatting consistency in clients.mdx file
@localden
Copy link
Copy Markdown
Contributor

localden commented Apr 9, 2026

Thanks for the contribution, @morozow!

Would love a second set of eyes here from @olaservo and @cliffhall, but this doesn't seem like a client? There are many MCP-related offerings out there and I am not sure to what degree we want to broaden this list to include all of them.

@localden localden added the clients PRs that are updating the Clients page: https://modelcontextprotocol.io/clients label Apr 9, 2026
@olaservo
Copy link
Copy Markdown
Member

olaservo commented Apr 9, 2026

I agree this doesn't really fit in the client page. It might be best to share it in the 'Show and tell' section of the Discussions instead?

morozow added 3 commits April 9, 2026 09:23
- Update supported features list to include Discovery, Instructions, Sampling, Roots, Elicitation, Tasks, and OAuth Client Credentials
- Revise description to clarify stdio Bus as an MCP client runtime with multi-transport support
- Reorganize key features to highlight client operations, server worker management, transport options, and deployment flexibility
- Add mention of ACP Registry support for dynamic agent launching
- Update feature descriptions to reflect current capabilities and SDK availability
- Refocus description on multi-language SDKs and supervised process runtime
- Emphasize health monitoring, session continuity, and message routing
- Reorganize key features to highlight transport modes and protocol flexibility
- Add details on process supervision, restart policies, and flow control
- Clarify deployment options including Docker images and C API embedding
- Improve clarity on session-aware routing and worker pool management
@morozow
Copy link
Copy Markdown
Author

morozow commented Apr 9, 2026

Makes sense to question it. The way people typically use this page is practical: "what can I use to connect to MCP from my stack and run it in production?" stdio Bus answers that — code-level integration from multiple languages plus Docker deployment. It's not a proxy on the side, it's the client layer the application talks to MCP servers through.

Worth noting this isn't a thin wrapper or a helper script. The project has its own runtime, a published specification, a documentation site, Docker images, and SDKs for five languages. That's the shape of a standalone client, not auxiliary tooling.

In practice the scenario is straightforward: a developer writes code in Python, Node, Rust, C++ or Go, starts stdio Bus, and from that point works with MCP servers through it. That's why it fits here.

Updated the entry to lead with that angle.

- Update Rust SDK crate link from stdiobus-client to stdiobus
- Correct package reference to match actual crate name on crates.io
@cliffhall
Copy link
Copy Markdown
Member

In practice the scenario is straightforward: a developer writes code in Python, Node, Rust, C++ or Go, starts stdio Bus, and from that point works with MCP servers through it.

That sounds more like a proxy than a client.

@morozow
Copy link
Copy Markdown
Author

morozow commented Apr 9, 2026

@cliffhall The difference is in behaviour, not wording. stdio Bus takes a startup config --config/--config-fd, uses it to create worker pools, launches the MCP worker processes itself, and keeps them healthy via monitor/restart. For each session, it also chooses which worker handles it. Proxy just forwards bytes to services that are already running and doesn't do any of that.

That's what makes it a client: it owns which MCP servers exist, how they're started, and how requests reach them – the application talks to stdio Bus, not to MCP servers directly.

@localden
Copy link
Copy Markdown
Contributor

localden commented Apr 9, 2026

There are a few inconsistencies here that would need to be resolved for this to be considered, but overall this project seems like a process supervisor more so than a client. I do agree with @olaservo and @cliffhall's assessment.

@morozow - appreciate you taking the time to contribute! At this point, we will close this PR, but if there is a specific MCP client that you implement in the future, feel free to open a new PR and we'll help review it.

@localden localden closed this Apr 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clients PRs that are updating the Clients page: https://modelcontextprotocol.io/clients

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants