Contoso is building a multi-agent operations desk. Agents must call internal inventory, ticketing, and change-management APIs through a consistent tool interface with centralized auth and observability. Leadership wants standards-based agent-to-tool integration rather than ad-hoc function schemas per framework. Which approach best fits Microsoft Foundry multi-agent tooling guidance?
Select an answer to reveal the explanation.
Short Explanation
You want the standards path, not one-off schemas. Build MCP servers on Azure Functions or Logic Apps, front them with API Management when needed, and have agents act as MCP clients. That gives you centralized tool discovery, auth, and observability.
Full Explanation
The correct approach is implementing MCP servers (for example on Azure Functions or Logic Apps, fronted by API Management where needed) and having agents act as MCP clients for tool discovery and invocation. Building and integrating tool ecosystems includes function calling, specified and dynamic tool use, and designing MCP servers/clients on Azure compute and integration services. MCP gives a common tool surface for multi-agent solutions so inventory, ticketing, and change-management systems are discoverable, auth-bound, and observable. The approach of hard-coding REST URLs only inside each agent system prompt with no shared contract is incorrect because baking URLs into prompts is brittle, non-discoverable, and bypasses validation, versioning, and centralized policy. The approach of exposing each backend as an unmanaged public internet webhook without authentication is incorrect because public unauthenticated endpoints violate Zero Trust tool boundaries and production security requirements. The approach of training a custom embedding model so agents never need tools is incorrect because retrieval/embeddings address knowledge grounding; they do not execute transactional operations against line-of-business APIs. Also plan tool error handling, result validation, and quality checks once MCP tools are wired.