Use the function tool
Unit 6 of 8 · Module 4: Develop generative AI apps that use tools
Go deeper
Unlocks when you've watched the lesson.
Read this lesson
The model asks, your app acts
The function tool, often called function calling, lets the model use functions you've written, to fetch data or make something happen in the middle of a reply. The model decides when to reach for one of the named tools you offer, but it never runs your business logic itself. What it hands back is a structured function call, a bit like a waiter writing an order ticket for the kitchen. Your code is the kitchen: it runs the function, then passes the result back to the model. That's how the model's reasoning gets hooked up to real systems: APIs, databases, business workflows, and small utility functions. What you get: clear, structured requests for each call; control over how and where functions run; a safe, reliable path to APIs, internal services, and helpers; multi-turn orchestration, where the result goes back in and the model keeps thinking; and answers grounded in live data from your own systems. Typical jobs: looking up an order or an account in an internal API, creating a support ticket or sending a notification, or checking a business rule or reference table before answering.
A get time example
Let's walk through a tiny example. In your code, write a get time function, and describe it in the tools list: type function, name get time, and a short description. Keep a running list of messages, starting with a developer message. Then, in a loop, add the user's prompt, call responses dot create with the messages and tools, and add the response output to the list. If that output contains a function call for get time, run the function, and append a function call output item carrying the call ID and the result. Then call the model again, so it can answer using what the function returned. Say hello, and the model just says hello back. Ask what time it is, and the model calls get time, your app runs it, and the model answers with the actual time. This one has a single function with no parameters, but you can define as many functions as you need, with or without parameters.
Process, practices, limits
So the full flow goes like this: you define the tools. The model reads the prompt. It sends back a function call, with the function's name and the call details. Your app runs the matching function. You return a function call output with the result. And the model finishes its answer. Some good habits: keep each tool small and focused, so it's easy to control and test. Validate the inputs, because in production you should never blindly trust the arguments a model sends. Handle errors gracefully, and send back a clear error message the model can work with. Log every call, how long it took, and whether it failed. And require explicit authorization before anything high-impact, like issuing a refund. Keep the limits in mind: the model can only ask for a call, and your app has to run it. Its arguments can be wrong or surprising, so check them. Each tool call adds some delay. And critical decisions still need a human to review them. Used well, function calling turns a text generator into a coordinator for your real systems, one you can control and audit.
Facts from Microsoft's documentation: How to use function calling with Microsoft Foundry Models (CC BY 4.0), rewritten in Loop's own words and examples. Narration, animation, and quiz by Loop. The coding lab is based on code samples in Microsoft's Azure AI documentation (MicrosoftDocs/azure-ai-docs, MIT License; notice). Microsoft, Azure, and Microsoft Foundry are trademarks of Microsoft. Loop is independent and not affiliated with or endorsed by Microsoft.