Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/superradcompany/tool-cli/llms.txt

Use this file to discover all available pages before exploring further.

MCP supports two transports:
  • stdio — the host spawns a subprocess and communicates over stdin/stdout. Most desktop AI clients (Claude Desktop, Cursor, VS Code) use this.
  • HTTP (streamable HTTP) — the client connects to an HTTP endpoint. Required for remote servers, containers, and web clients.
Some clients only speak stdio. Some servers only expose HTTP. Transport bridging lets you connect them anyway: tool run --expose starts a proxy that speaks one transport on the outside and the other on the inside.

​
Expose a stdio server as HTTP

Start a local stdio server and make it accessible over HTTP. Useful for testing with curl, connecting web clients, or running in a container. 
# Expose on localhost:3000 (default)
tool run . --expose http

# Custom port
tool run . --expose http --port 8080

# Bind to all interfaces (accessible from other machines)
tool run . --expose http --port 8080 --host 0.0.0.0
--host 0.0.0.0 binds to all network interfaces. Only use this in trusted environments — the MCP endpoint will be reachable from any device on your network.

​
Proxy an HTTP server as stdio

Wrap a remote HTTP MCP server so that stdio-only clients can connect to it. The proxy accepts stdio on one side and forwards requests to the HTTP endpoint. 
tool run namespace/remote-mcp --expose stdio
This is useful when:
  • Your AI client only supports stdio (e.g., Claude Desktop)
  • The MCP server you want to use only exposes an HTTP endpoint
  • You want to add config or auth headers without modifying the client

​
Use cases

Claude Desktop + HTTP server

Claude Desktop only speaks stdio. Use --expose stdio to proxy any HTTP MCP server into a stdio connection Claude Desktop can use.

Local server via HTTP

Expose a stdio-based local server over HTTP for testing with curl or browser-based MCP clients.

Container / VM deployment

Run a stdio server inside a container, expose it as HTTP on a known port, and connect external clients to that port.

Localhost testing

Develop and test your stdio server locally, then expose it on HTTP so your CI pipeline or a teammate can hit the same endpoint.

​
Passing config at runtime

Both bridging directions support inline config values and config files: 
# Pass an API key when exposing
tool run . --expose http -k API_KEY=your-key

# Load config from a file
tool run . --expose http --config-file creds.json

​
Reference

FlagDescription
--expose httpExpose a stdio tool as an HTTP server
--expose stdioProxy an HTTP tool as a stdio server
--port <n>Port for HTTP mode (default: 3000)
--host <addr>Bind address for HTTP mode (default: 127.0.0.1)
-k KEY=VALUEPass a config value inline
--config-file <path>Load config from a JSON file
-vVerbose output

Build docs developers (and LLMs) love

Get started for freeTalk to us