2.2.2. MCP Tools
💡 First Principle: Adding an MCP server to an agent is subscribing to a stream of capabilities rather than importing a snapshot of them. The server tells the connected agent what tools it currently offers; when the server's toolset grows, so does the agent's — no republish, no redeploy.
Phase 1 covered the protocol; here is the product surface. In Copilot Studio you add an MCP server as a tool, connecting over streamable HTTP with the authentication the server requires. Once connected, the server's tools appear to the orchestrator alongside every other tool, described by the server itself — which means tool descriptions are authored once, at the server, and stay consistent across every agent in the company that connects.
That centralization is the strategic argument the exam looks for. One platform team maintains the MCP server that wraps the order-management API; a dozen agents across departments connect to it; a new "cancel order" capability ships server-side and is instantly everywhere, with uniform behavior and one place to fix bugs. Compare that to a custom connector, where the same change means updating an OpenAPI definition, republishing, and hoping every consuming agent picks it up.
Governance still applies — MCP connections ride the same connector infrastructure, so DLP policies and admin controls can allow or block them like any other connection. Dynamic does not mean ungoverned.
⚠️ Exam Trap: The MCP signature phrase is "tools should become available to agents automatically as they're added." If the scenario emphasizes automatic propagation of new operations without republishing, MCP beats custom connectors every time.
Reflection Question: Your company's integration team debates wrapping a fast-evolving internal API as either one MCP server or per-team custom connectors. What breaks — organizationally, not just technically — under the connector approach as the API adds operations monthly?
