Accessing mcp through a docker sandbox

[dhndmn]

Hi all - I want to use xcodebuildmcp through a sandboxed agent. I have Pi running in a Docker sandbox (ubuntu) hosted on my mac. I can't seem to figure out how to SSH into my mac from the sandbox (feature limited, I think), so I'm wondering if there are other ways of my agent sending commands. I built a custom pi extension with the tools I needed, and this remote setup worked for me previously when I could SSH into the mac from a remote machine. It doesn't seem like the mcp server is reachable via any ports and is expecting the agent to be running locally. I may be mistaken. Does anyone have a similar setup that is working?

My agent wants to implement some socat TCP bridge solution as a backup plan, but I thought I'd see if someone has solved this.

Thanks for reading.

[hosanxiv]

Your reading is correct: XcodeBuildMCP currently exposes its MCP server over stdio only, not an HTTP/SSE port. The server imports StdioServerTransport and connects it directly (source, startup path). That is why there is no port for the Linux container to reach.

The process also needs to run on macOS because its tools invoke Xcode, simulators, and other host resources. So the workable layouts are:

1. Simplest: run the agent/MCP client on the Mac and configure it to spawn xcodebuildmcp mcp.
2. Keep the agent in Docker: run XcodeBuildMCP on the Mac behind a small stdio-to-Streamable-HTTP bridge, then point the container's MCP client at that bridge using host.docker.internal:<port>.
3. SSH approach: enable macOS Remote Login and have a Mac-side command/proxy spawn the stdio server. A plain SSH shell alone is not automatically an MCP transport; the client or wrapper must preserve stdin/stdout as the JSON-RPC channel.

For option 2, bind the bridge to a trusted interface and add authentication/firewalling. Exposing an Xcode control surface to the LAN without access control would be risky.

So this is not a missing XcodeBuildMCP port setting: remote transport is simply not part of the current server. A native Streamable HTTP mode would need to be added upstream; until then, a Mac-side transport bridge is the cleanest container architecture.