Tool calling definition
Tool calling is the mechanism that lets a language model use software it cannot run itself. The application gives the model machine-readable descriptions of the functions it may use, and when the model judges one is needed it returns a structured request naming the tool and its arguments. Something else executes that request and returns the result to the model.
Tool calling is how an AI model reaches outside itself: instead of answering in prose, it emits a structured request naming a tool and its arguments, which the application executes and feeds back. The model never runs anything. In Sanity, a Context MCP endpoint serves an agent tools derived from how the endpoint is configured, so in GROQ mode the agent gets `groq_query` and `schema_explorer` and queries the dataset at request time rather than reading a stale index.
Tool calling works as a round trip between the application and the model, and OpenAI's function calling guide states it as five steps. First, the application makes a request to the model along with descriptions of tools it could call. Second, the model returns a tool call, a structured request naming one tool and the arguments for it. Third, the application executes code on its own side using the input from that tool call. Fourth, the application makes a second request to the model carrying the tool output. Fifth, the model returns a final response, or more tool calls if the task needs them.
The load-bearing detail is that the model does not execute anything at any point in that loop. It produces a request; code somewhere else runs it. Anthropic draws the same line, describing how a model "returns a structured call that your application executes (client tools) or that Anthropic executes (server tools)" in its tool use overview. Client tools run in your infrastructure and your code replies with a tool result. Server tools such as web search or code execution run on the provider's side and you simply see the results.
The vocabulary is worth getting right because it appears in every API. A tool is a piece of functionality the application tells the model it has. A tool call is the model's request to use one. A tool call output is what the tool returned, sent back with a reference to the specific call it answers.
Tool calling and function calling are the same mechanism under two vendor names, and both vendors say so. OpenAI's documentation opens with "Function calling (also known as tool calling)," and Anthropic's opens with "Tool use (also called function calling)." If you see the two terms in different blog posts or SDKs, you are not looking at two different capabilities.
There is one narrow technical distinction, and it is worth stating precisely because it is the only real version of it. In OpenAI's terminology, a function is a specific kind of tool: one defined by a JSON schema. That sits alongside custom tools, which take free-form text as input and output, and built-in platform tools such as web search, code execution, and access to MCP servers. So "tool" is the broad category and "function" is the schema-defined case within it.
OpenAI introduced function calling on June 13, 2023, with the `gpt-4-0613` and `gpt-3.5-turbo-0613` models, announced alongside other API updates. The naming drift toward "tool" followed as providers added capabilities that were not plain schema-defined functions.
No. Tool calling and MCP (Model Context Protocol) sit at different layers and are constantly conflated. Tool calling is the model-side mechanic: given tool descriptions, the model emits a structured call. MCP is a protocol for how tools are described, discovered, and invoked across clients and servers, so the same tool works in different AI clients without bespoke wiring for each one.
MCP does not replace tool calling. An MCP server supplies the tool definitions, and the model still tool-calls against them exactly as it would against tools defined inline in your own code. Anthropic announced and open-sourced MCP on November 25, 2024, with the first specification version dated 2024-11-05, and has since announced donating the protocol to the Linux Foundation's Agentic AI Foundation.
The practical consequence is that MCP is where tool *providers* live. If your content, your database, or your ticketing system needs to be callable by an agent, you publish an MCP server and the tool-calling machinery in whichever client the user prefers picks it up.
Tool calling is one step; an agent is the loop around it. The agent pattern is: call the model, execute any tool call it emits, feed the result back, and repeat until the model stops or a limit trips. OpenAI's guide describes the application continuing this flow for as many tool calls as the task requires, and points to its Agents SDK as the framework that packages that orchestration. A single tool call is not an agent, though nearly every agent is built out of them.
Tool calling also differs from classic retrieval-augmented generation (RAG) in who decides to retrieve. In classic RAG the application decides, runs the search, and pastes passages into the prompt before the model ever sees the question. With tool calling, the model decides whether to retrieve and what query to use, so retrieval becomes one tool among several rather than a fixed preprocessing step. The two coexist happily in the same system.
Finally, tool calling is not structured output or JSON mode. Both produce machine-readable JSON, but structured output constrains the shape of the model's answer, while a tool call is a request for an action that something else performs, with the conversation expected to continue once the result arrives.
Tool calling fails because the decision to call a tool belongs to the model, which is the whole feature and the whole failure surface. A normal API integration fires when your code says so. A tool call fires when the model judges it is needed, which means the model can pick the wrong tool, call nothing when it should have called something, or invent an argument. Anthropic documents that last case directly: when a required parameter is missing from the user's prompt, a model "might infer a reasonable value" rather than asking for it, naming Claude Sonnet specifically in its tool use overview.
Because the failure modes are behavioral rather than syntactic, evaluation focuses on judgment. The Berkeley Function-Calling Leaderboard from UC Berkeley's Sky Computing Lab tests roughly 2,000 question-function-answer pairs made up of 1,680 Python, 100 Java, 100 SQL, 70 REST API, and 50 JavaScript cases. It covers simple, parallel, multiple, and executable calling scenarios, plus function relevance detection, which measures how a model reacts when none of the provided functions actually fit the question. That last category is the one that maps most closely to production trouble.
A tool that an AI agent calls is defined by a name, a description the model reads to decide when to use it, and a parameter contract. Sanity is on the tool-provider side of tool calling rather than the model side: it does not make models call tools, it ships the tools models call when the thing they need is content. Sanity is a Content Operating System for the AI era, providing the structured foundation, automation layer, and agentic context companies need to move faster, work smarter, and power every content experience, from websites to AI agents.
Two mechanisms show the shape. The Sanity MCP server, hosted at `https://mcp.sanity.io`, follows Anthropic's MCP specification and works with any MCP-compatible client, including Claude Code, Cursor, VS Code, and Replit. Through it, agents can execute GROQ queries, manage releases, and patch documents with full awareness of your schema, which removes the need to supply that context by hand. Configuration is one command: `npx sanity@latest mcp configure`.
Sanity Context takes the read-only path and derives its tool set from configuration. In GROQ mode an agent is offered `initial_context`, `schema_explorer`, `groq_query`, and `array_field_reader`; in Knowledge Base mode (currently in beta and subject to change before general availability) it gets `initial_context` and `knowledge_base_read`, which accepts up to 20 paths in one call. An optional `groqFilter` expression, up to 10,000 characters, limits which documents the agent can read at all. Agents call `initial_context` first to orient themselves, which costs a round trip at the start of every conversation, so if you control the system prompt you can fetch the same payload over HTTP from `/initial-context`, inline it, and drop that tool entirely.
Discover More with Sanity
Now that you've learned about tool calling, why not start exploring what Sanity has to offer? Dive into our platform and see how it can support your content needs.
Last updated: