Tool Categories
Tools extend what an agent can do beyond generating text. The Azure AI Foundry Agent Service supports two categories: built-in tools (provided by the service with no implementation required) and function/API tools (custom logic you define via a JSON schema). The model decides which tool to call — and when — based on the tool descriptions and the user's query.
Built-in Tools Overview
| Tool | What It Does | When to Use |
|---|---|---|
| File Search | Semantic retrieval from the agent's vector store or a connected Azure AI Search index | RAG over uploaded documents |
| Code InterpreterA built-in tool that runs arbitrary Python code in a fully sandboxed, network-isolated environment. Files must be uploaded specifically to Code Interpreter — they are separate from File Search vector store files. | Executes Python code in a sandboxed environment; can read uploaded files, produce charts, run calculations | Data analysis, CSV processing, math, plot generation |
| Bing GroundingA built-in tool that queries the public Bing search index for real-time web results. It is not customizable to search only your site — it always queries public Bing. | Real-time web search via Bing API; injects live search results into context | Current events, product info, anything beyond training cutoff |
| Azure AI Search | Direct connection to an Azure AI Search index (alternative to File Search connection) | Enterprise search with full-text + vector |
Beyond built-in tools, a Function ToolA custom tool defined by a JSON schema describing the function name, purpose, and parameters. The agent runtime returns a tool-call object to the developer's application code, which must execute the function and return results. lets you connect the agent to any external API or internal service via a JSON schema. The Tool ChoiceA configuration setting controlling when the model invokes tools: auto (model decides), required (must call at least one tool), none (no tools), or a specific forced function. setting controls whether the model may skip tools or must call at least one on every turn.
Code Interpreter Deep Dive
Code Interpreter runs arbitrary Python code in an isolated sandbox. It can:
- Parse CSV, Excel, JSON, and image files uploaded to the tool's file list.
- Generate charts and return them as image outputs.
- Perform complex calculations that the model would otherwise approximate.
- Write and iteratively debug its own code based on errors.
Enabling Code Interpreter:
- Open the agent in the Foundry portal → Tools tab.
- Toggle Code Interpreter to Enabled.
- To provide input data, click + Add file under Code Interpreter and upload data files (CSV, XLSX, etc.).
- The model will reference these files by name in generated code (
/mnt/user-data/uploads/<filename>).
Files uploaded to Code Interpreter are separate from files uploaded to the File Search vector store. Code Interpreter files are available for code execution only; they are not semantically indexed.
Function (API) Tools Schema
Function tools let you connect the agent to any external API or internal service. You define a function schema — a JSON object that describes the function name, what it does, and its parameters.
Minimal function schema example:
{
"name": "get_weather",
"description": "Returns current weather for a given city. Use when the user asks about weather conditions.",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "The name of the city, e.g. 'Seattle'"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "Temperature unit"
}
},
"required": ["city"]
}
}
| Schema Field | Purpose |
|---|---|
name | Identifier the model uses to call the function |
description | Natural-language explanation the model reads to decide whether to call it — write this carefully |
parameters.properties | Each argument the function accepts, with type and description |
required | List of parameter names that must be present |
Tool Choice Configuration
| Setting | Behavior |
|---|---|
auto (default) | Model decides whether and which tool to call |
required | Model must call at least one tool; useful when you always need grounding |
none | No tools are called; model replies from its weights only |
{"type": "function", "function": {"name": "X"}} | Forces a specific function to be called |
Use required when you want to guarantee the agent always searches before answering. Use none for pure chat endpoints where tool overhead is undesirable.
Combining Multiple Tools
Multiple tools can be active on a single agent simultaneously. The model can call them sequentially within one turn:
- Example: File Search retrieves a policy document → Code Interpreter parses a data table from that document → the model synthesizes both into a final answer.
- Example: Bing Grounding fetches today's news → a custom function logs the query to your analytics service.
Design guidance when combining tools:
- Write tool descriptions that clearly differentiate their scope so the model does not confuse them.
- Avoid overlapping descriptions (e.g., two "search" tools with no stated scope difference).
- Test each tool independently before combining.
Hands-On: Enable Code Interpreter and Analyze a CSV
Goal: Enable Code Interpreter, upload a CSV, and verify the agent can analyze it.
- Navigate to Azure AI Foundry → Agents → open your agent.
- Click the Tools tab.
- Toggle Code Interpreter to Enabled.
- Under Code Interpreter, click + Add file → upload a CSV file with numerical data (e.g., a sales report).
- Save the agent configuration.
- Switch to the Playground tab.
- Type: "Summarize the data in the uploaded CSV and show me the top 3 rows by revenue."
- Observe the agent's tool call log — it should show a code execution step with Python code operating on the CSV.
- Confirm the response includes accurate data values derived from the file (not hallucinated).
- (Optional) Ask the agent to "plot a bar chart of monthly revenue" and verify an image is returned.
AI-3018 Assessment Focus
The separation between Code Interpreter files and File Search files, and the execution model for function tools (developer code, not Foundry) are the highest-frequency exam traps here.
Exam Trap
"Code Interpreter can access the internet" — False. Code Interpreter runs in a fully sandboxed, network-isolated environment. It cannot make HTTP requests or access external services.
Exam Trap
"Files uploaded to the File Search vector store are automatically available to Code Interpreter" — False. File Search files and Code Interpreter files are separate upload targets with separate storage.
Exam Trap
"Bing Grounding uses your own web content" — False. Bing Grounding queries the public Bing search index. It is not customizable to search only your site.
Exam Trap
"A function schema's description field does not affect when the model calls it" — False. The description is the primary signal the model uses to decide whether to invoke the function. A vague description leads to missed or incorrect tool calls.
Exam Trap
"Tool choice = required forces the agent to use every enabled tool" — False. required means the model must call at least one tool, not all of them. The model still selects which tool(s) are appropriate.
Exam Trap
"The agent executes function tool logic internally" — False. For function tools, the agent runtime returns a tool-call object to your application code. Your code must implement the function and return the result back to the agent.
Question — click to flip
Q: Can Code Interpreter make HTTP requests to external APIs?
Question — click to flip
Q: If a CSV is uploaded to the File Search vector store, can Code Interpreter read it?
Question — click to flip
Q: Who executes the logic of a function tool — Foundry or the developer's application?
Question — click to flip
Q: What does setting tool_choice to 'required' do?
Question — click to flip
Q: Why do two function tools with identical descriptions cause routing problems?
Question — click to flip
Q: What does Bing Grounding search?