Add an MCP Tool in Copilot Studio (Maker Walkthrough) | elijah.ai
Makers, Microsoft-hosted: Part 2 of 5. Previous: OAuth for custom connectors. Next: Dataverse identity. Series: 1 · 2 · 3 · 4 · 5

Add an MCP Tool in Copilot Studio (Maker Walkthrough)

Why this exists: You finally have (or will have) a custom connector that speaks MCP, the Model Context Protocol. That is the “agent can call my backend in a standard shape” story. Copilot Studio still needs a boring thing from you: a working connection and a clear choice about whose identity runs the call.

For you if: You are the maker standing in Studio clicking Add tool, not the person writing the MCP server from scratch.

Before you start: If OAuth still feels fuzzy, read Part 1 once. It saves you from guessing about delegated vs app-only.

What you are actually wiring

In plain terms: your agent wants to call an action. That action lives behind a connector definition. The connector needs a connection (tokens, consents, all the fun). Studio’s job is to decide when to invoke the tool. Your job is to make sure the connection matches how your API expects to be called.

Microsoft-hosted assumption: your connector points at an HTTPS API in the cloud. Same world as the rest of your tenant.

Maker-provided vs end user

Studio will ask who owns the credential. This is not cosmetic.

  • Maker-provided. You pin one connection. Every user of the agent hits the same backend identity (often paired with client credentials in the connector layer). Predictable. Great for org-wide lookups that are not personal.
  • End user (or similar). The caller’s context matters. Each person brings their own token path. Better when the tool reads “my email” or “rows I am allowed to see.”

If you pick maker-provided and your API still checks individual file ACLs, you will get weird “it works for me in Test” behavior. Match the pattern to the data model.

Steps that consistently work

  1. In Copilot Studio, open your agent.
  2. Add a tool from an existing connector that your environment already knows (browse MCP servers or connectors your admin published depending on your org’s setup).
  3. Select or create the connection. If Test never worked in Power Apps, stop here and fix that first.
  4. Set credentials to Maker provided when you want a shared line, or the user-based option when the tool should respect each person’s access.
  5. Save, publish if your process requires it, then run a small prompt that forces the tool (do not trust small talk prompts that the model can answer without the tool).

Extension that shows up in real posts: x-ms-agentic-protocol

If your team edits OpenAPI for MCP streaming compatibility, you might see an extension like mcp-streamable-1.0. In human language: it tells Microsoft’s agent stack “this connector is not pretending to be a random REST toy; it participates in the agent protocol.” You do not need to memorize the spec. You do need to know that if someone strips that extension during an export/import, discovery breaks in quiet ways.

Checklist before you blame the agent

  • Connector saved and (if required) shared with your environment.
  • Connection created in the same environment as the agent.
  • Tool enabled on the topics or orchestration path you think you are testing.
  • You published after changes. Unpublished agents love to waste time.

When you need an admin (say it clearly)

Bring them a sentence, not a vibe.

  • “DLP blocks this endpoint” or connector policy forbids the connection type.
  • Tenant requires admin consent for the API permission you added.
  • Service principal setup is incomplete and you cannot grant app roles yourself.

What to read next

Tool calls Dataverse? Part 3. Tool calls a flow? Part 4. Pure pain on auth codes? Part 5.

Microsoft sources

From elijah.ai. For people who ship agents, not slide decks.