Core idea: MCPX turns MCP servers into Unix-composable commands for agent workflows. It is primarily for agents that are shell-first, and secondarily useful for humans running tools directly.
For me, a practical use case is OpenClaw: OpenClaw can call `mcpx` like any normal CLI and use MCP servers immediately, without implementing custom MCP transport/auth plumbing in OpenClaw itself. This also fits well with Codex Apps mode, where connected apps can be exposed as MCP servers through the same command contract.
Command contract: - mcpx - mcpx <server> - mcpx <server> <tool>
Design choices: - schema-aware `--help` (inputs + declared outputs) - native flag surface from MCP `inputSchema` - pass-through tool output for normal shell composition (`jq`, `head`, pipes) - explicit exit mapping (`0/1/2/3`) - stdio + HTTP server support - optional caching - `mcpx add` for bootstrapping server config from install links/manifests/endpoints
Examples: - mcpx github search-repositories --help - mcpx github search-repositories --query=mcp - echo '{"query":"mcp"}' | mcpx github search-repositories
Install: - brew tap lydakis/mcpx && brew install --cask mcpx - npm i -g mcpx-go - pip install mcpx-go
I would love feedback on command UX, schema/flag edge cases, and where this should stop vs expand.
ldkge•1h ago
1. How is your agent using MCP today?
2. Where did MCPX make your agent workflow easier?
3. Where did MCPX get in the way in real agent loops?
4. What MCP workflow do you want to do that MCPX still doesn’t support?
5. What output/error behavior made automation brittle?
Concrete examples or snippets are especially helpful.