Function Calling is the most common mechanism large language models use to reach external capabilities: developers first describe "which functions exist and what their parameters look like" in JSON Schema, and when the model needs data or an action mid-conversation, it emits a structured call request. Your program executes the real function and feeds the result back so the model can continue. The key point in one sentence: the model only decides "what to call and what parameters to fill in"—the code that actually runs is always yours.
What problem does it actually solve?
A model natively only outputs text; it cannot do "hands-on" things like checking the weather, reading a database, or placing an order. Function Calling builds a bridge in between: the model understands the request in natural language, expresses "which function I want to call and with what parameters" in a structured format, and leaves execution to the program. This is exactly the foundation that tool calling stands on.
What a complete function call looks like
- Define: include a tools array in the request, spelling out each function's name, description, and parameter structure (JSON Schema).
- Decide: when the model needs an external capability, it does not answer directly but returns tool_calls: a function name plus parameter JSON.
- Execute: your program parses the tool_calls and invokes the real function—calling an API, reading a database, or running a script.
- Feed back: the result goes back into the conversation as a tool message, and the model composes its final answer from it.
The key building blocks
- tools definitions: an "instruction manual" for the model. The clearer the description, the more accurate the parameters—note that description is written for the model, not for humans.
- tool_choice: controls whether the model "must call / may call / must not call" a given function; typically auto, none, or a specific function name.
- Parallel calls: return multiple tool_calls at once, handy for getting several independent things done in one round.
- Structural constraints: parameters must be valid JSON; a type error fails on the program side, so Schema constraints are rigid.
How it really differs from tool calling, MCP, and plugin calling
| Dimension | Function Calling | Tool Calling | MCP | Plugin Calling |
|---|---|---|---|---|
| Essence | A calling mechanism | Umbrella term | A connection protocol | A capability-distribution model |
| Who defines tools | The developer, in the request | Varies | Exposed by an MCP server | Packaged by the platform |
| Problem solved | How the model initiates a call | How the model uses external capabilities | How tools are discovered and uniformly connected | How capabilities reach users |
Function Calling was popularized by OpenAI in 2023, and most mainstream models now support compatible implementations; tool calling is the bigger bucket, holding function calling, code execution, and MCP tools alike. Remember: MCP handles "how to connect", plugins handle "how to distribute", and function calling handles "how to initiate"—the three are links in a chain, not replacements for one another. The boundary with plugin calling follows the same logic.
Boundaries and limits
- Parameter hallucination: the model may invent parameter names or mistype values; the program side must validate.
- Tokens and latency: each call adds a conversation round, and tools definitions consume context too—many tools means expensive and slow.
- Safety red lines: never let the model directly trigger irreversible actions like wiping a database, transferring money, or mass-mailing; sensitive actions need human confirmation.
- Capability gaps: models differ in how mature their function-calling support is; smaller models often "talk but never call" or get the format wrong.
Common misconceptions
- "The model really executes code"—it doesn't. It only emits call requests; execution lives in your program.
- "Function calling is MCP"—no. MCP is a protocol layer; tools it exposes can still be used by the model via mechanisms like function calling.
- "Function calling makes plugins unnecessary"—plugins distribute capabilities to users, function calling serves developers; different layers.
- "Once defined, the model will always call"—the default is auto; if the model sees no need, it won't call. Specify the function name to force it.
FAQ
Q: Is function calling the same as the tool parameters in various vendors' APIs?
A: Same lineage—"model emits structured calls, program executes"—differing in field names and packaging; migration mostly means rewriting the definitions.
Q: I already use MCP. Do I still need to care about function calling?
A: Yes. MCP handles how tools get connected; function calling handles how the model initiates calls. Upstream and downstream, not either-or.
Q: Can function calling invoke local scripts?
A: Yes. A function is just an entry point in your program; the model doesn't care what's behind it. It only says "which one, with what parameters".
