An internal inventory API must be usable as tools by agents built in Microsoft Copilot Studio and by agents built in Microsoft Foundry. The team wants agents to discover the available operations and their inputs through a standard protocol rather than custom integration code in each agent. What should the team design?
Select an answer to reveal the explanation.
Short Explanation
Think of an MCP server as a menu posted on the restaurant door: any agent that walks up can read what's offered and how to order it. Build the tools once and both your Copilot Studio and Foundry agents can use them. The trap is dumping the API spec into knowledge, which lets an agent read about the API but not call it.
Full Explanation
Model Context Protocol is an open protocol for exposing tools and resources to AI agents. An MCP server publishes a list of tools, each with a name, a description and an input schema, and agents that support MCP can discover those tools at run time and invoke them with structured arguments. Copilot Studio agents can connect to MCP servers as tools, and Foundry agents can use MCP tools as well, so one server gives both platforms the same capabilities without bespoke integration code in each agent. Placing an OpenAPI document in a knowledge source only makes the text available for retrieval; knowledge grounds answers but does not create callable actions, so the agent cannot execute operations that way. A PCF code component is a user-interface control inside an app; agents do not call PCF components. A virtual table could surface inventory rows as data, but it is read-oriented, depends on a data provider for that API, and does not expose the API's operations, such as reserving stock, as tools. Exam caveat: custom connectors remain the standard design for apps and flows; MCP fits when the consumers are agents across platforms. Operational check: connect the MCP server to a test agent in each platform and confirm the tool list, descriptions and input schemas appear as expected.