What Is Function Calling? The Model Asks, Your Code Answers, and Nothing Runs Until You Run It (2026)

Quick answer: Function calling is how a language model requests an action it cannot perform itself. You hand it a list of callable functions described in JSON Schema. When a customer asks "where is order 4417," the model does not look anything up. It emits a structured object that says, in effect, call get_order_status with order_id: "4417" — and then it stops and waits. Your application receives that object, decides whether to run it, runs it, and posts the result back in a second request so the model can turn a row of data into a sentence. Two model requests per answer, an executor that belongs entirely to you, and a tool list that is billed as input tokens on every single turn. Vendors sell the first half of that sentence and rarely mention the rest.

The loop, and the two requests nobody budgets for

OpenAI's guide breaks the flow into five steps, and the shape is identical on Anthropic's API even though the field names differ. It is worth reading slowly, because the interesting part is where the sequence pauses.

1. You make a request to the model and include the tools it may call.
2. The model replies with a tool call rather than an answer.
3. Your code executes the operation, with the arguments the model supplied.
4. You make a second request carrying the tool output.
5. The model returns a final answer, or asks for more tool calls.

The same sequence, read as a question of who is holding the baton:

Step three is the only row where code runs, and it is code you own. The model produces a request and a sentence; it produces no side effects.

That third row is the whole entry. Anthropic states it plainly: the model "returns a structured call that your application executes." The model has no network access to your database, no credential, and no ability to retry. It emits an object and stops. Which means that every question people ask about tool-using bots — can it refund the wrong customer, can it be talked into deleting something, what happens if it invents an order number — is a question about your executor and not about the model. The model can request anything at all. Your code is the entire enforcement surface.

There is one qualification worth carrying into a vendor conversation. Anthropic distinguishes client tools, which run in your application, from server tools such as web search, web fetch and code execution, which run on Anthropic's own infrastructure and return results without your handling execution at all. So "the model cannot run code" is true of the tools you define and not of every tool in the catalog. Ask which kind you are buying.

The second thing that fourth row costs you is structural. A tool-using answer is a minimum of two model requests, and each one re-sends the conversation so far plus the whole tool list. A three-hop answer is four requests. Nobody prices a chatbot this way in a proposal.

The declaration is a JSON Schema, and "one standard" is not quite true

A tool definition is a small, boring object, and the boredom is the point: it is documentation written for a reader who cannot ask you a follow-up question. OpenAI's shape carries type, name, description, parameters (a JSON Schema) and strict. Anthropic's carries a name, a description and an input_schema. MCP's tool objects carry name, title, description and inputSchema.

Three names for one JSON Schema field is a small thing that tells you something real: the "USB-C for AI" framing, which our own Model Context Protocol entry repeats, describes the server side of the plug. The model-facing side is still per-vendor, which is why frameworks and platforms spend so much code translating between these shapes.

The strict flag deserves a line of its own because it is the difference between a schema that is a hint and a schema that is a contract. OpenAI documents strict mode as guaranteeing that calls adhere to the schema "instead of being best effort," recommends always enabling it, and imposes two requirements to get it: additionalProperties must be false on every object, and every field in properties must be listed as required, with genuinely optional fields expressed by adding null as an allowed type. If you have ever wondered why a vendor's action builder makes you mark everything required, that is why.

What tools cost before a customer types anything

This is the part with actual numbers in it, and they come from the providers' own documentation rather than from us.

OpenAI is explicit about the mechanism: "functions are injected into the system message in a syntax the model has been trained on," which means callable function definitions "count against the model's context limit and are billed as input tokens." Every turn. Not once at setup.

Anthropic publishes the fixed overhead separately, and the table is more interesting than a single number would be. Enabling tool use adds a special system prompt whose size varies by model and by your tool_choice setting — before you have defined a single tool of your own. Claude Opus 5 adds 286 tokens with a tool choice of auto or none, and 406 tokens when a tool is forced. Sonnet 5 adds 354 and 474. Haiku 4.5, much the cheapest of the three, adds 496 and 588, which is more than either — though so do Opus 4.5 and Sonnet 4.5, and that is the tell. The number tracks the model generation rather than its size or price: Opus 4.7 sat at 675 and 804, well over double what Opus 5 costs, while Opus 4.8 sits at 290 and 410. With no tools supplied and a tool choice of none, the overhead is zero.

Two consequences follow, and they explain a piece of vendor behavior that otherwise looks like arbitrary greed.

The first is that a long tool list is a standing tax on every message in every conversation, including the ones that need no tool at all. The second is that accuracy degrades as the list grows: OpenAI's guidance is to "keep the number of initially available functions small for higher accuracy" and to aim for fewer than twenty available at the start of a turn, calling that a soft suggestion rather than a limit. Both providers now ship a tool search mechanism precisely so that large tool catalogs can be loaded on demand instead of declared up front, though OpenAI's version is available only on gpt-5.4 and later models. When your platform caps how many actions an agent may have — Chatbase gates AI Actions at 5, 8 and 12 across its Hobby, Standard and Pro tiers, verified on its pricing page during our May 2026 session — the cap is a packaging decision, but it is sitting on top of a real constraint. If you want to sanity-check what a tool list is doing to your bill, our token counter and LLM API cost calculator work on the same input-token arithmetic.

MCP does not replace function calling. It feeds it

This is the single most common misreading we encounter, including in our own earlier writing, so it is worth being exact.

The Model Context Protocol standardizes how an application discovers and reaches a tool provider. Its own architecture overview draws the boundary in one sentence: MCP "focuses solely on the protocol for context exchange—it does not dictate how AI applications use LLMs or manage the provided context." The same document then describes the runtime path: the AI application "fetches available tools from all connected MCP servers and combines them into a unified tool registry that the language model can access," and when "the language model decides to use a tool," the application "intercepts the tool call, routes it to the appropriate MCP server, executes it, and returns the results back to the LLM."

Read that carefully and the division of labor is clean. The model still selects a tool, using whatever tool-calling format its provider speaks. MCP is what filled the registry and what carries the call onward to whoever implements it. Adding an MCP server does not remove a function-calling step; it changes where the tool definitions came from and who runs the code at the far end.

Two other details from the current specification are worth knowing before a vendor call. MCP became a stateless protocol at version 2026-07-28, with each request carrying its own protocol version and capabilities; the transports are stdio for local servers and Streamable HTTP for remote ones, the latter being HTTP POST with optional Server-Sent Events rather than the older "HTTP+SSE" naming still common in write-ups. And the spec's elicitation primitive lets a server request additional input from the user or ask for confirmation of an action — which is the standardized hook for the confirm-before-write gate that our AI agent integration guide argues you should insist on.

The buyer's real question: who picks the tool, the flow or the model?

Almost every SMB platform will tell you it supports tool calling. The claim is usually true and almost never answers the question that matters, which is whether the model chooses the tool at runtime or whether a branch in your flow chart calls an endpoint at a fixed step and the model only phrases the result. Both are useful. They fail differently, they cost differently, and they need different testing.

Chatbotscape earns affiliate commission on some of the platforms named below. It does not change what we publish. See our affiliate disclosure.

Scores in brackets are the composite editorial scores from each review's frontmatter, not a rating of tool calling. Nine of the fifteen reviews in our set record no MCP support at all as of their last refresh — Manychat, Wati, BotPenguin, Chatfuel, Typebot, Blip, Landbot, Intercom and AiSensy — which is an absence from vendor pages rather than a tested negative.

"MCP support" on a pricing page points in one of two opposite directions

Here is a distinction we have not seen drawn anywhere else, and it fell out of comparing our own reviews against each other rather than from any vendor's documentation.

A platform can be an MCP server: outside AI applications connect in and act on your account. It can be an MCP client: its own agent reaches out to tool servers you connect. Only the second does anything for what your customer-facing bot can do mid-conversation. Both ship under the same three-letter acronym, on the same kind of feature bullet.

Read the Tars row against the Tidio row and the buying lesson is stark. Both are chatbot builders, both advertise MCP, and only one of them lets your bot reach a system it did not previously know about. A hosted MCP server on the vendor's side is a developer-convenience feature — a real one, and useful — but if what you wanted was live stock lookup inside a customer conversation, you will not discover the mismatch until after you have paid.

Where it breaks

Five failure modes, in the order we would test for them. None of them are exotic; all of them are consequences of the loop rather than bugs in it.

The model picks the neighboring tool. get_order_status and get_shipping_estimate sound alike to a reader who only has your description to go on. This is a writing problem, not a model problem, and OpenAI's own best-practice list frames it that way: pass the intern test, use the system prompt to say when not to use each function, use enums and object structure to make invalid states unrepresentable.

The model invents an argument. Nothing in the loop verifies that order 4417 exists; the schema constrains shape, not truth. A hallucinated identifier reaches your executor looking exactly like a real one, which is why validation belongs in your code and not in the prompt. See AI hallucination for the general case.

The result comes back as a string, and gets misread. OpenAI notes that the tool result you return is typically a string whose format is up to you, and the model "will interpret that string as needed." An empty result set and a failed lookup can look identical to the model unless you make them different.

Something in the conversation asks for the tool. Once a bot can act, text arriving from a customer, a knowledge-base document or a web page becomes a potential instruction. This is prompt injection with consequences attached rather than merely embarrassing output, and our prompt injection tester is a starting probe set.

Parallel calls arrive in a batch. Both providers allow several tool calls in one turn and both let you switch it off — OpenAI with parallel_tool_calls: false, Anthropic with disable_parallel_tool_use. OpenAI's guidance is to assume there may be several. Executors written for exactly one call are a recurring source of dropped work.

Related terms

• Model Context Protocol — the discovery and transport standard that fills the tool registry function calling then selects from.
• AI agent — what you get when the loop above runs repeatedly toward a goal instead of once.
• Large language model — the component that emits the call, and the one that never executes it.
• Chatbot API — the three layers that share the word API, and where a platform API sits among them.
• Webhook — the inbound counterpart: the platform calling your server, rather than your code calling a tool.
• AI hallucination — the general form of the invented-argument failure above.

FAQ

What is function calling in simple terms?

It is how a language model asks for something to be done. You give it a menu of functions it may request, each described in plain language with a schema for its arguments. Instead of writing an answer, the model can hand back a structured request naming one function and its arguments. Your application runs it, gives the model the result, and the model writes the answer. The model never runs anything; it writes the order slip.

Is function calling the same as tool calling?

Yes, in practice. OpenAI's guide opens by saying function calling is "also known as tool calling," and Anthropic documents the identical loop under the name tool use. Older material tends to say functions, newer material tends to say tools, and platform interfaces often use a third word such as actions. If a vendor uses several of these on one page, ask them to point at the schema.

What is the difference between function calling and MCP?

They operate at different layers and you generally use both. Function calling is the model-facing mechanism: the model emits a structured request, your application executes it. MCP is the application-facing standard for discovering and reaching tool providers, so that a connector written once works with any compatible host. MCP's own specification says it does not dictate how AI applications use language models, and the architecture overview describes the host collecting MCP tools into a registry the model then selects from. So MCP supplies and routes; function calling chooses.

Does function calling stop the chatbot from making things up?

It changes what gets made up. Grounding an answer in a live lookup removes a large class of invented facts, which is the same argument made for retrieval-augmented generation. But the arguments themselves are generated, so a model can confidently request a lookup for an order number that never existed. Schema validation constrains the shape of a request, not its truth. Verification belongs in the code that runs before the query.

How many tools should an AI chatbot have?

Fewer than the platform allows. OpenAI's published guidance is to keep the number of initially available functions small for higher accuracy and to aim for under twenty at the start of a turn, though it calls that a soft suggestion rather than a limit. Both major providers now ship a tool-search mechanism so large catalogs can be loaded on demand instead of declared up front, with OpenAI's requiring gpt-5.4 or later. The cost side pushes the same direction, since every definition is re-sent and re-billed on every turn. In an SMB deployment, three well-described tools generally beat ten.

Does function calling make the chatbot slower or more expensive?

Structurally, yes, on both counts, though we publish no measurements of our own. A tool-using answer takes at least two model requests instead of one, and each request re-sends the conversation plus the full tool list. On top of that, enabling tool use adds a fixed system-prompt overhead that Anthropic publishes per model — 286 tokens for Claude Opus 5 at the default tool choice, 496 for Haiku 4.5 — before any of your own definitions are counted. Whether that matters depends on how often a tool actually gets called.

My platform says it supports function calling. What should I check?

Three things, in this order. Does the model select the tool at runtime, or does a step in your flow call an endpoint at a fixed point and the model only narrates the result? How many tools may an agent have on your plan, and is that a packaging cap or a technical one? And can you see, per conversation, which tool was chosen and why — the debug view our Botpress review singles out as a strength is the difference between tuning a bot and guessing at it. The AI agent integration guide turns those into a longer vendor script.

Sources

• OpenAI. Function calling, API documentation — the five-step tool-calling flow, the function definition fields (type, name, description, parameters, strict), the statement that functions are injected into the system message and billed as input tokens against the context limit, the guidance to keep initially available functions small and aim for fewer than twenty at the start of a turn, strict-mode requirements (additionalProperties: false, all properties required, null for optional), tool_choice values, parallel_tool_calls, tool search for deferred loading, and the best-practice list including the intern test and the use of enums to make invalid states unrepresentable. developers.openai.com (read 9 August 2026).
• Anthropic. Tool use with Claude, Claude Platform documentation — the statement that Claude returns a structured call your application executes, the client-tool versus server-tool split, stop_reason: "tool_use", the tool_use and tool_result blocks with tool_use_id, the input_schema field name, strict: true, disable_parallel_tool_use, the note that tool-calling behavior is steerable through the system prompt, and the published per-model tool-use system-prompt token table (Opus 5 at 286/406, Sonnet 5 at 354/474, Haiku 4.5 at 496/588, Opus 4.7 at 675/804, and zero when no tools are supplied with a tool choice of none). platform.claude.com (read 9 August 2026).
• Model Context Protocol. Architecture overview, specification version 2026-07-28 — the scope statement that MCP does not dictate how AI applications use LLMs, the host/client/server participants, the data and transport layers with stdio and Streamable HTTP, the tools/resources/prompts primitives with name, title, description and inputSchema, tools/list and tools/call, the description of the host combining server tools into a unified registry and intercepting the model's tool call, statelessness and server/discover, and the elicitation primitive for requesting user input or confirming an action. modelcontextprotocol.io (read 9 August 2026).
• Chatbotscape platform reviews: Botpress (Autonomous Engine tool selection, per-turn debug visibility, and bi-directional MCP verified against the public awesome-mcp-servers catalog; that review's evidence block calibrates each item, and the builder walkthrough is marked docs-signal rather than a paid-account run), Voiceflow (the MCP server announcement plus MCP tool blocks in Studio), Tars (the ~9-minute Grafbase MCP client connection to a Google Sheets server, with read and write confirmed), Chatbase (AI Actions, the 5/8/12 tier caps, and the 17-minute Stripe action build, May 2026), AiSensy (the Tool Calling configuration form captured in an authenticated Free-tier session on 29 May 2026), Landbot (API-node webhook invocation, recorded as not function-calling-style), Intercom, Tidio (the "Now with MCP" Smart Actions claim, vendor page 26 May 2026) and SendPulse (the hosted MCP server endpoint). Each review carries its own verification dates and basis labels, and where a claim rests on vendor documentation rather than a session the table above says so.
• Ahrefs Keywords Explorer, US and volume-by-country, 9 August 2026 — the search-demand figures in this entry's keyword note.
• Chatbotscape evaluation methodology. /methodology (continuously updated).