# 10. Tool calling & protocols

> How a model asks for something to be done, and how the answer gets back.

Track: Agents. 28 terms.

A model cannot run code or open a web page. What it can do is emit a structured request: the name of a tool and some JSON arguments. The application validates that request, runs the tool, and feeds the result back as a new message so the model can continue.

Under the hood that request is ordinary tokens, wrapped in special tokens the model learned in training and laid out by a chat template. On top sit protocols such as MCP, for connecting tools, and AG-UI, for streaming agent activity to a user interface.

**Interactive figure on the web page: Anatomy of a tool call.** One full round trip between the user, the application, the model and a tool. Step through to see the actual messages at each stage: the tool definition the model is given, the call it emits, the tool result, and the final answer.

## Terms

### Function calling

A model's ability to output a structured request to run a named function with arguments, instead of plain text.

### Tool definitions

Declarations of the tools the model may use, passed with the request: name, description and parameter schema.

### Tool schemas

The JSON Schema for a tool's parameters: types, required fields, allowed values and field descriptions. Good schemas prevent bad calls.

### Tool descriptions

Plain-language text saying what a tool does and when to use it. The model chooses tools mostly from these.

### Function arguments

The values the model fills in for a tool's parameters, emitted as JSON.

### Tool-call tokens

Special tokens a model is trained to put around tool calls, which the engine uses to detect and parse them.

### Special tokens

Reserved vocabulary entries with structural meaning, such as begin and end of text, role markers and tool-call markers. Ordinary text never produces them.

### Control tokens

Special tokens that steer format or behaviour: role switches, turning a thinking mode on or off, end of turn.

### Message boundary tokens

Tokens marking where each message starts and ends, such as <|im_start|> and <|im_end|> in ChatML-style templates.

### Tool routing tokens

Tokens or markers that say which tool or output channel the following content belongs to, so the parser can route it.

### Chat templates

The model-specific recipe, often a Jinja template shipped with the tokenizer, that turns a list of messages and tools into the exact token sequence the model was trained on. A mismatched template quietly degrades quality.

### Structured model outputs

Responses guaranteed to match a schema, through constrained decoding or through validation and retry.

See: [related](https://llm-atlas-7or.pages.dev/learn/decoding/#structured-generation)

### JSON Schema

A standard vocabulary for describing the shape of JSON data. It is the common language for tool parameters and structured outputs.

### JSON parsing

Turning the model's emitted text into data. Robust harnesses cope with partial streams, trailing text and malformed JSON.

### Argument validation

Checking parsed arguments against the schema and business rules before running the tool, and returning a useful error to the model when they fail.

### Tool authorization

Deciding whether this agent, acting for this user, may call this tool with these arguments right now.

### Tool permissions

The policy of which tools and scopes an agent has been granted, ideally the least it needs.

### Tool execution

Running the tool's implementation, ideally in a sandbox with timeouts and resource limits.

### Tool-call errors

Failures from bad arguments, missing tools, timeouts or exceptions. Reporting them clearly lets the model correct itself on the next step.

### Hallucinated tools

The model calling a tool that does not exist or inventing parameters. Validation catches it; clear definitions and constrained decoding make it rarer.

### OpenAI-compatible API

The de facto HTTP interface, /v1/chat/completions with messages, tools and tool_calls, that most inference servers and gateways implement so clients can switch providers.

### AG-UI protocol

The Agent-User Interaction protocol: an open, event-based standard started by CopilotKit for streaming agent events, such as messages, tool calls and state changes, to front-end apps.

### Model Context Protocol (MCP)

An open protocol, introduced by Anthropic, for connecting models to tools and data. MCP servers expose tools, resources and prompts over a standard JSON-RPC interface that any client can use.

### Agent-to-application communication

How an agent talks to the app around it: streamed tokens, tool-call events, state updates and requests for user input.

### Agent-to-tool communication

How an agent reaches its tools: direct function calls, HTTP APIs or protocols such as MCP.

### Tool-call finish reasons

The field in a response that says why generation stopped, such as "tool_calls" (run the tools and call me back), "stop" or "length".

### Forced tool selection

Requiring the model to call a particular tool, or any tool, on this turn through the tool_choice setting.

### Tool choice

The API parameter that controls tool use: auto (the model decides), none, required, or one specific named tool.

Web page: https://llm-atlas-7or.pages.dev/learn/tool-calling/

_Definitions written for LLM Atlas._