A Foundry agent must answer questions across dozens of Dataverse tables whose columns change every sprint. One developer proposes writing and maintaining a custom OpenAPI tool definition for each query the agent needs; another proposes connecting the agent to the Dataverse MCP server. Which reasoning favors the MCP server?

The Model Context Protocol standardizes how a client discovers and calls tools. When a Foundry agent connects to the Dataverse MCP server, it lists the available tools at run time, including tools that search and describe tables and columns and that run queries, so the model can learn the current schema and adapt as columns change without anyone editing a tool definition. A custom OpenAPI tool can also work, but every operation and schema change must be reflected in a definition the team writes, versions, and redeploys, which is the maintenance burden the scenario highlights. The MCP server does not bypass security: requests run under an authenticated identity, and Dataverse security roles determine which tables and rows that identity can reach. Foundry agents can call OpenAPI-defined tools, so saying MCP is the only possible option misstates the platform; the MCP server is preferred here for maintainability, not because alternatives are impossible. The MCP endpoint requires authentication with Microsoft Entra ID, and administrators must enable the client for the environment, so token handling and access configuration remain part of the design. Exam caveat: a bespoke tool may still be right when the agent needs a narrow, tightly controlled operation that a custom API or connector expresses better. Operational check: add a column in a development environment and confirm the agent can describe and query it without any tool definition change.