A platform team wants specialist agents in Microsoft Foundry to discover and call a shared set of internal operations (inventory lookup, price quote, order status) through a standardized protocol rather than each agent embedding its own HTTP client and schema. Operations already run as Azure Functions behind Azure API Management. Which design best exposes these operations for multi-agent consumption?

The best design is to implement a Model Context Protocol server that surfaces the Azure Functions and Azure API Management operations as tools with typed schemas, and register Model Context Protocol clients in the agents that need them. Building and integrating tool ecosystems for multi-agent solutions includes designing MCP servers and clients, including exposures backed by Azure Functions, Azure Logic Apps, and Azure API Management. An MCP server presents stable, typed tools; agents act as MCP clients and call those tools without each reimplementing transport and schema logic.

Hard-coding REST URLs and ad-hoc JSON schemas into every agent's system prompt is incorrect because it produces inconsistent calling conventions, poor validation, and high maintenance cost as APIs evolve. Storing the function source code inside each agent's long-term memory is incorrect because long-term memory is not a secure or appropriate vehicle for executable service source code, and agents should call governed tools rather than reimplement backends. Replacing the Azure Functions with a single monolithic chat completion that pretends to perform inventory, pricing, and status updates is incorrect because it loses transactional correctness, auditability, and integration with inventory and order systems of record.

Exam caveat: prefer MCP or equivalent governed tool surfaces for shared multi-agent tool access over prompt-embedded HTTP hacks.