AI Guide to the Galaxy MCP Toolkit and Gateway, Explained

This is an abridged version of the interview we had in , where host Oleg Šelajev spoke with Jim Cla

This is an abridged version of the interview we had in , where host Oleg Šelajev spoke with Jim Clark, Principal Software Engineer at Docker, to unpack Docker’s MCP Toolkit and MCP Gateway. You’ve been deep in agents for a while. Where did this all start? When tool calling arrived, we noticed something simple but powerful: . So we wrapped tools in Docker images, gave agents controlled “hands,” and everything clicked. That was even before the Model Context Protocol (MCP) spec landed. When Anthropic published MCP, it put a name to what we were already building. So, what problem does the Toolkit solve on day one? Installation and orchestration. The Toolkit gives you a (think: YouTube transcript, Brave search, Atlassian, etc.) packaged as containers and ready to run. No cloning, no environment drift. Just grab the image, start it, and go. As Docker builds these images and publishes them to Hub, you get consistency and governance on pull. And it presents a single, client-friendly surface? Exactly. The Toolkit can act as an MCP server to clients, aggregating whatever servers you enable so clients can list tools in one place. I see “Toolkit” inside Docker Desktop. Where does the come in? The Gateway is a core piece the Toolkit: a process (and open source project) that unifies which MCP servers are exposed to which clients. The CLI and UI manage both local containerized servers and . That way you can attach a client, run through OAuth where needed, and use those remote capabilities securely via one entry point. Can we see it from a client’s perspective? Sure. Fire up the Gateway, connect Claude, run , and you’ll see the tools (e.g., Brave Web Search, Get Transcript) available to that session, backed by containers the Gateway spins up on demand. What hardening happens before a server runs? On pull/run, we do , ensuring Docker built the image, checking for an SBOM, and running supply-chain checks (via Docker Scout) so you’re not executing something tampered with. And credentials? Secrets you add (say, for Atlassian) are at runtime, nothing else can see them. For remote servers, the Gateway can handle , acquiring or proxying tokens into the right container or request path. It’s two flavors of secret management: local injection and remote OAuth, both controlled from Docker Desktop the CLI. If I have 30 servers, can I scope what a given client sees? Yes. Choose the servers per Gateway run, then so the client only gets the subset you want. Treat it like “profiles” you can version alongside your code; compose files and config make it repeatable for teams. You can even run gateways for different configurations (e.g., “chess tools” vs. “cloud ops tools”). How do I move from tinkering to something durable? Keep it . The Gateway and servers are defined as services in your compose files, so your agent stack is reproducible. From there, push to cloud: partners like already support one-command deploys from Compose, with Azure integrations in progress. Start locally, then graduate to remote runs seamlessly. And choosing models? Experiment locally, swap models as needed, and wire in the MCP tools that fit your agent’s job. The pattern is the same: pick models, pick tools, compose them, and ship. Summarize the path for me. Spin up your first profile and point your favorite client at the Gateway. When you’re ready to expand your agent stack, explore tooling like for local iteration and for on-demand cloud resources — then keep everything declarative with Compose.