With the latest features in Docker MCP Gateway<\/a>, including Smart Search<\/strong> and Tool Composition<\/strong>, we\u2019re shifting from \u201cWhat do I need to configure?\u201d<\/em> to \u201cWhat can I empower agents to do?\u201d\u00a0<\/em><\/p>\n This week, Anthropic also released a post about building more efficient agents<\/a>, and they have called out many of the same issues that we\u2019ll be discussing in this post. Now that we\u2019ve made progress towards having<\/em> tools, we can start to think more about effectively using<\/em> tools.<\/p>\n With dynamic MCPs, agents don\u2019t just search for or add tools, but write code to compose new ones within a secure sandbox, improving both tool efficiency and token usage.<\/p>\n If you think about how we configure MCPs today, the process is not particularly agentic<\/em>. Typically, we leave the agent interface entirely, do some old-school configuration hacking (usually editing a JSON file of some kind), and then restart our agent session to check if the MCPs have become available. As the number of MCP servers grows, is this going to work?<\/p>\n So what prevents our agents from doing more to help us discover useful MCP servers<\/a>?<\/p>\n We think that Docker\u2019s OSS gateway<\/a> can help here. As the gateway manages the interface between an agent and any of the MCP servers in the gateway\u2019s catalog, there is an opportunity to mediate that relationship in new ways.\u00a0<\/p>\n Out of the box, the gateway ships with a default catalog, the Docker MCP Catalog<\/a>,\u00a0 including over 270 curated servers and of course the ability to curate your own private catalogs (e.g. using servers from the community registry<\/a>). And because it runs on Docker, you can pull and run any of them with minimal setup. That directly tackles the first friction point: discovery of trusted MCP servers.\u00a0<\/p>\n Figure 1: The Docker MCP Gateway now includes mcp-find and mcp-add, new Smart Search features that let agents discover and connect to trusted MCP servers in the Docker MCP Catalog, enabling secure, dynamic tool usage.<\/p>\n However, the real key to dynamic MCPs is a small but crucial adjustment to the agent\u2019s MCP session. The gateway provides a small set of primordial<\/em> tools that the agent uses to search the catalog and to either add or remove servers from the current session. Just as in the post from Anthropic<\/a>, which suggests a search_tools<\/em> tool, we have added new tools to help the agent manage their MCP servers.<\/p>\n With this small tweak, the agent can now help us negotiate a new MCP session. To make this a little more concrete, we\u2019ll show an agent connected to the gateway asking for the DuckDuckGo MCP and then performing a search.<\/p>\n Figure 2: A demo of using mcp-find and mcp-add to connect to the DuckDuckGo MCP server and run a search<\/p>\n In the example above, we started by connecting our agent to the catalog of MCPs (see docker mcp client connect \u2013help for options). The agent then adds a new MCP server to the current session. To be clear, the duckduckgo MCP server is quite simple. Since it does not require any configuration, all we needed to do was search the catalog, pull the image from a trusted registry, and spin up the MCP server in the local docker engine.<\/p>\n However, some MCP servers will require inputs<\/em> before they can start up. For example, remote MCP servers might require that the user go through an OAuth flow. In the next example, the gateway responds by requesting that we authorize this new MCP server. Now that MCP supports elicitations<\/a>, and frameworks like mcp-ui<\/a> allow MCPs to render UI elements into the chat, we have begun to optimize these flows based on client-side capabilities.<\/p>\n Figure 3: Using mcp-find and mcp-add to connect to the Notion MCP server, including an OAuth flow<\/p>\n In the building more efficient agents<\/a> post, the authors highlight two ways that tools currently make token consumption less efficient.<\/p>\n The result is the same in both cases. Too many tokens are not being sent to the model. It takes surprisingly few tools for the context window to accumulate hundreds of thousands of tokens of nothing but tool definition.<\/p>\n Again, this is something we can improve. In the mcp gateway<\/a> project, we\u2019ve started distinguishing between tools that are available<\/em> to a find tool, and ones that are added to the context window. Just as we\u2019re giving agents tools for server selection, we can give them new ways to select tools.<\/p>\n Figure 4: Dynamic Tools in action: Tools can now be actively selected, avoiding the need to load all available tools into every LLM request.<\/p>\n The idea is conceptually simple. We are providing an option to allow agents to add servers that do not automatically put their tools into the context window. With today\u2019s agents, this means adding MCP servers that don\u2019t return tool definitions in tools\/list<\/em> requests, but still make them available to find tool<\/em> calls. This is easy to do because we have an MCP gateway to mediate tools\/list requests<\/em> and to inject new task-oriented find<\/em> tools. New primordial<\/em> tools like mcp-exec<\/em> and mcp-find<\/em> provide agents with new ways to discover and use MCP server tools.<\/p>\n Once we start to think about tool selection differently, it opens up a range of possibilities.<\/p>\n The idea of \u201ccode mode\u201d has been getting a lot of attention since CloudFlare posted about a better way to use Tools<\/a> several weeks ago. The idea actually dates back to a paper \u201cCodeAct: Your LLM Agent Acts Better when Generating Code<\/a>\u201c, which proposed that LLMs could improve agent-oriented tasks by first consolidating agent actions into code. The recent post from Anthropic also frames code mode as a way to improve agent efficiency by reducing the number of tool definitions and tool outputs in the context window.<\/p>\n We\u2019re really excited by this idea. By making it possible for agents to \u201ccode\u201d directly against MCP tool interfaces, we can provide agents with \u201ccode-mode\u201d tools that use the tools in our current MCP catalog in new ways. By combining mcp-find<\/em> with code-mode,<\/em> the agent can still access a large, and dynamic, set of available<\/em> tools while putting just one or two new tools into the context window. Our current code-mode tool writes javascript and takes available MCP servers as parameters.<\/p>\n code-mode:<\/strong> <\/em><\/strong>Create a JavaScript-enabled tool that can call tools from any of the servers listed in the servers parameter.<\/p>\n However, this is still code written by an agent. If we\u2019re going to run this code, we\u2019re going to want it to run in a sandbox. Our MCP servers are already running in Docker containers, and the code mode sandbox is no different. In fact, it\u2019s an ideal case because this container only needs access to other MCP servers! The permissions for accessing external systems are already managed at the MCP layer.<\/p>\n This approach offers three key benefits:<\/p>\n A popular illustration of this pattern is building a code mode tool using the GitHubofficial MCP servers. The GitHub server happens to ship with a large number of tools, so code-mode will have a dramatic impact. In the example below, we\u2019re prompting an agent to create a new code-mode tool out of the Github-official and markdownify MCP servers.<\/p>\n Figure 5: Using the MCP code-mode to write code to call tools from the GitHub Official and Markdownify MCP servers<\/p>\n The combination of Smart Search and Tool Composition unlocks dynamic, secure use of MCPs. Agents can now go beyond simply finding or adding tools; they can write code to compose new tools, and run them safely in a secure sandbox.\u00a0<\/p>\n The result: faster tool discovery, lower token usage, fewer manual steps, and more focused time for developers.<\/p>\nEnabling Agents to Find, Add, and Configure MCPs Dynamically with Smart Search\u00a0<\/h2>\n
![\"Dynamic](\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/Dynamic-tools-fig1.png\" "\\"-")
\n <\/div>\n\n
![\"Dynamic](\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/Dynamic-tools-fig2.gif\" "\\"-")
\n <\/div>\nConfiguring MCP Servers with Agent-Led Workflows<\/h3>\n
![\"Dynamic](\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/Dynamic-tools-fig3.gif\" "\\"-")
Avoid An Avalanche of Tools: Dynamic Tool Selection<\/h3>\n
\n
![\"Dynamic](\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/Dynamic-tools-fig4.png\" "\\"-")
Using Tools in a new way: From Tool Calls to Tool Composition with code-mode<\/h2>\n
\n
![\"Dynamic](\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/Dynamic-tools-fig5.gif\" "\\"-")
![\"Dynamic](\"https:\/\/www.docker.com\/app\/uploads\/2025\/11\/Dynamic-tools-fig6.gif\" "\\"-")
\n <\/div>\n