Configure MCP tools

A partner sends you one line, an HTTPS endpoint address. Twenty minutes later the agent can check account eligibility, verify an identity, look up a product and submit an application, and at no point did you open an OpenAPI file or type an operation name. That is the trade Model Context Protocol makes, and understanding what arrived on the Tools page is the difference between configuring it well and being surprised by it later.

Model Context Protocol (MCP) helps you connect to existing knowledge servers and data sources directly within Copilot Studio^[1]. Microsoft lists three kinds of thing a connected server can offer. Resources are file-like data that an agent can read for more context, such as API responses or file contents. Tools are functions that a language model can call to perform an action. Prompts are predefined prompt templates to accomplish specific tasks. Then comes the sentence that decides what you can build: Copilot Studio currently supports MCP tools and resources. The training material states the same boundary from the other side, that the MCP specification defines a third component type called prompts, but Copilot Studio doesn't currently support it^[2]. A server that publishes a beautiful prompt library gives your agent nothing extra.

Two things are called a tool, and they are not the same thing

This page is unusable without separating two senses of one word, so take them now. The MCP server tool is the single entry that appears on your agent's Tools page once the server is connected: one row, one settings page, one on/off switch. An MCP tool is one function that the server publishes, and a server publishes many. Everything you configure at the agent happens on the MCP server tool. Everything that actually runs is an MCP tool inside it, selected by the orchestrator, the component that decides at runtime which tool, topic or knowledge source a turn should use; a later section covers why that component is the only thing able to call an MCP tool at all. Microsoft's own wording makes the containment explicit: a single MCP server can integrate and manage multiple tools and resources, and Copilot Studio agents can access each tool^[1].

The product surfaces that containment in a way no other tool mechanism does. For most tools the configuration page shows Details, Inputs and Completion. For MCP servers connected as agent tools, the configuration page is different from other tool types: the Details section is similar, but instead of Inputs and Completion, there are Tools and Resources sections^[3] with information about what the server offers. If you open a tool expecting to review the inputs it collects and the response it sends afterwards and find two lists of somebody else's capabilities instead, you are looking at an MCP server, not at a broken page. The figure below sets out that anatomy: the agent, the one server tool, and the published tools and resources behind it.

Reading about a capability is not the same as having it

Because a server's capabilities arrive as a tool, they arrive through the Tools page and nowhere else. Uploading the server's documentation as a knowledge source is the near miss that looks equivalent and is not, because knowledge grounds what the agent says while tools are what it can do. An agent given only the documentation will describe an inventory service fluently and have no way to invoke any of it, so a report that the agent explains the operations but never calls them is a Tools page problem before it is anything else.

Where this page sits among its neighbours

The other pages in this part of the domain each own a different far side. Add a tool by using an existing custom connector covers wrapping a service in a Power Platform connector, Add REST APIs to an agent covers pointing the agent at endpoints described by an OpenAPI specification, and Configure and monitor computer use covers driving a graphical interface when there is no API at all. Create a multi-agent solution by using A2A protocol covers the case where the far side is another agent rather than a set of functions. This page owns the case where somebody already runs a server that publishes a collection of model-callable tools, and covers connecting it, authenticating it, controlling which of its tools your agent may use, and knowing when a different mechanism is the better answer.

One piece of vocabulary carries over from Connect to Microsoft Power Platform connectors and matters here more than it looks. A connection in Copilot Studio is a stored authentication credential for a connector, not a network link and not the server itself. MCP relies on that machinery for connectivity, which is why the governance section near the end of this page is about connectors rather than about MCP.

The Add a tool button leads to MCP twice, by two different routes, and the route you take decides how much you have to know about the server. Neither is more correct than the other; they answer different questions. Take the catalog door when an MCP connector for the service already exists in your tenant, and the wizard door when you are the one registering a server nobody has registered yet.

Door one: an MCP connector already exists

This is the shorter path, and it is the one Microsoft documents for prebuilt Microsoft MCP connectors and for any server somebody already configured. Go to the Tools page for your agent, select Add a tool, select Model Context Protocol, and a list of available MCP connectors displays. Select the MCP connector you want from the list, authorize the connection by entering any required information, and when you're done, select Add and configure^[4]. The agent adds the MCP server as a tool and opens its settings page. Microsoft notes that the process is the same whether you are adding prebuilt Microsoft MCP connectors or a server to which you configured a connection.

It is worth knowing what is already in that catalog before you build anything custom. The training material lists prebuilt MCP connectors for Microsoft services including Dataverse, Dynamics 365, Microsoft 365 Outlook, GitHub and Microsoft Teams^[2], and the same door is where the preview Work IQ MCP servers appear. Work IQ Mail is added exactly this way: select the Tools tab, select Add Tool, select Model Context Protocol, search, select Work IQ Mail, expand the connection dropdown to create a new connection, sign in, and select Add and Configure^[5]. Two cautions attach to that family. It is a preview feature requiring a Microsoft 365 Copilot license, and its servers are allowed or blocked centrally by an administrator rather than by you. Note also that Work IQ MCP is a distinct preview capability from tenant graph grounding, which is a knowledge-side feature covered on Connect to Copilot connectors; the shared word is a coincidence of branding, not a shared mechanism.

Door two: you are registering the server yourself

When no connector exists, you supply the server's identity. Go to the Tools page for your agent, select Add a tool, select New tool, then select Model Context Protocol. The MCP onboarding wizard appears. Fill in the required fields Server name, Server description, and Server URL^[6], then select the authentication type, and select Create. The Add tool dialog appears, where you create or pick a connection and select Add to agent. The figure below places the two doors side by side so the fork is visible before you are three clicks into it.

The three fields do very different jobs, and only one of them is read by the orchestrator when it decides whether to call your server. Server name is a short label that appears in the agent's Tools list; the training unit is blunt that it's for your reference and isn't surfaced to users^[7]. Server URL is the HTTPS endpoint for the server's Streamable HTTP transport (the product documentation calls the same thing the Streamable transport type; this guide uses Streamable HTTP throughout). Server description is the one that carries weight: Microsoft says to write a brief but clear description of what your MCP server does, because the agent orchestrator uses this information to identify whether to call your server at runtime. The training unit's advice is to write it as a routing rule rather than a label, and its worked contrast is instructive. "An enterprise MCP server for banking systems" gives the orchestrator little to work with; a description naming the systems covered and the question types that should reach it gives the orchestrator something to match against. You will see in a later section why this field matters disproportionately: it is very nearly the only description on this surface you are allowed to write.

Transport, and the version check to run before you type a URL

One compatibility question precedes everything else. Currently, Copilot Studio supports the Streamable transport type^[6], and given that SSE transport is deprecated, Copilot Studio no longer supports SSE for MCP after August 2025. The training unit spells out the consequence: if the server still uses SSE transport, the connection won't succeed, and the server must migrate to Streamable HTTP first. That is a conversation with the server owner, not a setting you can change, so have it before you schedule the work. One stale artifact can make you doubt the rule: the MCP troubleshooting article^[8] still carries a known-issue row written in SSE terms, about the endpoint returned in an Open SSE connection call. It predates the transport change rather than contradicting it, so treat Streamable HTTP as the only supported transport and never read that row as evidence that SSE still works.

A third route exists and is worth recognising rather than memorising. You can create a custom connector in Power Apps manually to configure a connection to the server^[6], by selecting Add a tool, New tool, then Custom connector, and importing an OpenAPI specification file that describes the server. Microsoft's sample schema marks the operation with x-ms-agentic-protocol: mcp-streamable-1.0, which is what tells the platform this connector fronts an MCP server rather than an ordinary API. Reach for this when a gateway in front of your server needs extra request parameters that the wizard has nowhere to put.

Authentication is picked while you register the server, not afterwards, and the choice is dictated by what the server supports rather than by preference. You have three options: None, API key, or OAuth 2.0^[6]. Ask the server owner which one applies before you open the wizard, because backing out of the wrong choice means editing the connector afterwards.

Authentication type	How it works	When to use it
None	The agent connects without credentials.	Fully trusted or internal servers where network-level controls are sufficient. Not appropriate for servers exposing sensitive or regulated data.
API key	Each user provides their own key on first use; the agent reuses it for the session. Credentials are user-scoped, not embedded in the configuration.	Servers requiring a secret key, where per-user credential scoping is acceptable.
OAuth 2.0	Authentication is delegated to an identity provider. Users sign in through an authorization flow and the agent receives a user-scoped token.	Production workloads requiring strong identity guarantees and integration with existing access management.

Those rows are Microsoft's own, from the training unit on configuring MCP authentication^[9], which frames the three as a trust hierarchy: None trusts the network perimeter, API key trusts the user's own secret, and OAuth 2.0 trusts the identity provider to verify who the user is.

API key: two fields, and neither of them is the key

Selecting API key reveals a Type field with values Header and Query, and a field for the name of the header or query parameter where the key should be included. Header is the more common option and is typically more secure than a query parameter; use Query only when the server's documentation requires it. The parameter name has to match exactly what the server expects, so x-api-key means x-api-key and not X-API-Key guessed from memory.

The design point behind those two fields is easy to miss and worth stating plainly, because it changes who is exposed if a key leaks. You are not embedding a credential in the configuration. The maker never sets the key value; the two fields only tell the agent where to put a key. When users interact with the agent for the first time, they are prompted to provide their own API key, and the agent uses that user-scoped key for the rest of their session. The agent does not hold a single credential that returns every user's data under one identity.

OAuth 2.0: three sub-types, chosen by what the server supports

Selecting OAuth 2.0 asks for a Type, and Microsoft publishes all three with their conditions. Dynamic discovery applies when the server supports OAuth 2.0 dynamic client registration (DCR) with a discovery mechanism, so the client uses a discovery endpoint to find the necessary endpoints and register itself with the identity provider. Dynamic applies when the server supports DCR but not the discovery mechanism, so you supply the Authorization URL and Token URL template manually while registration stays automatic. Manual applies when the server requires manual configuration, and asks for Client ID, Client secret, Authorization URL, Token URL template, Refresh URL and optionally Scopes.

The training unit turns that into a selection order worth carrying into a scenario: start with dynamic discovery if the server supports DCR with a discovery endpoint, use dynamic if it supports DCR without one, and use manual only when the identity provider does not support DCR at all. Read the stem for what the server and identity provider support, never for which option sounds most thorough. The figure below puts the three types beside each other and shows the OAuth sub-types as the order you work through rather than as a menu.

The callback URL is a step, not a notification

With the Manual sub-type a callback URL appears after you select Create, and with Dynamic one might appear depending on the configuration; it is the address the identity provider responds to with the authorization code once the user signs in and grants permissions to your agent. Copy the callback URL to add to your application's registration with your identity provider^[6]. Skipping that copy is a silent failure mode: the wizard completes, the tool appears, and the authorization flow never finishes because the identity provider has nowhere to send the code back to. Microsoft's page on building a server makes the same point from the server side, that if you use OAuth 2.0 authentication you receive a callback URL from Copilot Studio after you add the MCP server, and you need to update your app registration with your identity provider to add this URL^[10].

One consequence of the whole design is worth holding on to. Whenever a credential reaches the server at runtime, with API key or with OAuth 2.0, it is the asking user's and not a stored maker credential typed once during setup; None sends none at all. Agents that need a shared identity against a back end are a different design problem, solved on the connector side and covered on Configure actions and connectors.

Selecting Create in the wizard registers the server. It does not yet give the agent a way in. On Add tool, select Create a new connection for your MCP server or use an existing one, then select Add to agent to finish adding the MCP server to your agent^[6]. That intermediate dialog is the whole subject of this section, because it is where an authenticated server stops being a URL and becomes something the agent can call.

Microsoft's training material describes what the object is: the connection represents the authenticated link between your agent and the MCP server, and when you deploy the agent to end users, each user is typically prompted to authenticate with their own credentials the first time they invoke an MCP tool^[9]. Users provide their API key or complete the OAuth authorization flow at that point. So there are two distinct moments where credentials appear, and confusing them is the source of most surprise here: the maker authorizes a connection during setup, and each user authorizes their own access at first invocation. The figure below runs the chain from the wizard to that first successful call.

Publishing an agent does not create or renew a connection

Publishing makes the agent's current content live on its channels. It has no effect on whether a stored credential is valid. An agent republished daily against an MCP server whose connection has expired fails identically every day, and an agent that was never given a connection at all does not acquire one at publish time. When a scenario tells you that the maker completed the wizard, published, and users still cannot reach the server's tools, the missing step is in the Add tool dialog, not in the release process.

The same reasoning explains the most common decay pattern, which is a server that worked for months and then stopped for everybody at once. Nothing about the agent changed, and the server's tools are fine. What expired is the credential behind the connection. The remedy is to reconnect or re-authorize, not to remove and re-add the server, and certainly not to rebuild the agent. Copilot Studio surfaces connection health with a small set of published status values, and those values, along with the difference between a connection and a connection reference, belong to Configure actions and connectors; everything that page says about diagnosing a connector connection applies unchanged to an MCP one, because underneath it is the same object.

What to check, in order

When an MCP server tool that used to work stops working, three checks separate the causes quickly. First, is the connection still valid, or has its credential expired or been removed in the maker portal? Second, has a data policy in the environment changed, which the governance section below covers and which blocks the connector rather than breaking it? Third, has the server itself changed, which Copilot Studio reflects automatically and which therefore tends to show up as tools appearing or disappearing rather than as a uniform failure. A failure that hits every user at once and every tool at once is nearly always the first or the second; a failure confined to one tool is nearly always the third.

Microsoft states the prerequisite in a one-line note on the MCP overview page: you must turn on generative orchestration to use MCP^[1]. That single sentence has more consequences than any other fact on this page, because generative orchestration is not merely recommended for MCP, it is the only caller.

Start with what generative orchestration is, since the rest is a deduction from it. With generative orchestration, active by default, your agent can automatically select the most appropriate tool or topic, or search across knowledge, to respond to a user^[3]. The alternative is classic mode: with generative orchestration turned off, an agent can only use topics to respond to the user, though you can still design your agent to call tools explicitly from within topics. For a connector tool or a REST API tool, that second clause is a genuine escape hatch. For MCP it is not, because the training material closes it: topics can't call MCP servers, and only generative orchestration can invoke MCP tools^[2], which Microsoft describes as a current, known limitation of the MCP implementation in Copilot Studio.

What that removes

Add tools to a topic teaches three placements for an ordinary tool: an agent-level tool the orchestrator may select, an agent-level tool with dynamic use cleared so it runs only when a topic calls it, and a topic-level tool created on the canvas. MCP has one of the three. There is no call site for an MCP tool, meaning no canvas position where the authored conversation hands control to it at a step you chose, because the mechanism that would place one does not reach MCP servers. The figure below shows the one live path and the row you have to move to when a requirement needs the other one.

So a compliance requirement phrased as "this server's tools must run only inside an approved topic, at a step we control" cannot be satisfied by configuration on an MCP server. It is a requirement for a different mechanism, and the honest answer to that scenario is to expose the operation through a connector tool or a REST API tool that a topic can invoke as an Action node. Recognising an unsatisfiable requirement is worth as much here as knowing a setting.

The same fact read backwards explains a failure that looks like a bug. An agent that was working, switched to classic mode so its support topics trigger on exact phrases again, and then stopped calling its MCP server has not lost its connection and has not had its tools disabled. It has lost the only component that could invoke them. The server still appears on the Tools page, its tools still list, and nothing will call any of them until generative orchestration is back on. Equally, a maker who cannot set orchestration to generative in a given environment cannot build an MCP-backed agent there, however correct the rest of the configuration is.

Description quality is the whole selection mechanism

When the orchestrator is the only caller, the tool's description stops being documentation and becomes the invocation logic. Microsoft lists what the agent weighs when picking a tool: the tool's name and description, the current conversation context, user intent derived from their message, available inputs and outputs, and previous tool usage in the conversation^[3]. Two MCP tools whose descriptions overlap are two tools the orchestrator will sometimes confuse, and an MCP server tool described as "this tool can answer questions", Microsoft's own example of a description that is too vague, competes with the agent's knowledge sources on almost anything a user asks. The next section covers why you usually cannot fix that from inside Copilot Studio.

Everything the agent knows about an MCP tool was written by somebody else. The server provides the name, description, inputs, and outputs. When you update or remove tools and resources on the MCP server, Copilot Studio dynamically reflects these changes. This process ensures users always have the latest versions and removes obsolete tools and resources^[1]. That is MCP's headline benefit and its sharpest constraint in the same sentence, and the two are inseparable.

The benefit is real and it is what justifies the mechanism. The training material describes the effect at organisational scale: when the MCP server owner updates a tool or resource, such as changing a description, adding a parameter, or deprecating a function, Copilot Studio reflects those changes automatically across every connected agent, with no per-agent updates or republication required^[2]. Compare that with a set of REST API tools built from an OpenAPI file: every one of those has to be revisited in every agent when the API changes.

What you may not edit

The constraint is the flip side. MCP tool descriptions are set on the server and can't be edited within Copilot Studio: what the server owner wrote is what the orchestrator reads, and when reviewing a connected MCP server's tools, every description is read-only^[11]. If a description is insufficient, the only remediation path is to work with the MCP server owner to update it on the server side; there is no way to override or supplement tool descriptions from within Copilot Studio.

That turns a piece of due diligence into a real step in the build. Before you connect a server for production use, read its tool descriptions and ask whether they are specific enough for the orchestrator to distinguish between them, because after connection you own the behaviour and not the text that drives it. The lever that remains yours is the Server description from the wizard, which is why the earlier section insisted on treating it as a routing rule. The figure below shows both halves of the loop: the server owner's edit propagating, and the orchestrator reading a description you cannot touch.

Answering the question the metadata exists to answer

The practical use of all this is discovery. A maker who inherits an agent with a connected server and no documentation does not have to ask the previous author what the agent can do. Go to the Tools tab for your agent and select the MCP server from the list of tools^[4]; the settings page shows a Tools section listing names and descriptions for the MCP tools the server offers, and a Resources section listing names and descriptions for a sampling of the resources. Both lists are generated from the server rather than from anyone's notes, which is what makes them the inventory to trust. Note the word sampling on the resources side: the list is illustrative rather than a complete inventory.

When the count does not match

A specific and confusing symptom follows from server-owned metadata, and it is one of the few places where the MCP surface has published known issues. The server's developers say it publishes eight tools; the Tools section shows six. Nothing is wrong with the connection. Microsoft's troubleshooting article records that tools with reference type inputs in the schema are filtered from the list of available tools for MCP server, and reference type inputs and outputs aren't supported^[8]. Three related schema issues sit on the same list: an input schema is truncated when a type in a tool definition is an array of multiple types instead of a single type, with the workaround being to make the values for type fields a single type; a System.FormatException is thrown when the exclusiveMinimum property is set to an integer instead of a Boolean; and tools with enum type inputs are interpreted as string instead of enum.

Microsoft publishes those as known issues the product team is working on, but every one of them is triggered by the server's tool definitions, and every fix belongs to the server owner. That is the pattern to carry away from this whole section. When the metadata is wrong, incomplete, or ambiguous, the work is on the server. Your side of the boundary holds the server description, the authentication choice, and which of the published tools you allow.

One sizing note belongs here rather than in a limits table, because it affects how many servers you connect. Microsoft bounds the orchestrator's working set: when using generative orchestration, the orchestrator can handle a maximum of 128 tools per agent, and for best performance and results we recommend limiting the number of tools in your agent to no more than 25 to 30^[3]. 128 is a hard maximum and 25 to 30 is a recommendation, and they are not interchangeable. A server publishing thirty tools consumes that budget on its own, which is the strongest practical argument for the selective enablement the next section covers.

The Resources section on a server's settings page reads like a menu and behaves like a catalog. Seeing a product specification, a compliance certificate or a safety datasheet listed there tells you the server publishes it. It does not tell you the agent can get at it.

Microsoft flags the rule as an Important note rather than burying it: for Copilot Studio agents to use a resource, the MCP server owner needs to configure the resource as an output of one of the MCP tools on the server^[4]. The training unit gives the mechanism behind the rule: resources differ from tools in an important way, in that they aren't independently callable by the agent, and the resource becomes available when the relevant tool returns it as part of its response^[11]. So a resource has no address of its own from the agent's point of view. It arrives as cargo. The figure below traces that route.

Three symptoms with one cause

That single fact explains three situations that otherwise look unrelated, which is a good sign it is the right model to hold.

A maker writes agent instructions that name a listed resource explicitly and the agent never uses it. The instructions are not the problem and neither is the wording; if no tool on the server returns that resource, no instruction can reach it. The remedy is a request to the server owner to expose it as a tool output, and Microsoft points to a reference implementation^[4] for owners who need to see how.

A vendor confirms in writing that a datasheet will not be returned as the output of any tool. That answer settles the design question immediately: the resource is unreachable through MCP, and if the agent genuinely needs that content, it needs a knowledge source instead. Resources are context an MCP tool hands back, not an indexed corpus, and the knowledge-source mechanisms are covered on Connect to Microsoft Power Platform connectors and its neighbours.

An agent stops including a document in its answers after a governance review turned off most of the server's tools. Nothing about resources was changed and nothing about resources needed to be. The tool that carried the resource is off, so the resource stopped arriving. The fix is to re-enable that specific tool, which means the review has to be conducted on what each tool returns, not only on what each tool does.

A server owner's design note, for the reader who is also the owner

When your own team is building the server, this rule shapes the design rather than merely constraining it. A library of reference documents published only as resources gives connected Copilot Studio agents nothing. The same library published as resources that a retrieval tool returns as its output is usable immediately, without any change on the agent side. If the plan is for agents to use documents as context in their answers, the deliverable is a tool that returns them.

Connecting a server hands the agent everything the server publishes. All tools are turned on by default when you add an MCP server; the Allow all toggle is turned on^[4]. For a purpose-built agent that is rarely what you want, and narrowing the set is a two-step operation: turn off the Allow all toggle so that toggles become available for each of the individual tools, then use the individual toggles to turn off tools that aren't needed, so your agent only uses the most relevant features.

Two arguments favour narrowing, and they are different arguments. The training material names both: orchestration ambiguity^[11], because the orchestrator evaluates the descriptions of every available tool when selecting one, so a larger candidate pool raises the chance of an unintended selection; and least privilege, because an agent should only have access to the capabilities it genuinely needs. An account-opening agent with access to ledger reconciliation and loan modification has a governance problem even if it never picks them.

The part that is a decision about the future

The toggle's second effect is the one questions are built on, because it applies to tools nobody has seen yet. When you turn off Allow all, any new tools added to the MCP server are turned off by default^[4]. Leaving Allow all on means the opposite: new tools are automatically enabled for the agent as soon as the server publishes them. The figure below sets the two branches side by side with what each one buys.

Allow all	Behaviour when the server publishes new tools	What you are trading
On	New tools are automatically enabled for the agent as soon as the server publishes them.	Convenience: the agent gains capabilities with no maker action. Appropriate when the server is trusted and its tools are expected to be relevant.
Off	New tools appear in the list but remain disabled until a maker explicitly reviews and enables them.	Control: full authority over what the agent can invoke at any moment, at the cost of ongoing awareness of server updates.

Microsoft is explicit that neither setting is universally correct and that the right choice depends on the organisation's governance posture and the trust established with the server owner. Read a scenario for which of the two properties it demands. "Any tool the server adds must be reviewed before the agent can use it" is a requirement for Allow all off. "The agent should pick up whatever the platform team ships" is a requirement for leaving it on. And notice the trap in the middle: a team that turned Allow all off six months ago and now wonders why two newly published, tested tools are not being used is seeing the setting work exactly as designed. The tools are there and off; somebody has to turn them on.

Turning off the server without disconnecting it

Selective enablement is per tool. There is also a switch that covers everything the server publishes, and it is not MCP-specific: it is the ordinary tool switch every agent tool has. Go to the Tools page for your agent, select the tool, and at the top of the configuration page turn off the tool using the Enabled toggle, then select Save. Turning off a tool blocks the agent from using the tool, but the tool is still connected to the agent and can be turned back on later^[3].

That is the answer to the incident scenario. When a vendor reports a data-quality problem and the agent must stop calling anything on that server while the rest of it keeps serving users, turning off the MCP server tool stops every tool inside it in one action, leaves the connection and the configuration intact, and touches no other tool, topic or knowledge source. Deleting the tool also stops the calls, and it throws away the connection and the enablement decisions you would have to rebuild afterwards; Microsoft keeps Delete as the separate, permanent option for exactly that reason. Prefer the reversible switch during an incident and reserve deletion for a decision you have already made.

Governance of MCP is not an MCP feature. Microsoft publishes the same paragraph on both MCP articles, and it is short enough to memorise: access to MCP servers in Copilot Studio relies on Power Platform connectors for connectivity. This condition means that if a data policy regulates Power Platform connectors, it also regulates access to the MCP server and its tools for your agent^[4].

Read the first sentence as the mechanism and the second as its consequence. The MCP server tool reaches the outside world through the same connector infrastructure a Salesforce or SharePoint tool uses, so it inherits every control that applies to connectors. Nobody writes an MCP-specific rule, and nobody needs to.

This has a very practical shape at build time. A certified MCP connector can appear in the catalog for every maker in the tenant and still be unusable in one environment, because a data policy there classifies it in a way that blocks it. The maker can select the connector, the wizard behaves, and the failure surfaces as a policy error rather than a connection error. The same mechanism is the durable way to stop makers across an entire environment from wiring one specific external server into their agents: block the connector by policy, once, centrally, rather than asking each maker not to use it.

How a data policy is authored, how it classifies connectors into groups, and the two moments it binds are taught on Evaluate security and governance considerations; this page does not repeat them. Two points from that material are worth carrying across the seam because they change what you would answer here. Copilot Studio's data policy enforcement exemption is no longer supported^[12], so an agent that was published before a policy changed is not grandfathered against it. And a policy that blocks a connector blocks it for the agent regardless of which tool mechanism sits on top, which is why an MCP server tool and an ordinary connector tool fail the same way for the same reason.

One family sits partly outside this pattern and it is worth one sentence so it does not confuse a scenario. Work IQ MCP servers, and MCP servers registered through Agents 365, are additionally allowed or blocked by an administrator in the Microsoft 365 admin center. That is administrator work rather than maker work, so treat it as context for why a server you can see is unavailable, not as a control you are expected to operate.

By the time you are deciding, the question is no longer "can MCP do this". It usually can. The question is whether the shape of the far side justifies the shape of MCP, and Microsoft supplies a routing table that answers most of it in one line each. The A2A article publishes it as recommended approaches by integration need: connect to APIs or basic HTTP services with custom connectors or HTTP tools; use MCP tools or resources with MCP servers; integrate agents built with Microsoft 365 Agents SDK with the Activity Protocol^[13]. Start there, then use the rest of this section for the cases where a scenario is written to make the wrong option attractive.

When MCP earns its place

MCP's distinguishing property is central definition with automatic propagation, and it pays off in proportion to how many agents share the far side and how often it changes. The training material's selection list is explicit: use MCP when multiple agents in your organization need access to the same set of tools, when an enterprise or platform team manages a centralized tool registry and owns the server, when you want tool updates to propagate to all consuming agents automatically, or when a prebuilt Microsoft MCP connector covers the service you need^[2].

The same list names the cases where it is the wrong call: only one agent needs the integration, so the added structure of an MCP server isn't justified for a single consumer; you need fine-grained control over each action's description, which makers can't edit for MCP tools; a topic needs to invoke the integration directly, which MCP cannot do; or the server's existing tool descriptions aren't precise enough for reliable orchestration^[2].

There is a scenario shape built directly on the first of those and it is worth recognising because the intuitive answer is wrong. An agent carries eleven separate REST API tools, each built from a small OpenAPI file describing one operation of the same internal platform, and every platform release forces a round of edits across all eleven. That is not an argument for building an MCP server on the spot; it is an argument for asking whether the platform team already runs one or is willing to. MCP fixes that maintenance problem only when somebody owns the server, and the ownership is the cost. Where the platform team will own it, one connected server replaces eleven imports and the eleven follow-up edits, because a single MCP server can integrate and manage multiple tools and resources^[1] and changes propagate on their own.

MCP against REST tools and custom connectors

When the far side is one conventional API described by an OpenAPI specification, MCP is the wrong door and the reason is not capability. A REST API tool or a custom connector is defined for the API you have, the maker writes the descriptions, and the tool can be invoked from a topic at an authored step. Those are exactly the three properties MCP gives away. The mechanics of both alternatives are covered on Add REST APIs to an agent and Add a tool by using an existing custom connector; the choice between them turns on whether the connection has to be reusable and governable as a Power Platform artifact.

One discriminator settles a whole class of stems quickly. If the requirement includes per-user authorization against an API where each employee must reach only their own records, that is an authentication design question and both mechanisms can carry a user-scoped token, so it does not by itself select MCP. If the requirement includes "a topic must call it at this step", MCP is eliminated outright. If the requirement includes "the change board must approve every operation the agent can perform", both work, but the enablement story differs: with MCP you approve by toggling published tools, with REST you approve by choosing which endpoints to import in the first place.

MCP against A2A

The last comparison is the one that most often goes wrong, because both mechanisms let an agent reach something clever on the far side. The difference is what crosses the boundary. Microsoft's own contrast for A2A is that the protocol defines a standard contract for agent communication, enabling an orchestrator or agent to send tasks to external agents, provide rich structured metadata, and receive agent responses in a predictable format^[13], and it draws the conclusion in one line: by using A2A, Copilot Studio can delegate tasks to another agent, not just call APIs. The published payload description makes the difference concrete, listing a unique contextId, message IDs, locale information, and the full chat history rather than just the latest user utterance.

An MCP tool call carries its typed inputs and returns its typed output. That is a transaction. If the far side is a specialist agent that holds its own reasoning and needs the conversation so far to do its job, wrapping it in a stateless MCP tool discards precisely the thing that made it worth calling, and the symptom is a reviewer complaining that the external agent keeps asking for context the user already gave. Copilot Studio also treats the two as different objects in the product: connected agents appear on the Agents page and are added with Add an agent, while MCP servers appear on the Tools page. Create a multi-agent solution by using A2A protocol and Design multi-agent solutions in Copilot Studio cover that side in full.

The short form, for a stem you have thirty seconds to read: a collection of functions somebody publishes and maintains is MCP; one API you are integrating yourself is a REST tool or a custom connector; an agent that reasons and needs the conversation is A2A.

Scenarios on this objective are written to be settled by one fact, and the skill is finding which fact the stem is actually about. Five patterns cover most of them.

The prerequisite pattern

Anything describing an agent that stops calling its MCP server, or a maker who cannot use MCP in an environment, is usually testing the orchestration prerequisite. Generative orchestration is required, topics cannot call MCP servers, and there is no configuration on the MCP side that restores an authored, step-controlled invocation. Distractors here offer plausible repairs: re-authorize the connection, re-add the server, edit the tool description, add a trigger phrase. Each of those is a real action somewhere else on this surface, which is what makes them attractive. If the stem mentions classic mode, exact-phrase topics, or an environment where orchestration cannot be set to generative, stop reading the other options.

The metadata-ownership pattern

Stems about discovering what a server can do, about an orchestrator picking the wrong one of two similar tools, or about a tool count that does not match what the developers promised, all resolve to server-owned metadata. The Tools and Resources sections on the server's settings page are the authoritative inventory. Descriptions are read-only, so any answer that says to rewrite an MCP tool's description in Copilot Studio is wrong on its face; the two legitimate answers are to work with the server owner or to sharpen the server description you do own. A missing tool usually points at the published schema limitations, a reference-type input above all, rather than at the connection.

The resource pattern

Any stem where a resource is listed but never used is the same question in different clothes. Resources are not independently callable, so the resolution is always that a tool must return the resource as its output. Watch for the variant where a governance review disabled tools and a document silently disappeared from answers; the reader who knows that resources travel as tool output gets there immediately, and the reader who does not looks for a knowledge-source setting that does not exist.

The enablement pattern

Allow all questions are almost always about the future rather than the present. Read for whether the requirement is "new tools must be reviewed first", which means turning Allow all off, or "the agent should pick up whatever the server adds", which means leaving it on. The trap variant tells you the toggle was turned off months ago and that two new tools are now being ignored; nothing is broken and the answer is to enable them. A neighbouring variant asks how to stop the agent calling a server during an incident without disturbing anything else, and the answer is the Enabled toggle on the MCP server tool rather than deleting it or unpublishing the agent.

The mechanism-selection pattern

The longest stems are usually the easiest, because they describe the far side in enough detail to classify it. Sort on three questions in order. Is somebody else publishing and maintaining a collection of model-callable tools? That is MCP. Is this one API, described by an OpenAPI specification, that only this agent needs? That is a REST API tool or a custom connector. Is the far side an agent with its own reasoning that needs the conversation so far? That is A2A. A governance requirement about blocking a server across an environment is a fourth variant of the same pattern and resolves to the data policy on the Power Platform connector, not to any per-agent setting.

One last habit is worth building, because it catches wrong answers in several patterns at once. Ask which side of the boundary the proposed fix sits on. Editing a tool description, adding a resource, changing a schema and migrating a transport are all server-side work. Choosing the authentication type, writing the server description, deciding Allow all, enabling individual tools, and turning the server tool off are all agent-side work. An option that quietly puts server-side work in the maker's hands is usually the distractor.