From: aidotengineer
Tool calling is not merely “plumbing” for AI agents; it is more important than some people realize and can be effectively used with agentic frameworks [00:00:04]. While much attention is often given to improving the agents themselves, building reusable and robust tools for agents has been less emphasized [00:00:55]. However, this trend is changing, with more tool platforms and libraries emerging to facilitate tool development [00:01:06]. The belief is that an agent is only as effective as its tools, and therefore, focus should be on creating tools that are reusable and robust across different agent frameworks [00:02:56].
The Role of Tools in Agent Frameworks
In a typical agent loop, a user sends a prompt, and the agent, utilizing large language models and memory, relies on tools to find answers [00:01:56]. When an agent breaks, it’s often due to issues with the tools, such as the large language model failing to call the correct tool or problems within the tool itself [00:02:35]. The application layer, specifically where tools are built, deserves more attention as it offers significant opportunities for improvement on top of models [00:02:24].
For example, to answer a question like “How far does the moon orbit expressed as the number of trips between Amsterdam and San Francisco?”, an agent might perform a series of tool calls [00:04:50]. This could involve searching for distances via external APIs (e.g., web search, geographical databases) and performing calculations using a JavaScript function or an external API like Wolfram Alpha [00:05:37].
Defining Tools for AI Agents
The way tools are defined significantly impacts their utility [00:05:54]. A typical tool definition includes:
- Tool Name: Advised to be simple [00:06:04].
- Tool Description: Acts almost like a system prompt for the large language model, guiding its use of the tool [00:06:09]. Long and detailed descriptions, sometimes resembling system prompts, are common in larger, more agentic tools [00:06:21].
- Input Parameters: Specifies the variables required for the tool to be called [00:06:40].
- Output Schema: Increasingly important, this helps make tools type-safe, enables structured outputs, and allows for chaining tool calls [00:06:48]. It informs the model about the expected data return type, even if the primary output is a string [00:07:06].
Types of Tool Calling Implementations
Historically, the location and method of tool calling within agent frameworks have evolved:
Traditional Tool Calling
In this model, the client application sends a prompt to an agent or AI application, which then sends it to the large language model along with tool definitions [00:09:02]. The model recommends tool calls, and the application explicitly parses and executes these calls using defined callback functions [00:09:42]. This involves significant back-and-forth communication between the application logic and the large language model, requiring explicit handling of queuing, retries, and errors [00:10:08]. This approach offers more control over the tool calling process [00:10:20].
Embedded Tool Calling
This approach treats the agent as a closed system [00:11:24]. The client app simply asks a question, and the agent, which contains the tools and connects with the large language model, handles all tool calling logic internally [00:11:40]. The tools are defined within the same agent, and the application receives only the final answer [00:12:11]. While easy to implement for beginners as it abstracts away error handling and retries [00:13:13], it offers no control over the tool calling process or decision-making inside the black box [00:13:19].
Separating Concerns: Tool Calling and Agent Frameworks
A key principle for building effective AI agents is the separation of concerns [00:13:42].
Model Context Protocol (MCP)
Introduced by Anthropic, MCP is a protocol designed to separate the client and server sides of agentic applications [00:14:53]. In MCP, a host (client) connects to servers that have access to tools or assets [00:15:10]. The host and client do not directly see the tools; rather, the server makes them available [00:15:29]. This clear distinction between front-end and back-end logic, where the MCP server handles tool definition, import, and execution, is a good step towards separating tool calling from the agentic framework [00:15:41].
Standalone Tool Platforms
A standalone tool platform means that tools are defined and hosted separately from the agentic framework [00:16:30]. Agents can then import these tools via an SDK or API call [00:16:48]. This approach centralizes tool creation and execution remotely [00:16:54]. The agent decides which tool to call and passes the request to the tool platform for execution [00:17:02].
These platforms often consist of:
- Tool Creation: Done via code or CLIs [00:17:40].
- Tool Execution/Surfacing: Done via SDKs that connect to agent frameworks like LangChain or CrewAI [00:17:46].
Benefits of standalone tool platforms include:
- Chaining Tools: Allows for sequential execution of tools, handling repetitive patterns [00:17:59].
- Authorization and Error Handling: Centralized management of credentials, authorization, and error handling for various connected systems (CRMs, databases) [00:18:25].
- Flexibility: Enables building tools once and bringing them into different agentic frameworks like LangChain, LangGraph, CrewAI, or Autogen, simplifying framework switching [00:18:58]. This also supports integration of third-party tools with AI web agents.
Dynamic Tools
Instead of creating a multitude of static tools for every specific function (e.g., a different tool for each component of a CRM), dynamic tools offer a more flexible approach [00:21:34].
For example, a dynamic tool can connect to a GraphQL schema or SQL database [00:22:29]. The large language model is given access to the schema and tasked with generating a valid query (e.g., GraphQL query) to interact with the database or API [00:22:55]. Models like Llama, OpenAI, and Claude have shown proficiency in generating GraphQL queries given a clear schema [00:23:29].
This approach reduces the need to define numerous individual tools and avoids duplicating business logic [00:24:23]. However, there are trade-offs, as LLMs might hallucinate or struggle with complex schemas, leading to incorrect syntax [00:24:36]. Despite these challenges, the future of dynamic tools appears promising [00:24:48].
Conclusion
As AI agents become more prevalent, it is crucial not to overlook the importance of the tools they utilize [00:24:58]. By focusing on robust tool definitions, adopting architectures that promote separation of concerns, and exploring dynamic tool capabilities, developers can significantly enhance the effectiveness, reusability, and maintainability of their AI applications [00:02:56].