Tool Integration
Tool integration is the engineering of connecting a language model to external functions and services, such as search, a database, a calculator, a code interpreter or a company API, so that it can fetch information and take actions that its own text generation cannot. The model does not execute anything itself: it emits a structured request naming a tool and its arguments, and surrounding software runs the call and feeds the result back.
Function calling is the basic mechanism, and the loop is simple. The developer describes each available tool with a name, a plain-language description and a JSON Schema for its parameters. Given a user request, the model either answers directly or returns a tool call, for example get_weather with city set to Lisbon. The application validates the arguments, runs the real function, appends the output to the conversation, and asks the model to continue, repeating until a final answer is produced. OpenAI introduced this as a dedicated API feature in June 2023, and other providers added comparable tool-use interfaces. The research roots include Toolformer by Schick et al. in 2023, which trained a model to decide when to call a calculator, search engine or translation tool, and ReAct by Yao et al. in 2022, which interleaved reasoning with tool actions.
The Model Context Protocol standardizes how tools are packaged and discovered. Anthropic introduced the Model Context Protocol, or MCP, in November 2024 as an open standard for connecting AI applications to external tools, data sources and prompts. Instead of each application writing custom glue for every service, a service exposes an MCP server that lists its tools and resources, and any MCP-compatible client can discover and call them over a common JSON-RPC based protocol. This reduces the integration work from every pairing of application and service to one implementation on each side, and the standard was adopted by a number of other vendors and tools after its release. It standardizes the connection, not the trustworthiness of what sits behind it.
Sandboxing and permissions are the central safety concern. A tool turns model text into real effects, and the model's input can include untrusted content, such as a web page or an email, that contains hidden instructions, the attack known as prompt injection. The defence is to treat every tool call as untrusted input: grant the least privilege needed, scope credentials to the user, run code execution in isolated containers or virtual machines without ambient secrets, restrict network access, set time and resource limits, and require human confirmation for irreversible actions such as payments, deletions or sending messages. Read-only tools are far safer than write tools, and combining private-data access, exposure to untrusted content and an outbound channel in one agent is a recognized high-risk pattern.
Errors and tool design decide whether agents work in practice. Models call tools with wrong arguments, pick the wrong tool or ignore results, and real services time out, rate-limit and return odd formats. Good integrations return structured, informative error messages the model can use to retry, keep results concise to avoid flooding the context window, make operations idempotent where possible so a retried call does no harm, and log every call for audit. Tool descriptions are effectively prompts, so vague names and overlapping tools confuse selection, and offering dozens of tools at once degrades accuracy. A common misconception is that the model is running the code; the reliability of the system rests on the host application's validation and control.
Read tool integration as giving a text predictor hands under supervision: the model proposes a structured action, and the quality of the schemas, the sandbox, the permissions and the error handling determines whether that capability is useful or dangerous.