What will I learn in chapter 3 of Build an AI Agent (From Scratch)?

The chapter introduction explains why agents need tools and sketches how an LLM uses a tool result to produce an answer. After reading it you should be able to: Explain why an LLM needs tools to access external data or interact with external systems, and how tools enable an agent to take actions step by step. Trace the introductory flow from tool information in the LLM’s context through tool execution and its result to a final answer. Explain the temporal, interaction, and functional limitations of LLMs and why tools are needed to address them. Explain how information-augmenting tools give an agent access to knowledge beyond an LLM’s training cutoff, using an example from the section. Describe how action-executing tools let an agent interact with the world and receive observations in return. Explain why an agent may use a domain-specialized tool instead of relying on the LLM alone, using an example from the section. Distinguish custom tools from provider-supplied tools, including who builds and maintains them and the tradeoff between tailoring and convenience. Explain when a provider tool is a sensible choice. Explain why the book emphasizes custom tools even though providers offer ready-made ones: internal understanding helps diagnose agent failures, and specialized real-world capabilities may not be available from providers.

What does section 3.1, LLM tools, cover?

This section explains why LLMs need tools by identifying three limitations that prevent them from acting as fully autonomous agents. Explain the temporal, interaction, and functional limitations of LLMs and why tools are needed to address them.

What does section 3.1.1, Why do we need LLM tools?, cover?

This section explains why agents need three kinds of tools: to obtain current information, act on the world, and perform specialized tasks reliably. Explain how information-augmenting tools give an agent access to knowledge beyond an LLM’s training cutoff, using an example from the section. Describe how action-executing tools let an agent interact with the world and receive observations in return. Explain why an agent may use a domain-specialized tool instead of relying on the LLM alone, using an example from the section.

What does section 3.1.2, Types of LLM tools, cover?

This section contrasts developer-built and provider-supplied LLM tools and explains why custom tools remain valuable despite convenient built-in options. Distinguish custom tools from provider-supplied tools, including who builds and maintains them and the tradeoff between tailoring and convenience. Explain when a provider tool is a sensible choice. Explain why the book emphasizes custom tools even though providers offer ready-made ones: internal understanding helps diagnose agent failures, and specialized real-world capabilities may not be available from providers.

What does section 3.2, How LLMs use tools, cover?

Introduces how a text-generating LLM uses tool definitions to request actions that an external executor performs. Explain how an LLM can select a tool and request its use without executing it directly: it receives a tool definition, generates a structured tool call, and relies on an external executor to run the tool.

What does section 3.2.1, How tool calling works, cover?

This section explains how an LLM requests a tool call, how the host application executes it, and how the result returns to the LLM for a final answer. Describe how a structured tool definition tells the LLM which tool is available and what inputs it accepts, using the calculator example. Distinguish a direct LLM answer from a tool-call response using the capital and multiplication questions. Explain the division of work between the LLM and host application when a tool is called.

What does section 3.2.2, How an LLM chooses tools, cover?

This section explains how training on tool-use examples enables an LLM to choose a tool and produce a structured call with the right inputs. Explain how examples pairing tool definitions with appropriate calls teach an LLM to recognize when a tool is needed, select one, extract argument values from a request, and format the call.

What does section 3.2.3, Guidelines for effective tool calling, cover?

The section gives practical schema-design guidelines that make LLM tool calls clearer, less error-prone, and easier for application code to handle. Explain how a tool’s name, description, and parameter schema tell an LLM when and how to use it. Describe why the vague name book is less reliable than a definition that states the action, required and optional inputs, formats, ranges, and expected output. Explain why mutually exclusive Boolean parameters can produce contradictory tool calls, and describe how a single enum and schema validation avoid that problem. Explain why code should retain identifiers already obtained and inject them into tool calls, leaving the model to supply only the decision input. Use the refund example to describe the risks of making the model repeat an order_id.

What does section 3.3.1, Implementing a web search tool, cover?

This section builds a Tavily-backed web search function, then adds search options and basic error handling. Trace how the basic search_web function loads a Tavily API key, creates a client, sends a query, and returns results. Explain why the section starts with a minimal configuration. Describe how optional parameters make web search more targeted, and explain the tradeoff of exposing more options to an LLM. Explain what the catchall error handler returns when search fails, and distinguish that learning example from the error-specific handling a production tool may need.

What does section 3.3.2, Converting to tool definitions, cover?

This section explains why Python tools need standardized definitions for LLM access and how to generate those definitions automatically from function metadata. Explain why a web search tool or calculator function must be represented in a standardized tool-definition format for an LLM, and why automatic conversion is preferable to maintaining definitions by hand. Describe how the utility derives a tool definition from a Python function’s name, docstring, and signature, including parameter types and which parameters are required.

What does section 3.3.3, End-to-end tool execution, cover?

This section connects LLM tool calls to registered functions, then uses a conversation loop to return tool results to the LLM until it can answer. Explain how the execution utility turns an LLM tool call into a function call using a toolbox. Trace how the control loop exchanges messages between the LLM and tools, including when it stops. Explain why the example question prompts a web search and how the LLM uses its result.

What does section 3.3.4, The challenges of custom tools, cover?

This section explains why custom LLM tools become difficult to build, share, and maintain at scale, motivating a common standard for tools. Explain why integrating a service not designed for LLMs takes more work than the Tavily example. Describe the need to learn each service’s conventions and turn its responses into something useful for an LLM. Explain why the minimal error handling in the example search tool would not suffice in production, and describe the kinds of failures a real tool must handle. Explain why teams can duplicate tool-building work even when they need similar capabilities, and why borrowing another team’s implementation may still be difficult.

What should I know before reading chapter 3?

Results and analysis: Why LLMs need tools (chapter 2): The earlier discussion of LLM limitations.; Conversation management: Handling stateless APIs (chapter 2): Managing conversation history when making calls to a stateless API.

Chapter 3: Enabling actions: Tool use

What you will learn in chapter 3 of Build an AI Agent (From Scratch)

The chapter introduction explains why agents need tools and sketches how an LLM uses a tool result to produce an answer.

After this chapter you will be able to

Tools for external action. Explain why an LLM needs tools to access external data or interact with external systems, and how tools enable an agent to take actions step by step.
Tool use response flow. Trace the introductory flow from tool information in the LLM’s context through tool execution and its result to a final answer.
Three LLM limitations. Explain the temporal, interaction, and functional limitations of LLMs and why tools are needed to address them.
Current information through tools. Explain how information-augmenting tools give an agent access to knowledge beyond an LLM’s training cutoff, using an example from the section.
Real-world actions and feedback. Describe how action-executing tools let an agent interact with the world and receive observations in return.
Reliable specialized execution. Explain why an agent may use a domain-specialized tool instead of relying on the LLM alone, using an example from the section.
Custom and provider tool tradeoffs. Distinguish custom tools from provider-supplied tools, including who builds and maintains them and the tradeoff between tailoring and convenience. Explain when a provider tool is a sensible choice.
Reasons to build custom tools. Explain why the book emphasizes custom tools even though providers offer ready-made ones: internal understanding helps diagnose agent failures, and specialized real-world capabilities may not be available from providers.
Tool calling division of labor. Explain how an LLM can select a tool and request its use without executing it directly: it receives a tool definition, generates a structured tool call, and relies on an external executor to run the tool.
Tool definition schema. Describe how a structured tool definition tells the LLM which tool is available and what inputs it accepts, using the calculator example.
Host-side tool execution. Explain the division of work between the LLM and host application when a tool is called.
Tool result feedback loop. Trace how an executed tool’s result is returned to the LLM and becomes a user-facing answer.
Learning tool calls from examples. Explain how examples pairing tool definitions with appropriate calls teach an LLM to recognize when a tool is needed, select one, extract argument values from a request, and format the call.
Explicit tool definitions. Explain how a tool’s name, description, and parameter schema tell an LLM when and how to use it. Describe why the vague name book is less reliable than a definition that states the action, required and optional inputs, formats, ranges, and expected output.
Nonconflicting parameter design. Explain why mutually exclusive Boolean parameters can produce contradictory tool calls, and describe how a single enum and schema validation avoid that problem.
Code-held identifiers. Explain why code should retain identifiers already obtained and inject them into tool calls, leaving the model to supply only the decision input. Use the refund example to describe the risks of making the model repeat an order_id.
Basic Tavily search function. Trace how the basic search_web function loads a Tavily API key, creates a client, sends a query, and returns results. Explain why the section starts with a minimal configuration.
Search options and tradeoffs. Describe how optional parameters make web search more targeted, and explain the tradeoff of exposing more options to an LLM.
Search failure handling. Explain what the catchall error handler returns when search fails, and distinguish that learning example from the error-specific handling a production tool may need.
Standardized Tool Definitions. Explain why a web search tool or calculator function must be represented in a standardized tool-definition format for an LLM, and why automatic conversion is preferable to maintaining definitions by hand.
Function Metadata Conversion. Describe how the utility derives a tool definition from a Python function’s name, docstring, and signature, including parameter types and which parameters are required.
Tool call execution utility. Explain how the execution utility turns an LLM tool call into a function call using a toolbox.
Tool conversation control loop. Trace how the control loop exchanges messages between the LLM and tools, including when it stops.
Need for tool standardization. Justify the section’s call for a common way to define, share, and integrate LLM tools across projects and LLM providers.
MCP tool integration standard. Explain why MCP makes tools easier to reuse: it gives compatible agents and tools a common way to communicate, avoiding custom integration code for each tool.
MCP component roles. Explain the distinct roles of the host, client, and server when an agent uses MCP tools.
Standardized tool interfaces. Describe how MCP standardizes tool discovery and tool execution in place of manually connecting definitions and function calls.
Inspector tool discovery and execution. Trace how to connect to the server in MCP Inspector, discover its tools, and run a search.
Standardized ready-made tools. Explain what the Tavily example demonstrates about using standardized MCP tools instead of implementing basic search yourself.
MCP client tool interaction. Trace how a programmatic MCP client launches a server, establishes a session, discovers tools, and calls a tool with arguments.
MCP tool format conversion. Explain why discovered MCP tool definitions need conversion for an LLM API and how the section converts them to OpenAI tool definitions.
FastMCP server wrapper. Describe how the existing search_web function becomes an MCP tool without changing its core search logic.
Custom server client connection. Explain how the existing client connects to the custom server and what confirms that the tool is available.
MCP implementation use separation. Explain what the similar client experience with the official and custom servers demonstrates about MCP.

Cover of Build an AI Agent (From Scratch)

liveBook manning.com

Read chapter 3 on liveBook Get the book at manning.com

What it builds on

Results and analysis: Why LLMs need tools (chapter 2) · The earlier discussion of LLM limitations.
Conversation management: Handling stateless APIs (chapter 2) · Managing conversation history when making calls to a stateless API.

Section by section

Introduction

The chapter introduction explains why agents need tools and sketches how an LLM uses a tool result to produce an answer.

Tools for external action: Explain why an LLM needs tools to access external data or interact with external systems, and how tools enable an agent to take actions step by step.
Why it matters: Tools are what let the agent do more than generate text from what the LLM already has.
Tool use response flow: Trace the introductory flow from tool information in the LLM’s context through tool execution and its result to a final answer.
Why it matters: This flow shows how a tool’s result becomes information the LLM can use in its answer.

Key terms: LLMs, tools, agent, next action, Tool info, tool execution, context, final answer

3.1 LLM tools

This section explains why LLMs need tools by identifying three limitations that prevent them from acting as fully autonomous agents.

Three LLM limitations: Explain the temporal, interaction, and functional limitations of LLMs and why tools are needed to address them.
Why it matters: These limits explain why a capable language model still needs tools to function as an agent.

Key terms: temporal, interaction, functional, tools

3.1.1 Why do we need LLM tools?

This section explains why agents need three kinds of tools: to obtain current information, act on the world, and perform specialized tasks reliably.

Current information through tools: Explain how information-augmenting tools give an agent access to knowledge beyond an LLM’s training cutoff, using an example from the section.
Why it matters: This explains how an agent can answer questions that require information its LLM was not trained on.
Real-world actions and feedback: Describe how action-executing tools let an agent interact with the world and receive observations in return.
Why it matters: An agent needs more than generated text when a task requires something to happen outside the conversation.
Reliable specialized execution: Explain why an agent may use a domain-specialized tool instead of relying on the LLM alone, using an example from the section.
Why it matters: Specialized tools let the agent rely on an appropriate executor for tasks the LLM may not perform reliably itself.

Key terms: information-augmenting tools, temporal gap, training cutoff, agent’s context, action-executing tools, interaction limitation, observations, feedback loop, domain-specialized tools, functional limitations

3.1.2 Types of LLM tools

This section contrasts developer-built and provider-supplied LLM tools and explains why custom tools remain valuable despite convenient built-in options.

Custom and provider tool tradeoffs: Distinguish custom tools from provider-supplied tools, including who builds and maintains them and the tradeoff between tailoring and convenience. Explain when a provider tool is a sensible choice.
Why it matters: The tradeoff helps you choose a tool without overlooking who controls and supports it.
Reasons to build custom tools: Explain why the book emphasizes custom tools even though providers offer ready-made ones: internal understanding helps diagnose agent failures, and specialized real-world capabilities may not be available from providers.
Why it matters: These reasons explain why learning to build tools is useful even when a provider offers ready-made options.

Key terms: custom tools, noncustom tools, built-in tools, LLM provider, tool selection, domain-specific logic

3.2 How LLMs use tools

Introduces how a text-generating LLM uses tool definitions to request actions that an external executor performs.

Tool calling division of labor: Explain how an LLM can select a tool and request its use without executing it directly: it receives a tool definition, generates a structured tool call, and relies on an external executor to run the tool.
Why it matters: This distinction separates what the model generates from the action the surrounding system actually takes.

Key terms: tool calling, tool definition, tool call, external executor, arguments

3.2.1 How tool calling works

This section explains how an LLM requests a tool call, how the host application executes it, and how the result returns to the LLM for a final answer.

Tool definition schema: Describe how a structured tool definition tells the LLM which tool is available and what inputs it accepts, using the calculator example.
Why it matters: The LLM needs a description of a tool and its inputs before it can request a usable call.
Selective tool requests: Distinguish a direct LLM answer from a tool-call response using the capital and multiplication questions.
Why it matters: Providing a tool does not mean every question must invoke it.
Host-side tool execution: Explain the division of work between the LLM and host application when a tool is called.
Why it matters: Tool calling only produces an action when the surrounding application carries out the LLM’s request.
Tool result feedback loop: Trace how an executed tool’s result is returned to the LLM and becomes a user-facing answer.
Why it matters: Returning results lets the LLM use tool output rather than leaving the user with an unresolved tool request.

Key terms: tool definitions, type, function, name, description, parameters, tool_calls, content, tool call, host system

3.2.2 How an LLM chooses tools

This section explains how training on tool-use examples enables an LLM to choose a tool and produce a structured call with the right inputs.

Learning tool calls from examples: Explain how examples pairing tool definitions with appropriate calls teach an LLM to recognize when a tool is needed, select one, extract argument values from a request, and format the call.
Why it matters: This explains how a model turns a request into a tool call with usable inputs.

Key terms: tool definitions, tool calls, parameter values, structured data, function names and arguments

3.2.3 Guidelines for effective tool calling

The section gives practical schema-design guidelines that make LLM tool calls clearer, less error-prone, and easier for application code to handle.

Explicit tool definitions: Explain how a tool’s name, description, and parameter schema tell an LLM when and how to use it. Describe why the vague name book is less reliable than a definition that states the action, required and optional inputs, formats, ranges, and expected output.
Why it matters: A clear definition helps the model select the right tool and supply usable inputs.
Nonconflicting parameter design: Explain why mutually exclusive Boolean parameters can produce contradictory tool calls, and describe how a single enum and schema validation avoid that problem.
Why it matters: Unambiguous parameters reduce failed calls and make invalid requests straightforward to reject.
Code-held identifiers: Explain why code should retain identifiers already obtained and inject them into tool calls, leaving the model to supply only the decision input. Use the refund example to describe the risks of making the model repeat an order_id.
Why it matters: Keeping known identifiers in code makes multistep calls cheaper and less likely to act on the wrong item.
Tool count guideline: State the section’s general tool-count guideline and explain why offering too many tools can hurt tool selection.
Why it matters: Even well-defined individual tools can be harder for the model to choose among when too many are offered.

Key terms: tool schema, function names, parameter descriptions, required and optional parameters, mutually exclusive Booleans, enum, schema, validate ranges and formats, order_id, decision input

3.3 Building tools and tool definitions for LLMs

Introduces the upcoming exercise of building a web search tool from scratch.

3.3.1 Implementing a web search tool

This section builds a Tavily-backed web search function, then adds search options and basic error handling.

Basic Tavily search function: Trace how the basic search_web function loads a Tavily API key, creates a client, sends a query, and returns results. Explain why the section starts with a minimal configuration.
Why it matters: This gives you a working search function before adding complexity.
Search options and tradeoffs: Describe how optional parameters make web search more targeted, and explain the tradeoff of exposing more options to an LLM.
Why it matters: Useful search controls must be balanced against the difficulty of using the tool correctly.
Search failure handling: Explain what the catchall error handler returns when search fails, and distinguish that learning example from the error-specific handling a production tool may need.
Why it matters: A search tool must make failures visible without assuming every failure should be handled the same way.

Key terms: TavilyClient, load_dotenv(), TAVILY_API_KEY, search_web, max_results, topic, time_range, tool definition, try-except, list | str

3.3.2 Converting to tool definitions

This section explains why Python tools need standardized definitions for LLM access and how to generate those definitions automatically from function metadata.

Standardized Tool Definitions: Explain why a web search tool or calculator function must be represented in a standardized tool-definition format for an LLM, and why automatic conversion is preferable to maintaining definitions by hand.
Why it matters: A tool’s Python implementation alone is not the definition the LLM needs to use it.
Function Metadata Conversion: Describe how the utility derives a tool definition from a Python function’s name, docstring, and signature, including parameter types and which parameters are required.
Why it matters: Reading the function’s metadata lets one utility produce definitions that reflect the functions it is given.

Key terms: tool definition, standardized tool-definition format, utility function, inspect, __name__, __doc__, inspect.signature, parameter types, required arguments

3.3.3 End-to-end tool execution

This section connects LLM tool calls to registered functions, then uses a conversation loop to return tool results to the LLM until it can answer.

Tool call execution utility: Explain how the execution utility turns an LLM tool call into a function call using a toolbox.
Why it matters: A tool call only produces an action when application code connects it to a registered function.
Tool conversation control loop: Trace how the control loop exchanges messages between the LLM and tools, including when it stops.
Why it matters: Returning each result to the conversation lets the LLM use external information before giving its final answer.
Current information search example: Explain why the example question prompts a web search and how the LLM uses its result.
Why it matters: The example shows what the execution loop enables when an answer depends on up-to-date information.

Key terms: toolbox, tool call, tool name, arguments, control loop, tool definitions, conversation history, tool message, current information, search_web

3.3.4 The challenges of custom tools

This section explains why custom LLM tools become difficult to build, share, and maintain at scale, motivating a common standard for tools.

Unfamiliar API integration costs: Explain why integrating a service not designed for LLMs takes more work than the Tavily example. Describe the need to learn each service’s conventions and turn its responses into something useful for an LLM.
Why it matters: A short tool function can hide considerable work needed to understand and adapt the service behind it.
Production error handling burden: Explain why the minimal error handling in the example search tool would not suffice in production, and describe the kinds of failures a real tool must handle.
Why it matters: A tool that works in a quick demonstration may still fail unpredictably or unhelpfully in production.
Cross-team tool reuse friction: Explain why teams can duplicate tool-building work even when they need similar capabilities, and why borrowing another team’s implementation may still be difficult.
Why it matters: Sharing a tool saves little effort if another team must substantially adapt it before use.
Growing tool maintenance burden: Describe why custom tools require continuing maintenance and why that burden grows as an agent gains more tools.
Why it matters: The cost of a tool continues after its first successful implementation.
Need for tool standardization: Justify the section’s call for a common way to define, share, and integrate LLM tools across projects and LLM providers.
Why it matters: A common standard addresses friction that grows when every tool and team uses its own approach.

Key terms: Tavily, API conventions, response formats, error handling, rate limits, backoff strategies, input validation, tool definitions, synchronous, asynchronous

3.4 MCP: Standardizing tools

This section explains how MCP standardizes tool integration so agents can reuse third-party tools without custom wrappers.

MCP tool integration standard: Explain why MCP makes tools easier to reuse: it gives compatible agents and tools a common way to communicate, avoiding custom integration code for each tool.
Why it matters: A shared integration standard can save developers from building or wrapping every tool themselves.

Key terms: MCP, MCP-compatible agent, MCP-compatible tool, custom tool wrappers

3.4.1 The core of MCP: Server–client architecture

This section explains how MCP separates an LLM-powered host from tool servers through clients, standardizes tool discovery and execution, and supports local or remote communication.

MCP component roles: Explain the distinct roles of the host, client, and server when an agent uses MCP tools.
Why it matters: These roles show where an agent’s decisions end and tool communication and execution begin.
Standardized tool interfaces: Describe how MCP standardizes tool discovery and tool execution in place of manually connecting definitions and function calls.
Why it matters: The shared interfaces let compatible clients discover and invoke tools without each integration defining its own bridge.
Local and remote transports: Distinguish stdio from streamable HTTP as ways an MCP client communicates with a server.
Why it matters: Transport choice determines whether a tool server is local or reachable over a network without changing what its tools do.
MCP capability scope: State which capabilities MCP servers can provide and which one this book concentrates on.
Why it matters: This distinction keeps the chapter’s focus on tool use without mistaking tools for MCP’s entire scope.

Key terms: host, MCP client, MCP server, tool discovery, tool execution, tool definitions, schema, stdio, standard I/O, streamable HTTP

3.4.2 Hands-on: Running an MCP server

Walks through running the ready-made Tavily MCP server, testing its tools in MCP Inspector, and showing the benefit of standardized tools.

Tavily server launch setup: Describe the prerequisites for launching the Tavily MCP server and the roles of npx, MCP Inspector, and the Tavily server package.
Why it matters: These pieces let you run and test an existing MCP server without building one first.
Inspector tool discovery and execution: Trace how to connect to the server in MCP Inspector, discover its tools, and run a search.
Why it matters: It shows how a client can discover and test a server’s tools through a common interface.
Standardized ready-made tools: Explain what the Tavily example demonstrates about using standardized MCP tools instead of implementing basic search yourself.
Why it matters: Standardization lets agent developers reuse capable tools rather than reimplementing each integration.

Key terms: Node.js, Tavily API key, npx, MCP Inspector, tavily-mcp@latest, Connect, Tools, List Tools, tavily_search, parameter schema

3.4.3 Understanding the MCP client

This section shows how an MCP client connects to a server, discovers and invokes its tools, and converts their definitions for an LLM provider.

MCP client tool interaction: Trace how a programmatic MCP client launches a server, establishes a session, discovers tools, and calls a tool with arguments.
Why it matters: This is how an agent uses MCP tools programmatically rather than through a testing interface.
MCP tool format conversion: Explain why discovered MCP tool definitions need conversion for an LLM API and how the section converts them to OpenAI tool definitions.
Why it matters: Discovery alone does not make a tool definition usable in an LLM API request; the client must present it in the provider’s format.

Key terms: MCP client, stdio_client, ClientSession, initialize(), list_tools(), call_tool(), MCP schema format, inputSchema, JSON schema, format_tool_definition

3.4.4 Hands-on: Implementing an MCP server

Shows how to expose an existing search function through a custom MCP server, connect to it with a familiar client, and see how MCP separates tool implementation from tool use.

FastMCP server wrapper: Describe how the existing search_web function becomes an MCP tool without changing its core search logic.
Why it matters: You can expose an existing Python tool through MCP without rewriting what the tool does.
Custom server client connection: Explain how the existing client connects to the custom server and what confirms that the tool is available.
Why it matters: The same client approach works for a server you build yourself.
MCP implementation use separation: Explain what the similar client experience with the official and custom servers demonstrates about MCP.
Why it matters: This separation lets tool builders and agent builders work on their respective concerns without requiring a new client interface for each server.

Key terms: FastMCP, search_web, @mcp.tool(), tool schema, docstring, stdio, StdioServerParameters, tool discovery, tool execution, MCP

3.5 Summary

Summarizes how tools extend LLMs, how tool calls become externally executed actions, and why MCP helps standardize tools.

Where this is used later

The think-act cycle (chapter 4) · Develops the agent’s step-by-step think-act cycle.
The problem of using internal data (chapter 5) · The discussion of using internal data builds on tools that retrieve information for an agent.
What code execution brings (chapter 8) · The discussion of code execution extends the idea of pairing LLM reasoning with a specialized execution capability.
(chapter intro) (chapter 4) · The ability of an LLM to call tools supplies the actions that the agent can take.
From text parsing to tool calling (chapter 4) · The earlier explanation of how LLM tool calling works.
The approach: Tools as output formatters (chapter 4) · The existing tool-calling mechanism that the approach reuses.
The think() and act() methods (chapter 4) · The agent’s think and act methods depend on the distinction between requesting and performing an action.
Agent as Tool: Calling agents as tools (chapter 9) · LLMs can choose which tools to call.

Concepts explained in this chapter

tool usageA tool call is a model-generated specification requesting invocation of a particular external tool with particular arguments.
tool descriptionA tool definition is a structured declaration of a callable tool's name, description, parameters, types, and required arguments for access by a language model.
MCPModel Context Protocol is an open protocol that standardizes how AI applications connect to tools, prompts, resources, and external services.
tool executionTool execution is the process of sending a tool request with arguments to a server, running the tool, and returning its result.
MCP serverAn MCP server is a protocol component that exposes tools, executes requested tools, and returns their results, potentially by connecting to external services or data.
validationData validation is the process of checking data against specified structural, type, and constraint requirements.
dynamic tool discoveryTool discovery is the standardized process by which a client requests and receives the definitions of tools available from a server.
mcp clientAn MCP client is the protocol component that connects a host application to one MCP server, retrieves tool definitions, and forwards tool-execution requests.
JSON SchemaJSON Schema is a standard for describing and validating the structure, types, allowed values, and required fields of JSON data.
tool resultA tool result is the output produced by an external tool after processing an invocation and its arguments, including whether execution succeeded or failed.
exceptionError handling is the detection and management of failures arising during program execution or external requests.
web searchWeb search is a tool capability that retrieves information from internet-accessible search indexes or pages.
exponential backoffA backoff strategy progressively delays repeated operations after transient failures or service throttling.
rate limitA rate limit is a provider-imposed bound on how many requests or operations a client may perform within a period or concurrently.
schemaA schema is a formal specification of the fields, types, and constraints that valid structured data must satisfy.
ReActThe ReAct pattern is an agent design in which reasoning and action alternate so the agent can incorporate tool results and adapt its subsequent behavior.
structured dataData organized according to a defined schema with predictable fields, types, or relationships.
training datasetTraining data is the collection of examples used to fit a machine-learning model's parameters and learned patterns.
tool selectionTool selection is the process by which a language model determines whether a tool is needed and chooses the appropriate available tool.
continuous improvementA reasoning process that repeatedly evaluates intermediate results and determines subsequent steps.

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.