Tools

Tools connect a model to files and commands, plus browsers and external services. Each tool needs a defined input and a result the agent can interpret, plus a clear boundary around its effects.

How Function Calling Works

Model providers call this mechanism function calling or LLM tool calling. The application describes each tool to the model with a name and an input schema. The model never runs anything itself. It returns a structured request that names a tool and supplies arguments. The application validates that request and runs the tool, then sends the result back as new context.

That split decides where control lives. The model chooses which tool to request. The application decides whether the request runs at all, so permission checks and input validation belong on its side of the line. In the control panel the model might ask to save a pipeline with a name and two steps. The application checks those steps before it writes anything.

Use Narrow Operations

A save-pipeline operation can accept a name and an ordered list of steps, then validate them and return a pipeline identifier. A general shell tool can perform many more actions. Prefer the narrow operation when the task has a stable interface you can check directly.

Validate inputs in application code. An instruction asking the model for valid JSON does not replace schema validation. Reject missing fields and unknown step types before starting work, along with any value outside the supported range.

Every Tool Costs Context

Tool descriptions sit in the context on every call. A long list of AI agent tools takes space and attention away from the task before work begins. Similar tools add a second problem. Two tools with overlapping names and jobs can lead the model to pick the wrong one.

Give each task only the tools it needs. A research role can work with search and read access alone. An MCP server can add dozens of tools at once, so connect the servers a task uses and leave the rest off. Some applications load a skill's full instructions only when someone invokes it, which keeps rarely used capabilities out of the context until they matter.

Return Useful Evidence

A tool result should distinguish success from failure, and mark an unknown outcome as its own case. Include identifiers and concise error details. If a request times out after creating a run, retrying without checking the run identifier can create duplicate work.

Save the full artifact for large outputs and return a summary with its location. The next step can retrieve the relevant portion without carrying an entire log through every model call.

Script The Fixed Steps

Some steps give the same correct result on every run. Fetching a transcript and counting words both fit that description. Write a script for each one and expose it as a tool. The model then calls the script instead of redoing the work in generated text.

Scripts save tokens and remove a source of variation. The model keeps the parts that need judgment while the script handles the parts that need consistency. A skill can package instructions that say when to act together with scripts that do the fixed work.

Connect Services Deliberately

Model Context Protocol (MCP) is one way to expose tools and resources to compatible agent applications. A shared protocol makes integrations easier to connect; it does not establish the accuracy of returned content or grant permission for every available action.

Repository text and web pages can contain instructions unrelated to the task, as can tool output. Treat that material as data. Tool permissions and checks must remain effective even when retrieved content asks the agent to ignore them.

September, 2026