How does STDIO transport work

[hemangjoshi37a]

make it work with STDIO transport

[crivetimihai]

Hi,

The MCP Gateway already supports stdio only clients via mcpgateway.translate and stdio only servers via mcpgateway.translate:

https://ibm.github.io/mcp-context-forge/#running-from-an-mcp-client-mcpgatewaywrapper
https://ibm.github.io/mcp-context-forge/using/servers/go/fast-time-server/#method-2-using-translate-module

Could you please expand on the requirement using the provided template?

[hemangjoshi37a]

why there is no option by default to include a stdio type server ?

[crivetimihai]

Hi @hemangjoshi37a,

The Admin UI intentionally doesn't offer STDIO as a gateway transport option because gateways are network-accessible HTTP endpoints — they have a url field pointing to a remote (or local) MCP server. STDIO requires spawning a local process and communicating via stdin/stdout, which is a fundamentally different model that doesn't fit the gateway concept.

The recommended workflow for using stdio-based MCP servers with ContextForge is:

1. Bridge the stdio server to HTTP using the translate module:

   python -m mcpgateway.translate --stdio "uvx mcp-server-git" --port 9000

   This wraps the stdio server and exposes it as an HTTP endpoint (SSE or Streamable HTTP).

2. Register the HTTP endpoint as a gateway in the UI:

   • URL: http://localhost:9000/sse (or http://localhost:9000/mcp for Streamable HTTP)
   • Transport: SSE or STREAMABLEHTTP

3. Create a virtual server and select the tools you want to expose.

The translate module supports bidirectional bridging:

• --stdio → HTTP: Expose a local stdio server over the network
• --sse / --streamablehttp → stdio: Wrap a remote HTTP server as a local stdio process

Documentation: https://ibm.github.io/mcp-context-forge/using/mcpgateway-translate/