Skip to content

Topic 10 · Agents

Tool calling & protocols

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

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.

In this topic

28

terms, each defined below

Jump to the interactive figure

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.

step 1 / 8

UserApp / harnessModelTool
question

1 · The user asks

"How many models in the atlas use MLA?"

Glossary

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

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

Search the atlas

Jump to a model, concept or page