1.3.1. Model Context Protocol (MCP)
💡 First Principle: MCP moves the catalog of capabilities from build time to run time. A traditional integration freezes "what the agent can do" into a static definition when you publish it; an MCP server tells the connected agent what tools it offers during the session — so when the server adds a tool, every connected agent gains it, with no republishing.
MCP is an open protocol with a client–server shape. The server wraps a system — a ticketing platform, a database, an internal API — and exposes three kinds of capabilities: tools (operations the agent can invoke), resources (data the agent can read), and prompts (reusable prompt templates). The client — Copilot Studio, in our case — connects to the server, asks what is available, and surfaces those capabilities to the orchestrator like any other tool. Modern Copilot Studio connections use streamable HTTP transport, and the server connection is secured with the authentication the server requires (such as API keys or OAuth) — governed, like other external calls, by your environment's policies.
The run-time discovery is the strategic difference. Your platform team stands up one MCP server wrapping the order-management system; five agents across the company connect to it. When the team adds a "cancel order" tool to the server, all five agents can cancel orders — immediately, consistently, with the logic maintained in exactly one place.
⚠️ Exam Trap: "New operations should become available to the agent without republishing anything" is the MCP signature. A custom connector — the static alternative — requires updating the OpenAPI definition and republishing before agents see any change.
Reflection Question: Your company has one internal API and twelve agents that need it, and the API changes monthly. Argue the maintenance case for an MCP server over twelve copies of a custom connector.
