An agent is only as good as the tools it can call, so tools need reusable definitions, reliable execution, and clear output schemas.
2
Separating tools from agent frameworks through MCP or a tool platform makes it easier to manage execution, credentials, errors, and framework changes.
3
Dynamic tools built around GraphQL or SQL can reduce the number of individual tools an agent sees, although generated queries can still fail.
Summary
Roy Derks argues that tool calling deserves as much design attention as the agent itself. In his view, tools are often the first part of an agent that breaks. A model may choose the wrong tool, pass invalid arguments, or encounter failures inside the tool. He explains how tool definitions need simple names, detailed descriptions, input parameters, and output schemas that support structured results and chained calls. The talk compares traditional tool calling, where application code handles callbacks and errors, with embedded tool calling, where an agent framework hides the process. Derks prefers separating the two concerns. MCP provides one way to put tool logic behind a server, while standalone tool platforms can create and execute tools remotely. He also describes dynamic GraphQL and SQL tools that let a model generate queries from a schema. This can avoid maintaining a large collection of narrow tools, but model-generated syntax remains an unpredictable part of the design.
Derks says teams spend much of their time improving agents while giving less attention to the tools those agents need. In his experience, the first failure in an agent is often a tool failure. The model may call a tool incorrectly, select the wrong tool, or trigger a problem caused by an incomplete setup. He compares the agent to a closed circuit with more dynamic tools around it. His practical conclusion is that an agent is only as good as its tools. Tools should be reusable and robust enough to move between agent frameworks, instead of being tied to one framework's extension interface.
A tool definition gives the model instructions for using the tool
A tool definition contains a name, a description, input parameters, and increasingly an output schema. Derks recommends keeping the name simple. The description can be much longer than a short label because it acts almost like a system prompt for the model. It needs to explain how the tool should be used. An output schema gives the model a structured view of the result. That matters when several calls are chained or when later steps need structured output. He gives the example of a customer-count tool that takes a country filter and returns customer data, potentially as JSON rather than an unstructured string.
Traditional tool calling leaves application code responsible for the loop
In traditional tool calling, a client sends a question to an application containing the agent. The application sends the prompt and available tools to the model, examines the model's recommended tool call, runs a callback, and sends the tool response back. The model may repeat this process before producing an answer for the client. Derks shows that this approach requires explicit handling for message roles, parsing, execution, retries, and errors. In a LangChain-style implementation, developers define the tools and callbacks, inspect the model response for tool-call messages, and execute the matching function themselves.
Embedded tool calling is easier to start with but hides decisions
Embedded tool calling puts the model, agent, and tools inside a framework-managed loop. The application passes in a question and tools, then receives the answer. Derks describes this as a black box. Framework code handles the calls, but the developer cannot see how tools are being selected or executed, and has limited control over the format beyond the supplied callback and tool definition. He considers this useful for getting started because developers do not need to implement retries or error handling themselves. The trade-off is reduced control over the calling process.
MCP separates an agent host from the server that owns tool logic
Derks presents MCP, the Model Context Protocol introduced by Anthropic, as a way to separate the client side and server side of agent applications. A host, such as a desktop application, contains a client that connects to MCP servers. A server acts like a small backend with access to tools or other assets such as data files. The host and client interact with the server rather than directly owning the tool implementation. Derks likes this separation because the server can define and import tool logic while the host and client use a common way to call it. He points to a TypeScript guide for building an MCP server.
A standalone tool platform can own creation, hosting, and execution
A standalone tool platform lets developers define tools outside the agent framework and bring them in through an SDK or API call. The agent still uses the model to decide which tool to call, but the remote platform executes it. Derks describes platforms as having a creation side and an execution or surfacing side. They can create tools from APIs or databases, chain repetitive calls, and handle authorization and errors. Separating these responsibilities also helps with credentials because a CRM and a database may require different authentication details. Derks says tools can then be built once and imported into LangChain, LangGraph, CrewAI, or another framework.
Dynamic GraphQL tools reduce the need for large collections of narrow tools
Derks describes experiments using GraphQL and SQL with clients. A CRM may contain customers, orders, contracts, and employee details, while a database may contain product, order, and payment data. Defining a separate tool for every possible filter or resource can create too many tools for the agent to handle. A dynamic GraphQL tool exposes a schema and asks the model to generate valid GraphQL. The schema tells the model which types and operations are available. Derks says models such as Llama, OpenAI models, and Claude can generate GraphQL well when the schema is provided and the queries are not too complex. He recommends avoiding custom scalars and deep nesting because these can confuse the model.
Dynamic tools save implementation work while keeping a model failure mode
Dynamic tools let developers reuse existing API or database logic instead of defining many separate tools in the agent framework. This reduces downstream integration work and avoids duplicating business logic. Derks is also clear about the cost. A model may generate valid GraphQL in one case and produce incorrect syntax in another. The same issue can apply to SQL or other query languages. Dynamic tools therefore provide flexibility, but their reliability depends on the model's ability to generate the required query correctly. Derks sees a future for dynamic tools alongside static tools, with the trade-off kept visible.
"I always feel like every time I'm building an agent first thing that breaks is the tools."02:37
Who should watch
You are building agents inside a framework and want to move their tools between LangChain, LangGraph, CrewAI, AutoGen, or another framework.
Your tools fail because of unclear schemas, callback errors, retries, authentication, or model-generated arguments.
You are deciding whether to expose many narrow API tools or let a model query a GraphQL or SQL schema.
