Tool

An AI tool is a named function with set limits that a model can request to read information, calculate something, or act through another system. It might look up a client record, calculate a fee, create a task, or send a message.

For a custom tool, the model sends the function name and inputs in a structured request, and the application decides whether to run it and return the result. OpenAI’s function-calling guidance says strict mode can require those inputs to match a supported JSON Schema, the rules for what the request must contain.

But a request with the right format can still change the wrong client’s record. Your firm has to define what the tool can do, whose account it uses, what its limits are, how you’ll check completion, and who handles a failure.

NIST’s August 2025 work with about 140 experts looks at tools along those lines, including access, whether actions can be undone, how calls are monitored, and how much the agent can do on its own.

What does an AI tool do?

A tool lets a model request one outside capability. It may read information, perform a calculation, or change another system.

The application gives the model a tool name, a description of when to use it, and rules for the allowed inputs. The model can then request something like get_project_status with a project ID.

The application checks that request, runs the code, and sends the result back, which the model can use to answer or choose another step.

The Model Context Protocol specification uses the same shape. Each tool has a unique name and schema metadata. A compatible client can discover the available set and let the model request one for the current job.

Tool calling and function calling usually name that same back-and-forth, the tool is what the system can do and the call is the model’s request to use it.

The application still owns authentication, permission checks, approval, execution, and the record of what happened. A valid project ID can still name the wrong client’s project.

What is the difference between a tool, an API, a skill, MCP, and computer use?

These terms describe different layers of one job.

A tool offers one thing the AI can request, such as reading the current project status. An API is the software interface underneath many tools, such as the way your project system lets other software access tasks and accounts.

A skill carries reusable instructions, such as how to review a weekly client report. MCP gives compatible AI applications a shared way to find tools and resources, so several assistants can use the same approved project lookups.

Computer use gives AI screen, keyboard, and mouse access, useful for an old client portal with no usable API. An AI agent chooses among tools while working toward a goal, such as inspecting an account and choosing the next allowed action.

An API can exist without AI. A tool can wrap one narrow API operation and describe it in terms the model can select. Model Context Protocol can expose that tool to several compatible applications. It does not decide the business permission or completion rule.

An AI skill tells the system how to do a kind of work. A tool gives it a way to read or act. The instructions may say how to review a proposal. The tools may fetch the approved transcript, read the rate card, and save the completed review.

Computer-use AI reaches software through the screen, while a tool with defined input types requests a named function directly, making it easier to limit and test. Computer use remains useful for old portals and desktop software with no usable interface for that direct connection.

Why is an AI tool an authority boundary?

Every tool brings a permission decision with it. Reading a rate card, changing a rate, sending a proposal, and deleting a proposal need four different permissions, so calling all of them “CRM access” hides choices your firm still has to make.

NIST’s tool-use taxonomy separates read-only access, constrained writes, and writes. It also asks whether an action is reversible, whether the environment is trusted, how the call can be observed, and how much initiative the agent has. A browser reading the open internet and a project lookup over approved internal records may both retrieve information. Their source risks differ.

OWASP calls this security failure excessive agency and names three causes, too many functions, too much permission, and too much freedom to act. An email summarizer that can also send and delete messages has more functions than its job needs.

A product lookup using a database account that can update and delete records has more permission than it needs. And a deletion tool that runs without approval has more freedom than the consequence allows.

Put the control in the system that runs the tool. OWASP says that system should check requests against policy rather than relying on the model to decide what’s allowed, so “never delete a record” in a prompt shouldn’t replace a database account with no delete permission.

What should every production tool define?

Write five fields before giving a tool real work:

1. Capability. Name the exact job, its inputs, and its result. get_project_status is clearer than use_crm.
2. Identity. State whose authority the call uses. A tool should not inherit an owner’s broad account because it was easiest to connect.
3. Limit. Define which clients, records, actions, rates, and destinations it can reach. Put approval before calls that exceed the automatic limit.
4. Proof. Name the business record that shows completion. Preserve the tool request and raw result, then check the CRM, task system, sent folder, or ledger where the work must exist.
5. Recovery. Decide what happens after a denial, timeout, partial write, duplicate call, or wrong result. Name the person who receives the stopped run.

For a project-health assistant, the first tool might read the latest task dates for one account and return the source record IDs, without being able to edit the account or contact the client. Once that lookup handles missing records, similar client names, and denied access, you can add a second tool that creates an internal task you can undo.

Sending a client message comes later, with a person approving it before it goes out.

This sequence avoids discovering in production that the same credential could read every client, change every record, and send as the owner.

How do you know the tool completed the job?

A request that matches the schema proves that the arguments fit the declared shape. A 200 response proves that the service accepted the call. The firm still has to prove that the right job finished.

A tool can create a task under the wrong client and return success, or time out after making the change, retry, and create a duplicate. It can also return an empty but valid response that the agent reads as no project risk, so the final message says the job is done even though the work is wrong.

Check what actually happened in the business system, whether the correct account changed, the source record is attached, the task owner and due date are right, and the client message appears in the approved sent channel. A repeatable eval can test those results against written cases.

A guardrail blocks a forbidden call before it runs, while the eval checks whether allowed work finished correctly. Logs help explain a failure afterward, but they don’t replace either check.

How much access should an AI tool have?

Start with the smallest read-only capability that can complete one useful job. Give it a separate identity, restrict the data scope, and record every call. Add one reversible write only after the read path passes representative cases.

OWASP recommends exposing only the minimum functions, avoiding open-ended tools when a narrow one will work, and enforcing minimum permissions in the connected system. It calls for human approval on high-impact actions. The MCP specification also recommends showing exposed and invoked tools, with a denial path for the user.

Keep approval before money moves, access changes, a record disappears, scope changes, or the firm makes a promise to a client. A better model can choose the right action more often. It cannot make an irreversible action cheap to undo.

That is the same autonomy test as checking the result and undoing the action. Low-consequence reads can run freely after testing. A client-facing write may still need approval even when the model usually gets it right.

Where does a tool sit on the Delivery Model Ladder?

A tool can appear at any stage. The workflow around it determines the stage on the Delivery Model Ladder.

At Stage 1, Enhanced, a person asks an assistant to run a lookup, checks the answer, and carries it into the next system. The tool makes them faster, but they still hold the process together.

At Stage 2, Augmented, a trigger starts a bounded workflow. The tool uses a scoped identity, the result is checked against the business record, and a failed call reaches a named owner. The capability has become part of delivery.

Stage 3, AI-native, requires the firm to maintain tool definitions, permissions, checks, and recovery as shared delivery infrastructure. Adding more tools does not move the firm up the Ladder. A broad connection with no owner can leave a sophisticated agent at Stage 1.

This is how tools fit inside an AI employee, where ongoing access to delivery systems is one of the four elements the firm supplies. The tool gives it access, while your firm still defines the job, what starts it, how to check the result, and what it’s allowed to do.

When should a business skip the tool?

Skip a new integration when the task is rare, cheap, and safe to complete with an ordinary file or manual action. A twelve-person firm does not need a maintained connector for a lookup someone performs twice a year.

Use fixed software or an AI workflow when the path can be written in advance. Use an AI agent when the next action depends on what the system finds and the firm can still test, stop, and recover the work.

For your first tool, define one read-only function, whose account it uses, what it can reach, what proves it worked, and who handles a failure. Test a clean result, a missing record, two similar clients, denied access, a timeout, and a partial response.

Add one change you can undo after the lookup consistently leaves the right evidence in the right business record.