LLM Tool: What It Means and How Tool Calling Works

An LLM tool is, most of the time, a function that a language model is allowed to ask for. You describe the function to the model with a name, a plain-English description, and a JSON schema for its inputs. The model reads the conversation, decides the function would help, and replies with a structured request to call it. The model never runs anything itself. Your application runs the function and sends the result back, and the model uses that result to write its answer.

That's the meaning behind "tool use" in Anthropic's docs and "function calling" in OpenAI's. The phrase has two other meanings, Simon Willison's llm command-line tool and developer software like local model runners, which are covered at the end.

Three meanings of "LLM tool" at a glance

What a tool actually is: name, description, schema

A tool definition has three parts that matter:

1. Name — a short identifier the model uses to refer to the tool, like get_order_status.
2. Description — plain text explaining what the tool does and when to use it. The model reads this to decide whether to call the tool.
3. Input schema — a JSON Schema object listing the arguments, their types, and which are required.

Here's an illustrative definition for a hypothetical order-lookup tool, in the shape Anthropic's API expects:

{
  "name": "get_order_status",
  "description": "Look up the current status of a customer order by its order ID. Use this when the user asks where an order is, whether it shipped, or when it will arrive. Returns the status, carrier, and estimated delivery date. Does not return payment details.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "The order ID, e.g. ORD-10482"
      }
    },
    "required": ["order_id"]
  }
}

The field names differ by provider, which trips people up when they port code:

Both providers let you set strict so the model's arguments match your schema exactly. Verify the details against OpenAI's function calling guide and Anthropic's docs before you ship, because these APIs change.

The loop: request, tool call, result, answer

OpenAI's guide breaks function calling into five steps, and Anthropic's flow is the same shape:

1. You send a request with the user's message and the list of tools.
2. The model replies with a tool call instead of (or alongside) text. On Anthropic's API the response carries stop_reason: "tool_use".
3. Your code runs the function with the arguments the model supplied. This is ordinary code: a database query, an HTTP request, a file read.
4. You send a second request containing the conversation so far plus the tool result.
5. The model answers, or asks for another tool.

Step 5 is where agents come from. If the model keeps asking for tools and your code keeps running them, you have a loop. That loop, with some reasoning between calls, is the pattern described in our explainer on ReAct agents, and it's what agent SDKs automate for you, as covered in what an agent API actually sells you.

You also control whether the model calls tools. Anthropic's tool_choice has four settings: auto lets the model decide, any requires some tool, tool forces one specific tool, and none blocks tools. Forcing a tool isn't supported on every model and setting, so check the docs for the model you use.

Client tools vs server tools

Not every tool runs in your code. Anthropic splits them by where execution happens:

• Client tools run in your application. That includes tools you define and tools where Anthropic publishes the schema, such as bash and the text editor tool. Your code still executes each call and returns the result.
• Server tools run on Anthropic's infrastructure. Its list includes web search, web fetch, tool search, and a code execution tool that runs Python and bash in a sandboxed container. You get results back without writing a handler.

OpenAI draws a similar line. Its built-in tools include web search, file search, and remote MCP servers, which run as part of the platform. Function calling is the separate path for your own code.

Server tools are quicker to add, but you don't control what happens inside them, and some carry usage-based charges on top of tokens.

MCP: packaging tools once for many apps

If you write a tool for one app, you define it in that app's code. If you want the same tool in Claude, ChatGPT, your editor, and your own agent, you'd redefine it four times.

The Model Context Protocol exists to remove that repetition. MCP describes itself as an open-source standard for connecting AI applications to external systems, and uses the analogy of a USB-C port. You wrap your tools in an MCP server once, and any MCP client can discover and call them. The MCP site lists Claude, ChatGPT, Visual Studio Code, and Cursor among the apps that support it.

Under the hood it's the same loop; MCP standardizes how tool definitions and calls travel. If you're choosing an app to plug servers into, see our guide to MCP clients.

How to write tool descriptions the model uses correctly

Anthropic's guide to defining tools calls detailed descriptions "by far the most important factor" in tool performance and suggests at least 3–4 sentences per tool. OpenAI's guide gives overlapping advice. Combined, it comes down to this:

• Say what it does, when to use it, and when not to. The order-lookup example above says it doesn't return payment details. That one sentence stops the model from calling it for a billing question.
• Describe every parameter and its format. "Order ID, e.g. ORD-10482" beats a bare string type.
• Use enums where values are fixed. If a unit can only be celsius or fahrenheit, say so in the schema instead of hoping.
• Consolidate related actions. Anthropic suggests grouping actions like create, review, and merge into one tool with an action parameter rather than three near-identical tools.
• Namespace names across services. github_list_prs and slack_send_message are harder to confuse than list and send.
• Don't make the model fill in what you already know. If your app knows the user's account ID, inject it in code. Don't ask the model to supply it.
• Return lean results. Send back the fields the model needs for its next step, not a full API response. Bloated results waste context.

What goes wrong with LLM tools

Most tool-calling failures are fixable in the definition or the surrounding code, not the prompt.

The last row deserves more attention than it usually gets. OWASP's entry on prompt injection calls this indirect injection: the model accepts input from an outside source, such as a website or file, and that content changes its behavior. A tool that fetches web pages is a direct pipe for it. OWASP's mitigations include least-privilege access, human-in-the-loop controls for privileged operations, and clearly separating untrusted content.

The practical rule: the tool's permissions are your real security boundary, not the prompt. A model that can only read orders can't be tricked into issuing refunds. The same failure modes apply to agents more broadly, which our piece on LLM agents covers.

The other two meanings: the llm CLI and LLM developer tools

Simon Willison's llm command-line tool

LLM is an open-source CLI tool and Python library for working with many models, including OpenAI, Claude, and Gemini, through remote APIs or with models running on your own machine. You type a prompt in your terminal and get a response back, and it can store your prompts and responses in SQLite so you can look back through them. Plugins add model providers, including local ones.

It also supports tool calling, so the two meanings overlap. Per the LLM tools documentation, every tool is a Python function. You enable one with -T (for example, the built-in llm_version and llm_time tools), pass your own functions with --functions, and add --td to print tool calls as they happen. The docs also warn plainly about prompt injection, describing the "lethal trifecta": private data, exposure to malicious instructions, and a way to send information out.

"LLM tools" as developer tooling

The loosest meaning covers the software people use around models. Two common examples are local runners:

• Ollama runs open models on your machine behind a local API, with an optional cloud path. Its API supports tool calling: you pass a tools list, the model returns tool_calls, and — as Ollama's tool calling docs show — your application runs the function and adds the result to the messages.
• LM Studio lets you download and run local models, serve them on OpenAI-like endpoints, and act as an MCP client, according to LM Studio's documentation. Its homepage now leads with Bionic, an agent app for work and code.

The same tool-definition ideas carry over: a local model with a good description and a tight schema behaves better than one without. If you're picking between the two runners, our LM Studio vs Ollama comparison covers how they've diverged.

If the part that stops you is getting someone's tool-using setup running on your own machine, Taku mirrors a working AI setup into a desktop workspace so you can run it without rebuilding the environment first. Taku is in Beta, and the Mac app is available now.

Key points

• "LLM tool" usually means tool use / function calling: a name, a description, and a JSON schema the model can ask your app to execute
• The model never executes anything. It returns a structured call; your code runs it and sends the result back
• Field names differ: Anthropic uses input_schema and tool_use / tool_result; OpenAI uses parameters and function_call / function_call_output
• Client tools run in your app; server tools run on the provider's infrastructure
• MCP packages tools once so many apps can use them
• Descriptions are the biggest lever on whether the right tool gets called with the right arguments
• Tool results can carry prompt injection, so limit what each tool is allowed to do

FAQ

What is a tool in an LLM?

A tool is a function you describe to a model so it can request it. The description includes a name, what the function does, and a JSON schema of its inputs. When the model decides the function would help, it returns a structured call with arguments, and your application runs it.

Is tool use the same as function calling?

Yes. Anthropic's docs say tool use is also called function calling, and OpenAI uses "function calling" for the same idea. The mechanics match; the field names and response formats differ between providers.

Does the LLM run the tool itself?

Not for tools you define. The model only produces the request, and your code executes it. The exception is server-side tools, such as Anthropic's web search and code execution tools, which the provider runs on its own infrastructure and returns results for.

How many tools can I give an LLM?

There's no single hard number that applies everywhere. OpenAI suggests aiming for fewer than 20 functions available at the start of a turn, as a soft guideline. With larger sets, both OpenAI and Anthropic offer tool search so the model loads only relevant tools on demand. Consolidating near-duplicate tools helps regardless.

What is the difference between an LLM tool and an MCP server?

A tool is a single function definition. An MCP server is a package that exposes one or more tools (and other resources) through a standard protocol, so any MCP-compatible app can use them without redefining each tool.

What is the llm CLI tool?

It's Simon Willison's open-source command-line program and Python library for prompting many models from your terminal, with plugins for more providers and local models. It supports tool calling through Python functions, and it can store your prompts and responses in SQLite.