# Tool

An AI tool is a named, bounded function a model can request to read outside information, perform a calculation, or take an action through another system.

Source: https://rodamora.com/glossary/tool
Updated: 2026-08-09

---

An AI tool is a named, bounded function that a model can request to read information, perform a calculation, or take an action through another system. It may look up a client record, calculate a fee, create a task, or send a message. For a custom tool, the model sends a function name and structured arguments. The application decides whether it runs and returns the result. OpenAI's [function-calling guidance](https://developers.openai.com/api/docs/guides/function-calling) says strict mode can make those arguments match a supported JSON Schema. That shows the request has the expected shape. It does not show that the action was allowed or that the right client record changed. NIST's August 2025 work with about 140 experts classifies tools by access, reversibility, monitoring, and autonomy. The operator defines the tool's capability, identity, limit, proof, and recovery plan.

## 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 a schema for the allowed inputs. The model can produce a structured request such as `get_project_status` with a project ID. The application checks the request, runs the underlying code, and sends the result back. The model uses that result to answer or choose another step.

The [Model Context Protocol specification](https://modelcontextprotocol.io/specification/draft/server/tools) 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 this same loop. The tool is the capability. The tool 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.

| Term | What it provides | Service-firm example |
| --- | --- | --- |
| Tool | One capability an AI can request | Read the current project status |
| API | A software interface beneath many tools | The project system's endpoint for tasks and accounts |
| Skill | Reusable instructions for performing work | How to review a weekly client report |
| MCP | A shared way to expose tools and resources to compatible AI applications | Make approved project lookups available to several assistants |
| Computer use | Screen, keyboard, and mouse access | Read a legacy client portal with no usable API |
| AI agent | Software that chooses among tools while pursuing a goal | Inspect an account and choose 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](https://rodamora.com/glossary/model-context-protocol) can expose that tool to several compatible applications. It does not decide the business permission or completion rule.

An AI [skill](https://rodamora.com/glossary/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](https://rodamora.com/glossary/computer-use) reaches software through the screen. A typed tool reaches a named capability directly and is easier to limit and test. Computer use remains useful for old portals and desktop software with no usable interface.

## Why is an AI tool an authority boundary?

Every tool answers a permission question. Reading a rate card, changing a rate, sending a proposal, and deleting a proposal are four different authorities. Calling all four “CRM access” hides the decisions the firm needs to make.

NIST's [tool-use taxonomy](https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems) 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 the security failure [excessive agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/). It names three root causes: excessive functionality, excessive permissions, and excessive autonomy. An email summarizer that can also send and delete messages has more functions than its job needs. A product lookup using a database identity with update and delete rights has more permission than it needs. A deletion tool that runs without approval has more autonomy than the consequence allows.

Put the control in the system that runs the tool. OWASP says the downstream system should validate requests against policy instead of relying on the model to decide whether an action is allowed. A prompt that says “never delete a record” is guidance. A database identity with no delete permission is a boundary.

## 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.

Consider a project-health assistant. Its first tool might read the latest task dates for one account and return the source record IDs. It cannot edit the account or contact the client. After that lookup works across missing records, similar client names, and denied access, a second tool can create a reversible internal task. Sending a client message comes later and keeps a person at the approval point.

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. It can time out after the write, retry, and create a duplicate. It can receive an empty but valid response, let the agent assume there was no project risk, and finish without an error. The final message may still say the job is done.

Check the state that matters to the firm. The correct account changed. The source record is attached. The task owner and due date are right. A client message appears in the approved sent channel. A repeated [eval](https://rodamora.com/glossary/eval) can score those outcomes against written cases.

A [guardrail](https://rodamora.com/glossary/guardrail) handles the other side of the boundary. It blocks a forbidden call before execution. The eval measures whether allowed work ended correctly. Logs help explain a failure after the fact. They do not replace either control.

## 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](https://rodamora.com/blog/delegate-the-inputs-own-the-outputs). 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](https://rodamora.com/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 that person faster. The person still holds 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.

The home for this capability is [an AI employee](https://rodamora.com/blog/what-is-an-ai-employee). Ongoing access to the systems where delivery lives is one of the four elements the firm supplies to that role. The tool provides access. The firm still supplies the job, trigger, validation, and operating boundary.

## When should a service firm 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](https://rodamora.com/glossary/ai-workflow) when the path can be written in advance. Use an [AI agent](https://rodamora.com/glossary/ai-agent) when the next action depends on what the system finds and the firm can still test, stop, and recover the work.

For a first tool, define one read-only capability with its identity, limit, proof, and recovery owner. Test a clean result, a missing record, two similar clients, denied access, a timeout, and a partial response. Add one reversible write after the lookup leaves the right evidence in the right business record.