Choosing agent tools in Foundry Agent Service

Tools are how an agent reaches beyond its training data: running code, searching, calling APIs or acting on a screen. Pick the tool that matches the data source or action the agent needs. Figure 6.1 groups these tools by job and shows the state the service keeps alongside them.

An agent (model, instructions and tools, with tool_choice auto, none or required) sits between a conversation and a memory store, which the service keeps. Below it, its tools fall into three groups: knowledge (file search, Azure AI Search tool, Grounding with Bing Search, Microsoft Fabric tool), actions (function tool, OpenAPI tool with its key taken from a project connection, computer use) and code (code interpreter). — Figure 6.1: An agent and the tools it can call, grouped by job, with the state the service keeps for it

Need	Tool
Calculations, data analysis in Python	Code interpreter (sandbox)
Current public web data with citations	Web search (recommended; no separate Bing resource) or Grounding with Bing Search (via a project connection)
Files uploaded to the agent or chat	File search (chunks and embeds into a vector store)
Curated existing index	Azure AI Search tool (`project_connection_id` plus index name)
External REST API	OpenAPI tool
Your own code	Function tool
GUI automation	Computer use
Enterprise analytics data	Microsoft Fabric tool

Controlling whether tools are called

Giving an agent a tool doesn’t guarantee it uses it. The tool_choice setting controls that.

`tool_choice`	Behaviour
`auto` (default)	Model decides, and may skip the tool
`none`	No tool calls
`required`	At least one tool call every run; the documented fix when an agent won’t call its tool

tool_choice="required" with one MCP knowledge-base tool gives grounded, cited answers every run. By contrast, tools only lists what’s available, and response_format sets the output format; neither forces a call. knowledge_base isn’t a valid choice.
When you use the Responses API MCP tool, the tool choice needs the server label.

Get the whole book

This note is one section of Ultra Transcenders AI-103: Developing AI Apps and Agents on Azure, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.

Amazon.co.ukKindle: coming soonPaperback: coming soon

Amazon.comKindle: coming soonPaperback: coming soon

Publishing soon on Amazon in Kindle and paperback editions.

About the book · Free AI-103 glossary · All AI-103 study notes

More AI-103 study notes

Guardrails in Microsoft Foundry: intervention points, Prompt Shields and actions
Where guardrails check an agent run, what Prompt Shields catch, and when to block or annotate.
Agent oversight: approvals, constraints and tool-access controls
How to keep humans in the loop and limit what an agent's tools can do.
Prompt engineering techniques for Azure AI apps
System messages, few-shot examples, chain of thought and grounding, and which fix suits which prompt problem.
Azure AI Search indexers, skillsets and the knowledge store
The indexer pipeline stages, built-in and custom skills, and knowledge store projections.
Vector, hybrid and semantic search in Azure AI Search
Vector fields and profiles, HNSW vs exhaustive KNN, hybrid queries with RRF, and the semantic ranker.
Azure Content Understanding: analyzers, modes and structured output
Prebuilt and custom analyzers, field extraction methods and Markdown output for RAG.
Video generation with Sora 2 in Microsoft Foundry
What Sora 2 can generate, its parameters and limits, and how the asynchronous jobs work.