There are three key issues when agents interact with MCP servers traditionally: - Context flooding - All tool definitions are loaded upfront, including ones that might not be necessary for a certain task. - Sequential execution overhead - Some operations require multiple tool calls in a chain. Normally, the agent must execute them sequentially and load intermediate return values into the context, wasting time and tokens (costing both time and money). - Code vs. tool calling - Models are better at writing code than calling tools directly.
To solve these issues, they proposed a new method: instead of letting models perform direct tool calls to the MCP server, the client should allow the model to write code that calls the tools.
This way, the model can write for loops and sequential operations using the tools, allowing for more efficient and faster execution. For example, if you ask an agent to rename all files in a folder to match a certain pattern, the traditional approach would require one tool call per file, wasting time and tokens. With Code Mode, the agent can write a simple for loop that calls the move_file tool from the filesystem MCP server, completing the entire task in one execution instead of dozens of sequential tool calls.
We implemented Code Mode in mcp-use's (repo https://github.com/mcp-use/mcp-use ) MCPClient . All you need to do is define which servers you want your agent to use, enable code mode, and you're done!
The client will expose two tools: - One that allows the agent to progressively discover which servers and tools are available - One that allows the agent to execute code in an environment where the MCP servers are available as Python modules (SDKs)
Is this going against MCP? Not at all. MCP is the enabler of this approach. Code Mode can now be done over the network, with authentication, and with proper SDK documentation, all made possible by Model Context Protocol (MCP)'s standardized protocol.
Hope you like it and have some improvements to propose :)
luigipederzani•35m ago
For some mcp servers, having domain-specific batch operations or embedded execution could unlock more efficient workflows.
ndimares•6m ago
We have a platform (Gram) which is serverless MCP. Now users can launch MCP servers that only have 3 tools, search, describe, execute. Gram handles the tool routing, and execution (acting sort of like the sandbox). So the client only ever needs to know about those three tools. Everything else is abstracted.