AI-103 Practice Question 6: OpenAPI Tool vs Function Calling
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 1 · question 6 of 10
A logistics company runs a prompt agent in Foundry Agent Service that customers reach through a chat widget. The agent must look up live shipment status from an existing internal REST service, which already publishes an OpenAPI 3.0 specification and accepts Microsoft Entra tokens. Because the agent is fully managed by Foundry and the widget is a thin client, there is no application process of the company's own sitting in the request path to execute callbacks. The team wants the least additional code to build and operate.
How should the shipment lookup be exposed to the agent?
Show answer and explanation
Answer:
The OpenAPI tool connects a Foundry agent to an external API described by an OpenAPI 3.0 or 3.1 specification, so the model powering the agent can call the service and retrieve real-time data. It supports anonymous, API key, and managed identity authentication; managed identity fits an Entra-protected internal service, with the least-privileged role assigned to the project's managed identity. Nothing new has to be written or hosted.
- B is wrong because function calling is client-side execution: the service returns the call the model wants to make, and your own application must run it and hand the output back. This agent has no such process in the request path, so the loop never closes. - C is wrong because file search grounds the agent in the *content* of documents. It would let the agent describe the API's endpoints from the spec text; it never invokes them, so shipment status is still unavailable. - D is wrong not because it fails but because it is redundant work. An MCP server is the right answer when you need one endpoint governing many tools; here it means building and operating a server to re-describe an API whose specification the OpenAPI tool already consumes directly.
Reference: Connect OpenAPI tools to Microsoft Foundry agents