Local Function Tools for Your First AI Agent

Updated 9 November 2026 · Standard formula, shown below

For a first AI agent, choose one small, deterministic local function that solves a task you can verify—such as adding numbers, converting units, or formatting a date. Keep it read-only, give it a clear input and output, and make the agent call it only when needed; this is a safer, easier starting point than granting access to files, a terminal, or external services.

What a local function tool does

An agent is a program that uses a language model to decide what to do next, often by selecting from tools made available to it. A local function tool is a function your application runs on the same machine or within the same application environment as the agent. The model generally does not execute that function itself: it requests a tool call with arguments, and the surrounding program validates the request, runs the function, then returns the result.

For example, an agent asked to split a restaurant bill might call a local function that accepts a total and a number of people, then returns the amount per person. The function handles arithmetic; the model handles the conversation and decides whether the tool is relevant. That division matters: deterministic calculations are better delegated to ordinary code than left to a model’s generated text.

Why start with a small, pure function

A useful first tool is usually a pure function: given the same valid inputs, it returns the same output without changing files, sending messages, or relying on hidden state. This makes it easy to test and limits the consequences of a mistaken call.

Unit conversion: convert a stated number of kilometres to miles, with the conversion factor documented in code.
Arithmetic: calculate a subtotal, average, or percentage from values explicitly supplied by the user.
Text formatting: normalize a date string or turn a list of names into a consistent format, while reporting invalid input rather than guessing.

Pick a function that is useful enough to demonstrate tool use, but narrow enough that its expected behavior fits in a few sentences. Avoid an all-purpose “do anything” function as your first tool. A narrow interface gives the model fewer ways to misunderstand what it can do and gives you clearer tests.

How to define the tool

Most agent frameworks represent a function tool with a name, a description, and a schema describing its inputs. The precise syntax varies by framework, but the design questions are much the same:

Name it by its action. Names such as convert_kilometres_to_miles are more informative than helper.
Describe when to use it. Say what it computes and what it does not do. For instance, clarify whether it accepts only a numeric distance or also interprets natural-language units.
Specify each argument. Include its type, unit, and any constraints. Distinguish a whole-number count from a decimal measurement.
Validate in the program. A schema can help guide a model, but your code should still reject missing, malformed, non-finite, or out-of-range values where appropriate.
Return a compact, predictable result. A structured result with a value and unit is easier for the agent to explain accurately than an ambiguous string.

For a conversion function, returning both value and unit helps prevent a model from presenting a number without its meaning. State rounding behavior explicitly. Keep full precision internally when useful, and round for display rather than silently changing the calculation.

Test the tool before involving the agent

Test the function as ordinary software first. Check a typical input, a boundary case, and invalid inputs. For a distance conversion, test zero, a familiar positive distance, a negative value if negatives are disallowed, and text where a number is expected. Confirm that the result has the intended unit and precision.

Then test the tool through the agent. Try prompts that should trigger it, prompts that should not, and ambiguous prompts where the agent ought to ask a question. If the user says “convert 5,” the tool should not have to guess whether that means kilometres, miles, or something else. The agent should request the missing unit or context before calling it.

Log the tool name, validated arguments, and whether execution succeeded, while avoiding unnecessary sensitive data. Clear logs make it easier to find a schema mismatch or a bad tool-selection decision. They also help separate two different failure types: the model may choose the wrong tool, or the function may behave incorrectly after being called.

Safety and common first-tool mistakes

“Local” describes where execution happens; it does not automatically make a tool safe. A local function can still overwrite data, expose private information, or run dangerous commands if it has those capabilities. Start with no side effects and grant only the permissions the task actually needs.

Do not pass arbitrary model text to a shell or evaluator. A calculator should parse a restricted numeric input or use explicit arithmetic code, not execute generated code.
Do not trust arguments just because a schema exists. Validate them in the function before using them.
Keep tool output factual and bounded. Return only the result needed for the task; do not let an error dump private paths or unrelated data.
Make failures explicit. Return a controlled error for invalid input instead of a plausible-looking default that could mislead the agent.
Require confirmation before consequential actions. If a later tool sends, deletes, purchases, or changes something, separate preparation from execution and ask for appropriate user confirmation.

A common misconception is that putting a function on the computer makes it inherently more private or reliable. A local tool avoids a network request for that function only if its implementation and surrounding system do not send the data elsewhere. Reliability still depends on validation, tests, dependencies, and how the agent uses the result.

When to add more capability

Once the first tool works, add another only to meet a clear need. A sensible progression is from pure calculations to read-only access to a limited local dataset, then—if the use case genuinely requires it—to controlled actions with explicit permissions and confirmation. Each step increases the number of possible failure modes.

For example, an agent that summarizes a personal reading list might first use a function to sort a list already provided in the prompt. Reading a local file adds questions about file paths and access permissions. Editing the file adds the risk of unintended changes. These are separate capabilities; they should not be bundled into one broad tool simply for convenience.

Keep the tool interface stable where possible, document changes, and maintain tests for existing behavior. If the agent repeatedly misuses a tool, improve the name, description, or input schema before adding more tools. A clear contract often solves the problem more effectively than a longer instruction telling the model to be careful.

Frequently Asked Questions

What is the best first tool for an AI agent?
There is no universal best choice. A small, deterministic function such as unit conversion or arithmetic is a practical starting point because it has clear inputs, outputs, and tests.

Does a local tool run inside the AI model?
Usually not. The model proposes a call; the application or agent framework runs the function and sends the result back to the model.

Can a local function tool work without internet?
Often, if the agent model and its dependencies are also available locally. A local function by itself does not guarantee that the entire agent operates offline.

Should my first tool be able to read or change files?
Usually not. Start with a function that has no side effects. Add carefully scoped file access only when the task requires it, and test permissions and error handling.

Why did the agent fail to call my function?
It may not have recognized the tool as relevant, or its requested arguments may not match the schema. Check the tool description, input requirements, and call logs, then test with a direct, unambiguous prompt.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.