Function calling is an AI application pattern where a model chooses a developer-defined tool and returns structured arguments so the application can call real business logic. Teams use it to let assistants retrieve data, create tickets, schedule work, search systems, or call APIs while the application remains responsible for execution and validation. In daily Azure work, it shows up when engineers build agents, connect chat to backend tools, audit model-selected actions, validate JSON arguments, or debug why a model called the wrong function.
tool calling, OpenAI function calling, model tool call
Difficulty
advanced
CLI mappings
4
Last verified
2026-05-14
Microsoft Learn
A model interaction pattern where an AI model selects a developer-defined tool or function and returns structured arguments for application code to execute.
Technically, Function calling is configured through Azure OpenAI or Azure AI Foundry model deployments, tool definitions, JSON schemas, chat messages, model responses, application execution code, validation logic, and follow-up tool-result messages. Important settings include model deployment, tool name, description, parameter schema, tool choice, temperature, max tokens, response handling, authorization context, timeout, and logging or redaction policy. Operators inspect it with request and response logs, tool-call arguments, application traces, deployment names, content safety results, latency metrics, failed validation records, and audit logs for executed backend operations.
Why it matters
Function calling matters because it turns architecture intent into runtime behavior. When teams misunderstand it, they may change the wrong scope, grant access too broadly, overload capacity, hide a data exposure path, or chase an application bug that is really platform configuration. For this term, that means the model proposes the action, but the application executes it, so design reviews must separate model reasoning from authorization, validation, and side effects. It affects security, reliability, operations, cost, and performance because one choice can change how users, identities, traffic, data, deployments, or events behave. Review owner, scope, evidence, dependencies, and rollback before production change.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
An Azure OpenAI request includes tool definitions with names, descriptions, and JSON parameter schemas, while the model response contains a structured tool call. Review owner, scope, evidence, dependencies, and rollback before production change.
Signal 02
Application traces show the tool call arguments being validated, authorized, executed against an API, and returned to the model as a tool result. Review owner, scope, evidence, dependencies, and rollback before production change.
Signal 03
Agent design reviews list which tools are read-only, which have side effects, who can invoke them, and how failed calls are logged. Review owner, scope, evidence, dependencies, and rollback before production change.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Design and document Function calling before a production release changes traffic, identity, data access, deployment, or runtime behavior.
Use Function calling during incident triage to narrow the affected scope and gather evidence before changing live settings.
Review Function calling during architecture, security, cost, performance, and reliability planning for the workload.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Function calling in action for customer support automation
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Lucerne Telecom, a communications provider, wanted its support assistant to look up orders and create service tickets without giving the model direct system access.
🎯Business/Technical Objectives
Let users request account actions in chat
Keep authorization in application code
Audit every tool execution
Reduce support handling time
✅Solution Using Function calling
The team used Function calling with an Azure OpenAI deployment and application-owned tools. Developers defined read_order_status and create_ticket schemas with narrow parameters and clear descriptions. When the model returned a tool call, the application validated arguments, checked the signed-in user, called the internal API, and sent the result back to the model. Application Insights traced prompts, tool names, validation failures, API latency, and ticket IDs. Side-effecting ticket creation required explicit user confirmation before execution. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release. Security, reliability, cost, and performance evidence were captured together so reviewers could see the operational tradeoffs rather than only the deployment result.
📈Results & Business Impact
Average chat handling time fell by 32 percent
Unauthorized tool attempts were blocked
Ticket creation was fully auditable
Human agents handled fewer routine status calls
💡Key Takeaway for Glossary Readers
Function calling is powerful when the application, not the model, controls validation, authorization, and side effects.
Case study 02
Function calling in action for field service scheduling
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Tailspin Utilities, an energy services company, needed a field assistant to schedule technician visits from natural-language customer conversations.
🎯Business/Technical Objectives
Convert chat requests into scheduling actions
Prevent invalid appointment windows
Log every backend action
Keep failed calls recoverable
✅Solution Using Function calling
The engineering team used Function calling to expose approved scheduling tools to the assistant. Tool schemas limited inputs to customer ID, service type, date range, and location. The application validated those arguments, checked entitlement, called the scheduling API, and returned available slots to the model. A second confirmed tool call booked the appointment. Operators reviewed Azure OpenAI deployment access, application traces, and failed call dashboards. The design separated conversation quality from backend execution safety. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release. Security, reliability, cost, and performance evidence were captured together so reviewers could see the operational tradeoffs rather than only the deployment result.
📈Results & Business Impact
Invalid booking attempts dropped by 57 percent
Scheduling API calls were traceable
Customer confirmations reduced mistaken bookings
First-contact resolution improved by 24 percent
💡Key Takeaway for Glossary Readers
Tool schemas and application validation make AI-assisted workflow automation practical without surrendering control to the model.
Case study 03
Function calling in action for financial compliance research
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Granite Ledger, a financial analytics firm, needed analysts to ask natural-language questions that could call approved portfolio and policy lookup APIs.
🎯Business/Technical Objectives
Allow read-only analytical tools
Block side-effecting operations
Record arguments for review
Reduce manual lookup time
✅Solution Using Function calling
The team used Function calling with only read-only tools during the first release. Developers defined schemas for portfolio_lookup, policy_search, and risk_summary. The application validated every argument, enforced analyst entitlements, redacted sensitive values from logs, and returned tool results to the model for summarization. CLI checks verified the AI resource, model deployment, and resource access assignments. Because no tool could change records, the compliance team approved a narrow pilot before considering write actions. Architects documented ownership, rollback steps, monitoring signals, and approval evidence so support staff could operate the design without guessing during incidents. The rollout included a lower-environment test, a named business owner, and a short runbook explaining what to verify before and after release. Security, reliability, cost, and performance evidence were captured together so reviewers could see the operational tradeoffs rather than only the deployment result.
📈Results & Business Impact
Analyst lookup time fell by 41 percent
No write-capable tools were exposed
Argument logs supported compliance review
The pilot expanded after two clean audits
💡Key Takeaway for Glossary Readers
Function calling lets AI applications use enterprise APIs safely when tools are narrow, observable, and permission-aware.
Why use Azure CLI for this?
CLI checks make Function calling review repeatable because they capture scoped evidence for configuration, ownership, dependencies, health, and change impact before operators modify production.
CLI use cases
List or show the Azure resources related to Function calling before selecting a target for deeper review.
Capture read-only evidence for Function calling during release approval, incident response, access review, or cost investigation.
Compare configuration, metrics, logs, and dependent resources for Function calling across environments before approving a mutating command.
Before you run CLI
Confirm tenant, subscription, resource group, application, profile, account, endpoint, or deployment scope before trusting command output.
Run list and show commands first, then save evidence before create, update, restart, delete, purge, scale, or access changes.
Check whether the command affects customer traffic, credentials, cached content, model behavior, data access, cost, or compliance evidence.
What output tells you
Names, resource IDs, locations, SKUs, enabled states, and parent relationships show whether you are inspecting the intended target.
Settings, identities, routes, deployments, indexes, endpoints, origins, or app settings explain how requests and workloads behave today.
Timestamps, metrics, usage, health state, and logs help separate Azure configuration issues from application or downstream failures.
Mapped Azure CLI commands
Function calling operational checks
direct
az cognitiveservices account show --name <ai-resource> --resource-group <resource-group>
az cognitiveservices accountdiscoverAI and Machine Learning
az cognitiveservices account deployment list --name <ai-resource> --resource-group <resource-group>
az cognitiveservices account deploymentdiscoverAI and Machine Learning
az monitor app-insights component show --app <app-insights-name> --resource-group <resource-group>
az monitor app-insights componentdiscoverAI and Machine Learning
az role assignment list --scope <ai-resource-id> --output table
az role assignmentdiscoverAI and Machine Learning
Architecture context
Technically, Function calling is configured through Azure OpenAI or Azure AI Foundry model deployments, tool definitions, JSON schemas, chat messages, model responses, application execution code, validation logic, and follow-up tool-result messages. Important settings include model deployment, tool name, description, parameter schema, tool choice, temperature, max tokens, response handling, authorization context, timeout, and logging or redaction policy. Operators inspect it with request and response logs, tool-call arguments, application traces, deployment names, content safety results, latency metrics, failed validation records, and audit logs for executed backend operations.
Security
Security for Function calling starts with tool schemas, argument validation, user authorization, prompt injection controls, secrets, backend API permissions, content filtering, audit logs, and limiting which actions the model can request. Review who can create, update, delete, execute, read logs, approve dependencies, and manage credentials or identities. Prefer Microsoft Entra ID, managed identity, private networking, least privilege, and audited automation where the service supports them. Keep secrets out of code and avoid broad public exposure unless there is a documented exception. Capture role assignments, diagnostic settings, policy decisions, Activity Log entries, and owner approvals so access and data handling are intentional and reviewable.
Cost
Cost for Function calling is driven by token usage for tool definitions and messages, model deployment pricing, retries, backend API calls, logging volume, human review time, failed tool loops, and duplicated agent experiments. The expensive mistake is not only Azure consumption; it can also be duplicate experiments, emergency support, overprovisioned capacity, unnecessary data transfer, or cleanup after weak design evidence. Review whether the workload truly needs the selected tier, retention, diagnostics, network path, scale rule, cache behavior, or automation pattern. Use tags, budgets, alerts, and cleanup reviews so teams can explain why the design exists and remove stale resources safely.
Reliability
Reliability for Function calling depends on schema accuracy, model deployment availability, validation failures, retry strategy, tool timeout handling, idempotency, tool-result messages, fallback responses, and dependency health for backend APIs. A resource can be present and still fail the business workflow if routing, identity, quota, storage, code, cache, scale, or downstream health is wrong. Test failure modes, retries, deployment behavior, disabled states, rollback steps, and maintenance windows before relying on the design. During incidents, compare platform metrics, logs, deployment history, and application traces from the same time window before changing production. The goal is a recoverable configuration support teams can verify quickly.
Performance
Performance for Function calling depends on model latency, schema size, tool selection accuracy, backend API response time, retry loops, streaming behavior, argument validation, dependency fan-out, and end-to-end task completion time. Measure platform metrics and application-side completion times because a fast control-plane response does not prove users received the right result. Test with realistic regions, data sizes, concurrency, authentication paths, route choices, cache state, package size, and downstream limits. When performance regresses, compare configuration changes, resource limits, client logs, diagnostic data, and workload timing before adding capacity or blaming one service. Tune with evidence from the exact environment and traffic pattern.
Operations
Operations for Function calling require tool inventory, schema versioning, prompt and deployment changes, trace correlation, approval for side-effecting tools, failed call dashboards, rollback, and support runbooks for agent behavior. Before a change, capture read-only CLI output, portal evidence when useful, owner tags, expected behavior, and rollback steps. During incidents, avoid changing several settings at once; compare metrics, logs, deployment operations, identity evidence, network state, and downstream health first. Keep runbooks clear enough for support teams to verify current behavior quickly. Good operations make the term observable, reviewable, and recoverable during releases, audits, and incidents. Review owner, scope, evidence, dependencies, and rollback before production change.
Common mistakes
Treating Function calling as a simple label instead of checking the live scope, owner, dependencies, and current configuration.
Running a mutating command for Function calling in the wrong subscription, resource group, app, profile, route, or account context.
Assuming successful deployment proves Function calling works without checking logs, metrics, user behavior, and rollback evidence.