iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
AI agents use tools through a handoff: an application or hosted runtime exposes callable operations, the model requests a tool and supplies arguments, and an execution environment runs it and returns the result. The model’s request is not itself execution of arbitrary code. To understand how an agent chooses and uses tools, separate three decisions: what tools are available, who executes a call, and which runtime manages the agent’s orchestration and state.
What happens when an agent calls a tool?
A tool call connects a model’s decision to an operation defined and made available by an application, platform, or connected service. The exact message format and execution path vary by integration, but the common sequence is:
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
- Declare the tools. The application or runtime supplies tool descriptions and input shapes, such as a function name and the arguments it accepts. Some platforms also make hosted tools or tools discovered through a connected server available.
- Request a call. Given the task and available definitions, the model can return a structured request selecting a tool and specifying its arguments. That request indicates what the model wants done; it does not establish that the operation has run.
- Execute the operation. An application handler, a hosted service, or another configured runtime performs the call. Which one runs it depends on the integration.
- Return the result. The execution environment sends the result back into the model’s interaction. The model can then respond, request another tool, or continue the workflow.
Anthropic’s tool-use documentation describes this handoff for Claude: a response can contain a tool_use block, and for a developer-defined function the application executes the requested operation. OpenAI’s tools guidance describes several possible integrations, including built-in tools, function calling, programmatic tool calling, tool search, and remote MCP servers. Those are product-specific options, not one universal agent interface.
Free tools Windows power users keep installed
One-click scans. No signup required.
What does the model decide, and what does the runtime decide?
The model can select among the tools made available to it and formulate a request using their declared inputs. The application or runtime determines which definitions to expose, how to execute a request, what permissions and resources the execution has, and what result to return. A model’s ability to request a tool therefore does not mean it can independently access a computer, service, or arbitrary code.
#1 Best Overall
Tool descriptions and input schemas matter because they tell the model what an operation is for and how to request it. They do not by themselves guarantee that the model will choose the right operation or provide suitable arguments. The orchestration layer still has to handle the request, and the execution layer has to define what the operation is allowed to do.
How do function calling and MCP differ?
Function calling is an integration pattern: the application defines a callable function and its input shape, receives the model’s structured request, and routes it to a handler or other execution environment. The application is responsible for implementing or connecting that handler.
The Model Context Protocol (MCP) standardizes connectivity between an agent runtime and a server that publishes tools and handles calls. In the OpenAI Agents API documentation, a connected runtime discovers the server’s available tools, calls them, and receives their results. MCP concerns how tools are exposed and called across that connection; it does not make the model’s decision about whether a tool applies.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Aspect | Function calling | MCP-connected tools |
|---|---|---|
| How tools are exposed | The application or integration supplies function definitions and input shapes. | An MCP server publishes tool definitions for a connected runtime to discover. |
| How calls are handled | The application routes a model request to its function handler or configured service. | The runtime sends calls to the MCP server, which handles them and returns results. |
| What the model still needs to do | Choose a suitable exposed function and provide arguments. | Choose a suitable discovered tool and provide arguments. |
| What the protocol or interface does not decide | Whether the operation is appropriate for the task or safe to run. | Whether the operation is appropriate for the task or safe to run. |
These approaches are not mutually exclusive: an agent can use application-defined functions alongside other integrations, including tools provided through MCP. The choice is about how a tool is defined, discovered, and connected—not a guarantee of better tool selection.
How can an agent’s available tools be narrowed?
Agents may receive tools directly in their configuration, discover them through a connected MCP server, or use tool search where the integration supports it. A larger potential tool catalog does not mean every tool must be exposed for every task.
OpenAI documents allowed_tools for limiting which MCP tools an Agents API agent can discover and call. Its Python Agents SDK also documents static allow/block lists and context-aware filters to control tool exposure. These are useful scope controls, but they should not be treated as a universal optimum for how many tools to expose or as a guaranteed security boundary. The execution environment still needs its own appropriate permissions and safeguards.
- Expose the tools relevant to the task rather than assuming a model should always see the entire catalog.
- Use allow-lists or filters when the integration supports them and a narrower set is appropriate.
- Keep tool descriptions and input requirements specific enough to distinguish operations.
- Enforce access and safety rules where calls execute; visibility controls alone do not establish what the execution environment can access.
Which runtime should manage the agent?
Runtime choice determines how much orchestration, state management, and execution wiring the platform handles versus how much the application owns. OpenAI’s documentation describes three options with different responsibilities. The comparison below summarizes those documented distinctions; exact capabilities can change as product APIs evolve.
| Integration | Orchestration | State and conversation history | What it suits |
|---|---|---|---|
| Agents API | Managed by OpenAI. | The documented approach includes saved session configuration and turns. | Teams that prefer a more managed agent flow and less application-owned orchestration. |
| Agents SDK | Runs within the application. | The application can use its own storage or SDK session mechanisms. | Teams that want SDK-supported orchestration while keeping the agent runtime within their application. |
| Responses API | The application works more directly with model responses and the integration. | The application manages history, response chaining, or Conversations. | Teams that want more direct control over interaction flow and state handling. |
Execution location is a separate decision from orchestration. Depending on the integration, tools may be hosted by a service, connected through a server, handled by application functions, or run in the application’s environment. Choose based on where the required capabilities and permissions belong, not just on which API produces a tool request.
Best Value
When does programmatic tool calling help?
In Anthropic’s documented programmatic tool-calling approach, Claude can call tools from code in an execution container. That can let a workflow compose several tool operations through code instead of requiring an individual model round trip for every operation. It is an option for multi-tool work, not a requirement for every agent.
The surfaced Anthropic documentation included performance and token figures for named agentic-search benchmarks, but did not provide a publication year in the available material. Those figures are therefore not quoted here as date-complete statistics. Evaluate this approach against the workflow, execution environment, and current product documentation rather than treating an unqualified benchmark figure as a general prediction.
What should developers verify before deployment?
Tool use puts a model’s request into an execution path, so review the whole path rather than just the prompt or tool schema.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- Tool scope: Confirm that only the appropriate tools are exposed or discoverable for the task.
- Execution permissions: Check what the application handler, hosted tool, or MCP server can access and change.
- Input handling: Validate arguments at the execution boundary; a structured request is still input from the model.
- Results and errors: Decide what information is returned to the model and how failed or incomplete calls are handled.
- State ownership: Identify where conversation history, session state, and tool results are stored and how they persist across turns.
- Current product behavior: Verify API labels, available tools, and configuration options in the relevant vendor documentation, since product surfaces and capabilities change.
Where can developers learn more?
For hands-on reading, Manning lists Micheal Lanham’s AI Agents in Action, Second Edition as a June 2026 print edition and describes coverage of connecting agents to MCP servers and building servers. O’Reilly lists Kyle Stratis’s AI Agents with MCP for print publication on November 3, 2026; as of October 9, 2026, that date is still in the future. These publisher details establish subject fit and listed publication timing, not current retailer stock, price, or availability.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
