How to integrate custom tools
Unit 4 of 6 · Module 8: Integrate custom tools into your agent
Go deeper
Unlocks when you've watched the lesson.
Read this lesson
Function calling in code
Now let's wire custom tools into an agent, using the three main options. Pick whatever fits: your company may already have Azure Functions, or a public API may publish an OpenAPI description. First, function calling. You start with an ordinary function, like check stock, for Pedalwise, the bike shop: it takes a bike model and returns how many are in stock, as JSON. Its docstring explains what it does, what the bike parameter means, and what comes back. Next, you describe it to the agent as a function tool. You give it a name, a description, and its parameters, written as a JSON schema: a small, formal description of the input. Here the schema says the input is an object with one property, bike, which is a string, and it's required. Additional properties false means nothing else is allowed, and strict true tells the model to follow the schema exactly. Then you add the tool to a list and create the agent version, with a model, instructions, and those tools. From then on, whenever a customer asks what's in stock, the agent can ask for check stock, with the right bike.
Azure Functions and OpenAPI
Second, Azure Functions: serverless code that reacts to triggers, like an HTTP request or a message on a queue. You develop and deploy the function first, then add it to the agent as an Azure Function tool. The tool definition has two bindings, each pointing at a storage queue. The input binding is the queue the agent drops a request into; that message triggers the function. The output binding is the queue where the function puts its answer, and the agent picks it up from there. You also give the function a name, a description, and its parameters, just like before. Third, OpenAPI tools, which use OpenAPI 3.0 or 3.1 specifications. You write a JSON file that describes the API. The servers section gives the base address, here a public weather service. Each path is an operation, with an operation ID, its parameters, like a location in the path and a format in the query string, and the responses it can return, such as two hundred for success, or four oh four when a location isn't found. Then you register it as an OpenAPI tool, with a name, the spec, a description, and how to authenticate. Three authentication types are supported: anonymous, API key, and managed identity.
You describe, the agent decides
Here's the idea developers often find strange at first. You never write code that says: if the user asks about stock, call this function. The solution is declarative: you describe the tools, and the agent decides when and how to use them, based on each prompt. That's why good names and well-documented parameters matter so much. A function called get data, with a parameter called x, gives the agent almost nothing to go on. A function called check stock, with a bike parameter described as a bike model, tells it exactly when it fits. Use one option, or combine several, and your agents can reach external systems, process in real time, and scale with your workflows.
Facts from Microsoft's documentation: Use function calling with Microsoft Foundry agents; Connect OpenAPI tools to Microsoft Foundry agents; Integrate Azure Functions with Foundry Agents (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.