#tool-use-mcp

Tool error handling and retries are the ways an AI agent responds when a tool call fails, by classifying the failure, deciding whether it is safe to try again, and then either retrying with a better request or stopping and surfacing the error. Tools fail for ordinary reasons: network timeouts, rate limits, malformed inputs, missing permissions, empty results, or temporary backend outages. If an agent treats every failure the same, it either gives up too early or blindly repeats a bad request. Go

A code execution tool, or sandbox, is a controlled runtime that lets an AI agent run code safely without giving it full access to your systems. LLMs are good at writing code, but they cannot reliably verify code by thought alone. A sandbox lets an agent: run generated code check outputs inspect errors iterate on fixes You’d reach for it when the task needs computation, file manipulation, data transformation, or testing. In practice, teams use sandboxes when “just answer in text” is too britt

A computer-use or browser-use tool is a capability that lets an AI agent operate software directly—usually a web browser, and sometimes the broader desktop—by clicking, typing, scrolling, and reading the visible screen instead of calling an API. Not every task has a clean API. Many real workflows still live in web apps: logging into dashboards, filling forms, checking inventories, downloading reports, or copying data between systems. A browser-use tool helps an LLM or agent handle those tasks by

A tool result or tool message is the message an app sends back to the model after the model asks it to use an external tool, such as a search API, calculator, database query, or function call. LLMs do not reliably know fresh data, private data, or exact computations on their own. A tool result lets the system return the tool’s output to the model in a structured way so the model can continue the conversation with real evidence. You’d use it whenever the model needs to: fetch data from an

Parallel tool calling is when an LLM asks for multiple tools to be run in the same turn, so independent actions can happen at the same time instead of one after another. Use parallel tool calling when the model needs several unrelated results, such as fetching weather for three cities, looking up multiple records, or calling a search API and a calculator in the same step. It matters because it can reduce latency and keep agent flows simpler: rather than forcing the model to serialize independent

A JSON schema for tool arguments is a machine-readable description of what inputs a tool expects, including the names, types, and constraints of its parameters. When an LLM calls a tool, it needs a reliable way to format the arguments so the tool can actually run. A JSON schema helps by telling the model and the application: which fields are required what type each field should be whether values must match a pattern, range, or enum how to validate the request before executing the tool In practic

A tool schema or tool definition is a machine-readable description of a function, API, or action an LLM can call, including its name, what it does, and the inputs it accepts. Tool schemas let you connect a model to real capabilities without letting it invent the interface. In practice, they solve three common problems: Structured calling: the model can ask for a function call instead of writing brittle free-form text. Validation: the runtime can check that the model supplied the

Function calling, also called tool calling or structured tool use, is a way for an AI model to ask your app to run a specific function with specific arguments instead of guessing the answer itself. Large language models are good at language, but they are not reliable sources of fresh facts, private data, or side effects like “send the email” or “look up today’s weather.” Function calling solves that by letting the model produce a structured request that your code can execute. You reach f

The Model Context Protocol (MCP) is an open standard that lets AI apps connect to external tools, data sources, and workflows through a common interface, usually via an MCP client talking to an MCP server. Without a shared protocol, every AI app tends to build one-off integrations for files, databases, APIs, and internal tools. MCP solves that by giving model-powered applications a standard way to discover and use capabilities from different systems. In practice, you reach for MCP when y

An MCP server is a service that exposes tools, data, or actions to an AI client using the Model Context Protocol, so an LLM-powered app can safely discover and call external capabilities in a standard way. Without a standard protocol, every AI app ends up integrating with files, databases, APIs, and internal tools in its own custom way. That makes integrations harder to build, harder to reuse, and harder to govern. An MCP server solves that by giving AI clients a common interface for: discoverin

An MCP client is the software that connects an app or agent to an MCP server so it can discover and use external tools, resources, or prompts through the Model Context Protocol. If you want an LLM app to safely call APIs, read files, query data, or use other external capabilities in a standardized way, you need something on the client side to speak MCP. In practice, the MCP client is the piece that: opens and manages the connection to one or more MCP servers, asks what capabilities those servers

An MCP transport is the way a Model Context Protocol client and server exchange messages, most commonly either over standard input/output (`stdio`) or over HTTP-based connections. MCP defines *what* messages are sent; the transport defines *how* they move between processes or over a network. You choose a transport based on deployment shape: `stdio` is the usual choice for a local, single-user tool or desktop app starting a server as a child process. HTTP is the usual choice when the MCP

An MCP resource is a piece of data that a server exposes to a model or client through the Model Context Protocol, usually as a named, readable thing like a file, document, or other context object. Resources are how MCP lets an assistant work with context that already exists somewhere else without copying it into the prompt by hand. In practice, they are useful when you want an LLM app to inspect docs, logs, configs, or other stored information in a structured way. You’d reach for resourc

An MCP prompt is a prompt template or prompt resource exposed through the Model Context Protocol so an app or agent can fetch and use a standardized prompt from a server instead of hard-coding it. MCP is designed to let tools, models, and clients work together through a common protocol. Prompts are one part of that: they let a server publish reusable instructions, examples, or task templates that a client can retrieve dynamically. You’d use an MCP prompt when you want: a consistent prompt across

Tool choice (often exposed as `tool_choice`) is the setting that tells an LLM whether it may decide on its own to call a tool, must call a tool, or must not call any tool. Tool choice lets you control how an assistant interacts with external capabilities like search, databases, calculators, or internal APIs. You reach for it when you want to: let the model answer directly unless a tool is clearly needed, force a tool call for workflows that must use fresh or trusted data, or prevent tool use

A tool call ID is a unique identifier attached to one specific tool invocation so the model and your application can refer to that exact call again later. Tool calls are often part of a multi-step exchange: the model asks for a function or external service to run, your app executes it, and then you send the result back. The tool call ID is what keeps that round-trip unambiguous. You reach for it when: a model makes more than one tool call in the same turn you need to match each tool result to th

A tool registry is a catalog that lists the tools an AI agent or application can use, along with the metadata needed to call them correctly. When you build an agent that can search, fetch data, send messages, or run internal workflows, the model needs more than just a tool name. It needs to know: what each tool does, what inputs it expects, how to call it safely, and often which tools are available in the current context. A tool registry solves that discovery problem. Instead of hard-coding