Function calling (also called tool use) is the mechanism by which large language models bridge natural language understanding and structured programmatic execution — the model does not run code itself, but emits a structured description of what should be called and with which arguments, letting your application execute and return the result. It is the core primitive underpinning modern AI agents, enabling models to query databases, call REST APIs, search the web, and write files. The critical mental model: function calling is a contract between your schema and the model — the quality of your descriptions and parameter definitions directly determines reliability, and every round-trip through the tool loop is an extra API call that adds latency and cost.
What This Cheat Sheet Covers
This topic spans 12 focused tables and 92 indexed concepts, 75 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: JSON Schema Tool Definition Structure
Every provider requires you to describe your tools using a JSON Schema subset. Getting this structure right is the single most important step in function calling: the model uses your names, descriptions, and parameter definitions to decide when and how to call each tool.
| Pattern | Example | Description | |
|---|---|---|---|
{"type": "function", "function": { "name": "get_weather", "description": "Get current weather", "parameters": { "type": "object", "properties": { "location": {"type": "string"}}, "required": ["location"] } }} | • Tools are passed in a tools array• each entry has type: "function" wrapping a function object with name, description, and parameters (a JSON Schema object). | ||
{"name": "get_weather", "description": "Get current weather", "input_schema": { "type": "object", "properties": { "location": {"type": "string"}}, "required": ["location"] }} | • Anthropic uses input_schema (not parameters) for the JSON Schema object• tools are passed in a top-level tools array on the messages request | ||
{"function_declarations": [{ "name": "get_weather", "description": "Get weather", "parameters": { "type": "object", "properties": { "location": {"type": "string"}}, "required": ["location"] }}]} | • Gemini wraps declarations in a function_declarations list inside a tools array• schema format follows OpenAPI 3.0 conventions | ||
"type": "string" / "integer" / "number" / "boolean" / "array" / "object" | • Standard JSON Schema primitive types • map directly from Python ( str→string, int→integer, float→number, bool→boolean, list→array, dict→object). | ||
"required": ["location", "unit"] | • Lists parameters the model must provide • omitted parameters are treated as optional and may or may not be included | ||
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]} | • Restricts a parameter to a fixed set of values • strongly improves accuracy by reducing the model's output space for that argument | ||
"location": {"type": "string", "description": "City and state, e.g. Austin, TX"} | • Per-parameter descriptions are read by the model • more detail → more accurate argument generation • Include format examples inside the description string | ||
"parameters": { "type": "object", "properties": {...}, "required": [...], "additionalProperties": false} | • Required for OpenAI strict mode ( strict: true)• rejects extra keys • Must be set on every nested object as well | ||
"address": {"type": "object", "properties": { "city": {"type": "string"}, "zip": {"type": "string"}}, "required": ["city"]} | • Full JSON Schema nesting is supported • for strict mode, each nested object needs its own additionalProperties: false and all fields in required. | ||
"$defs": {"Node": {...}},"properties": { "children": {"items": {"$ref": "#/$defs/Node"}}} | • Recursive or reusable schemas use $ref pointing to $defs• supported by OpenAI structured outputs for tree-like data structures |