Running an MCP sounds simple: spin up a Python or Node server that exposes your tool. Done, right? Not quite.<\/p>\n
You run into problems fast:<\/p>\n
- \n
- Runtime friction<\/strong>: If an MCP is written in Python, your environment needs Python (plus dependencies, plus maybe a virtualenv strategy, plus maybe GPU drivers). Same goes for Node. This multiplies fast when you\u2019re managing many MCPs or deploying them across teams.<\/li>\n
- Secrets management<\/strong>: MCPs often need credentials (API keys, tokens, etc.). You need a secure way to store and inject those secrets into your MCP runtime. That gets tricky when different teams, tools, or clouds are involved.<\/li>\n
- N\u00d7N integration pain<\/strong>: Let\u2019s say you\u2019ve got three clients that want to consume MCPs, and five MCPs to serve up. Now you\u2019re looking at 15 individual integrations. No thanks.<\/li>\n<\/ul>\n
To make MCPs practical, you need to solve these three core problems: runtime complexity, secret injection, and client-to-server wiring.\u00a0<\/p>\n
If you\u2019re wondering where I\u2019m going with all this, take a look at those problems. We already have a technology that has been used by developers for over a decade that helps solve them: Docker containers.<\/p>\n
In the rest of this blog I\u2019ll walk through three different approaches, going from least complex to most complex, for integrating MCP servers into your developer experience.\u00a0<\/p>\n
Option 1 \u2014 Docker MCP Toolkit & Catalog<\/strong><\/h2>\n
For the developer who already uses containers and wants a low-friction way to start with MCP.<\/em><\/p>\n
If you\u2019re already comfortable with Docker but just getting your feet wet with MCP, this is the sweet spot. In the raw MCP world, you\u2019d clone Python\/Node servers, manage runtimes, inject secrets yourself, and hand-wire connections to every client. That\u2019s exactly the pain Docker\u2019s MCP ecosystem set out to solve.<\/p>\n
Docker\u2019s MCP Catalog<\/a> is a curated, containerized registry of MCP servers. Each entry is a prebuilt container with everything you need to run the MCP server.\u00a0<\/p>\n
The MCP Toolkit<\/a> (available via Docker Desktop) is your control panel: search the catalog, launch servers with secure defaults, and connect them to clients.<\/p>\n
How it helps:<\/strong><\/p>\n
- \n
- No language runtimes to install<\/li>\n
- Built-in secrets management<\/li>\n
- One-click enablement via Docker Desktop<\/li>\n
- Easily wire the MCPs to your existing agents (Claude Desktop, Copilot in VS Code, etc)<\/li>\n
- Centralized access via the MCP Gateway<\/li>\n<\/ul>\n\n
![\"MCP](\"https:\/\/www.docker.com\/app\/uploads\/2026\/01\/MCP-Catalog.gif\" "\\"-")
\n <\/div>\nFigure 1: Docker MCP Catalog: Browse hundreds of MCP servers with filters for local or remote and clear distinctions between official and community servers<\/p>\n
\nA Note on the MCP Gateway
One important piece working behind the scenes in both the MCP Toolkit and cagent (a framework for easily building multi-agent applications that we cover below) is the MCP Gateway<\/a>, an open-source project from Docker that acts as a centralized frontend for all your MCP servers. Whether you\u2019re using a GUI to start containers or defining agents in YAML, the Gateway handles all the routing, authentication, and translation between clients and tools. It also exposes a single endpoint that custom apps or agent frameworks can call directly, making it a clean bridge between GUI-based workflows and programmatic agent development.<\/p>\n<\/div>\nMoving on: Using MCP servers alongside existing AI agents is often the first step for many developers. You wire up a couple tools, maybe connect to a calendar or a search API, and use them in something like Claude, ChatGPT, or a small custom agent. For step-by-step tutorials on how to automate dev workflows with Docker\u2019s MCP Catalog and Toolkit with popular clients, check out these guides on ChatGPT<\/a>, Claude Desktop<\/a>,Codex<\/a>, Gemini CLI<\/a>, and Claude Code<\/a>.\u00a0
Once that pattern clicks, the next logical step is to use those same MCP servers as tools inside a multi-agent system.<\/p>\nOption 2 \u2014 cagent: Declarative Multi-Agent Apps<\/strong><\/h2>\n
For the developer who wants to build custom multi-agent applications but isn\u2019t steeped in traditional agentic frameworks.<\/em><\/p>\n
If you\u2019re past simple MCP servers and want agents that can delegate, coordinate, and reason together, cagent<\/a> is your next step. It\u2019s Docker\u2019s open-source, YAML-first framework for defining and running multi-agent systems\u2014without needing to dive into complex agent SDKs or LLM loop logic.<\/p>\n
Cagent lets you describe:<\/p>\n
- \n
- The agents themselves (model, role, instructions)<\/li>\n
- Who delegates to whom<\/li>\n
- What tools each agent can access (via MCP or local capabilities)<\/li>\n<\/ul>\n
Below is an example of a pirate flavored chat bot:<\/p>\n
\n\nagents:\n root:\n description: An agent that talks like a pirate\n instruction: Always answer by talking like a pirate.\n welcome_message: |\n Ahoy! I be yer pirate guide, ready to set sail on the seas o' knowledge! What be yer quest? \n model: auto\n\n\ncagent run agents.yaml\n\n<\/pre>\n<\/div>\n
You don\u2019t write orchestration code. You describe what you want, and Cagent runs the system.<\/p>\n\n
Why it works:<\/strong><\/p>\n
- \n
- Tools are scoped per agent<\/li>\n
- Delegation is explicit<\/li>\n
- Uses MCP Gateway behind the scene<\/li>\n
- Ideal for building agent systems without writing Python <\/li>\n<\/ul>\n
If you\u2019d like to give cagent a try, we have a ton of examples<\/a> in the project\u2019s GitHub repository. Check out this guide<\/a> on building multi-agent systems in 5 minutes.\u00a0<\/p>\n
Option 3 \u2014 Traditional Agent Frameworks (LangGraph, CrewAI, ADK)<\/strong><\/h2>\n
For developers building complex, custom, fully programmatic agent systems.<\/em><\/p>\n\n
Traditional agent frameworks like LangGraph, CrewAI, or Google\u2019s Agent Development Kit (ADK) let you define, control, and orchestrate agent behavior directly in code. You get full control over logic, state, memory, tools, and workflows.<\/p>\n
They shine when you need:<\/p>\n
- \n
- Complex branching logic<\/li>\n
- Error recovery, retries, and persistence<\/li>\n
- Custom memory or storage layers<\/li>\n
- Tight integration with existing backend code<\/li>\n<\/ul>\n
Example: LangGraph + MCP via Gateway<\/strong><\/p>\n
\n\n\nimport requests\nfrom langgraph.graph import StateGraph\nfrom langchain.agents import Tool\nfrom langchain_openai import ChatOpenAI\n\n# Discover MCP endpoint from Gateway\nresp = requests.get(\"http:\/\/localhost:6600\/v1\/servers\")\nservers = resp.json()[\"servers\"]\nduck_url = next(s[\"url\"] for s in servers if s[\"name\"] == \"duckduckgo\")\n\n# Define a callable tool\ndef mcp_search(query: str) -> str:\n return requests.post(duck_url, json={\"input\": query}).json()[\"output\"]\n\nsearch_tool = Tool(name=\"web_search\", func=mcp_search, description=\"Search via MCP\")\n\n# Wire it into a LangGraph loop\nllm = ChatOpenAI(model=\"gpt-4\")\ngraph = StateGraph()\ngraph.add_node(\"agent\", llm.bind_tools([search_tool]))\ngraph.add_edge(\"agent\", \"agent\")\ngraph.set_entry_point(\"agent\")\n\napp = graph.compile()\napp.invoke(\"What\u2019s the latest in EU AI regulation?\")\n\n<\/pre>\n<\/div>\nIn this setup, you decide which tools are available. The agent chooses when to use them based on context, but you\u2019ve defined the menu.
And yes, this is still true in the Docker MCP Toolkit: you decide what to enable. The LLM can\u2019t call what you haven\u2019t made visible.<\/p>\nChoosing the Right Approach<\/strong><\/p>\n
\n
- Secrets management<\/strong>: MCPs often need credentials (API keys, tokens, etc.). You need a secure way to store and inject those secrets into your MCP runtime. That gets tricky when different teams, tools, or clouds are involved.<\/li>\n