AI-103 Practice Question 15: Toolbox Shared Tools
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 2 · question 5 of 10
A platform team supports fourteen agents: some are Foundry prompt agents, the rest are code agents built on Agent Framework and LangGraph. All fourteen wire up the same six internal tools, each with its own copy of the connection settings and credentials. When one backing API changed its auth scheme last quarter, the team had to edit and redeploy every agent. They want the tools defined once, credentials handled centrally, and a tool change rolled out without touching agent code.
What should they build?
Show answer and explanation
Answer:
A toolbox is the Foundry construct for exactly this problem. You curate a set of tools once and expose them behind one MCP-compatible endpoint, with centralized credential injection, token refresh and policy enforcement using Microsoft Entra ID and OAuth identity passthrough. Toolboxes are *Foundry-homed but not Foundry-bound*, so the LangGraph and Agent Framework agents consume the same endpoint as the prompt agents. Versioning closes the loop: create a new toolbox version, test it, promote it to default, and every consuming agent picks it up with no redeployment.
- A is wrong because an OpenAPI tool still has to be attached and configured, with its own authentication, on each of the fourteen agents. It consolidates the *API surface*, not the per-agent configuration and credentials that caused the churn. - C is wrong because it multiplies the problem: six new function apps to operate, and each agent still holds its own tool wiring. It also changes the hosting model for no stated reason. - D is wrong because a shared package only helps agents written in a language that can import it, and every agent still has to be rebuilt and redeployed to pick up a new version, the exact cost they are trying to remove.
Reference: What is Toolbox in Microsoft Foundry?