Connecting Microsoft Copilot Studio

Microsoft Copilot Studio supports MCP servers, but it does not connect to them the same way an MCP-native client (Claude Desktop, Claude Code, Cursor, etc.) does. Copilot Studio reaches a remote MCP server through a Power Platform custom connector, and Power Platform’s “Generic OAuth 2.0” connector type does not implement MCP’s OAuth 2.1 + PKCE flow. That means the standard sign-in path documented in Connecting an AI client doesn’t apply here.

Instead, Copilot Studio connects to Conduit as a service client, authenticated with an agent key: a static, long-lived bearer your organization mints against that client, pastes into the connector once, and can rotate or revoke at any time. This guide walks the end-to-end setup.

You do not install Conduit. You configure a Power Platform custom connector that points at your organization’s Conduit endpoint, attach it to a Copilot Studio agent, and authorize a connection once per end user.

Before you start

You need:

An active Conduit subscription. Conduit is single-plan — there’s no separate tier to confirm, just billing in good standing.
Org-admin role on Conduit. Required to mint a service client and its agent key.
A Microsoft Power Platform environment with maker rights, and access to Copilot Studio (copilotstudio.microsoft.com) in that environment.
Your Conduit MCP endpoint URL — https://conduit.wyre.ai/v1/mcp. The /v1/mcp endpoint is the unified endpoint: it exposes every vendor your organization has connected, behind one URL.

Step 1 — Mint a service client on Conduit

Sign in to your Conduit dashboard and open Org settings → Service clients. Click Create, give the client a recognizable name (for example, Copilot Studio Test), and click Create.

The dashboard shows the client ID (svc_…) and the client secret exactly once. Copy the client ID — Step 3 mints the connector’s credential against it. The connector never uses the secret; copy it too if you’ll drive the client_credentials grant from somewhere else, because it is hashed at rest and cannot be retrieved later.

Scope the client before you go further. A new service client picks up each vendor’s Everyone default, so with permissive defaults it can reach more than you intend — add it to a team, or give it an override in the vendor’s Access editor. See Managing access.

Step 2 — Build the Power Apps custom connector

Open make.powerapps.com in the target environment → Custom connectors → + New custom connector → Create from blank. Name it Conduit (or a name of your choosing).

On the General tab:

Scheme: HTTPS
Host: the hostname of your Conduit MCP endpoint, https://conduit.wyre.ai/v1/mcp, without https:// or the path
Base URL: /

On the Definition tab, add a single POST operation:

Summary / operation ID: InvokeMCP
URL: /v1/mcp
Add the Microsoft MCP extension to the operation: switch to the Swagger editor toggle and set x-ms-agentic-protocol: mcp-streamable-1.0 on the operation. This tells Copilot Studio to treat the endpoint as an MCP server (negotiate initialize / tools/list / tools/call dynamically).

On the Security tab:

Field	Value
Authentication type	API Key
Parameter label	`Bearer token`
Parameter name	`Authorization`
Parameter location	Header

Click Create connector at the top right.

Step 3 — Mint an agent key and create a connection

The custom connector needs a value for the Authorization header, and Power Platform stores whatever you paste verbatim — it never refreshes a stored credential. So the value to paste is an agent key: a static bearer bound to the service client from Step 1, which Conduit accepts on /v1/mcp directly. It has no hourly clock, so there is nothing to re-paste on a schedule.

An org admin mints one against the service client:

POST /api/orgs/<org-id>/service-clients/<client-id>/agent-key

The 201 response carries the key:

{
  "agent_key": "cak_a4f9b27c1e05_…",
  "prefix": "cak_a4f9b27c1e05",
  "rotated": false
}

Copy agent_key immediately — it is shown once, only its hash is stored, and it cannot be read back. prefix is the key’s public lookup handle, safe to record so you can tell which key a connection is holding. rotated is false on a first mint and true when the call replaced an existing key.

Back in make.powerapps.com:

Open the connector you just created → Test tab → + New connection.
In the Bearer token field, paste Bearer cak_… — the literal word Bearer, a space, then the agent key.
Click Create. The connection status flips to Connected.

Smoke-test the connection from the Test tab → operation InvokeMCP → request body:

{"jsonrpc":"2.0","id":1,"method":"tools/list"}

Click Test operation. A successful response is HTTP 200 with a JSON body containing a result.tools array — your organization’s connected vendor tools.

Step 4 — Add the connector to a Copilot Studio agent

Open copilotstudio.microsoft.com in the same environment, open (or create) your agent, and on the Overview tab scroll to Tools → + Add a tool.

In the picker, search for your connector name (e.g. Conduit). Select the action, confirm the connection, and click Add. The tool appears under the agent’s Tools section labeled Model Context Protocol.

The first time an end user asks the agent to use a Conduit tool, Copilot Studio will reply with “Let’s get you connected first” and a link to the connection manager. The user clicks the link, selects the existing Connection, and submits. This is a one-time consent step per end user, separate from the maker-side connection you created in Step 3.

After consent, retry the request. The agent picks the right MCP tool, Conduit proxies it to the vendor, and the response comes back inline.

Important limits and considerations

Copilot Studio caps tools at 70 per MCP server, per agent

When Copilot Studio calls tools/list against an MCP server, it applies a hard cap of 70 tools per server, per agent. If Conduit surfaces more than 70 tools (the unified /v1/mcp endpoint exposes every connected vendor’s tools), only the first 70 are visible to the agent’s tool-selection pass. Copilot Studio surfaces this in the trace panel as reasonCode: "LimitTools".

If you need access to more tools from one agent, the cleanest pattern is per-vendor connectors pointing at Conduit’s per-vendor endpoint:

/v1/<vendor>/mcp

For example, point one connector at /v1/autotask/mcp and another at /v1/halopsa/mcp. Each vendor MCP surface is comfortably under 70 tools, and Copilot Studio sees both connectors as separate MCP servers with separate 70-tool budgets. Alternatively, shard responsibilities across multiple agents.

The agent key doesn’t expire hourly — but it is a long-lived secret

This is why the connector carries an agent key rather than a client_credentials access token. That token is valid for 3600 seconds, and because Power Platform stores it verbatim and never refreshes it, every invocation through the connection returns HTTP 401 an hour after you paste it. An agent key has no such clock: no scheduled re-paste, no token-broker service to build. (A connection created before agent keys existed still holds an access token and still 401s — replace its value with an agent key.)

The trade-off: the connection record now holds a static, long-lived secret. Handle it accordingly.

Scope the service client. The key resolves to that client’s own identity (svc:<org-id>:<client-id>), so the connector reaches exactly what the client’s team grants and Access-editor overrides allow — no more, no less.
Rotate in place. Calling the mint endpoint again issues a new key and invalidates the previous one, keeping the same identity and every grant attached to it. Update the Power Platform connection with the new value.
Revoke immediately. DELETE /api/orgs/<org-id>/service-clients/<client-id>/agent-key kills the key at once and leaves the service client intact; revoking the client itself takes the key with it. A key can never outlive the service client’s own expiry either.

The service client is per-organization

A service client is scoped to the org that created it. Its agent key — like any token minted with its secret — carries that org’s identity (sub: svc:<org-id>:<client-id>) and surfaces only that org’s connected vendors. You cannot share one service client across organizations.

Troubleshooting

Symptom	Likely cause
Minting the key returns 404 Service client not found	The client ID isn’t in that org, or the client was revoked. Re-copy the ID from the dashboard.
`tools/list` returns 401 Unauthorized	The key was revoked, or replaced by a rotation, or the service client expired — mint a key and update the connection with the new `Bearer cak_…`. A connection still holding a one-hour `client_credentials` access token 401s the same way; switch it to an agent key.
Agent says “Let’s get you connected first” every turn	Per-end-user consent wasn’t completed. Open the linked connection manager, pick the connection, submit.
Agent only sees a subset of expected tools	The 70-tool cap is in effect. Switch to per-vendor connectors at `/v1/<vendor>/mcp`.
Connector creation rejects the OpenAPI	Make sure the operation has `x-ms-agentic-protocol: mcp-streamable-1.0` (Swagger editor toggle) and the spec is Swagger 2.0, not OpenAPI 3.
Tool call returns a permissions error from a vendor	The service client inherits the org’s vendor configuration. Confirm the vendor is connected on Conduit and reachable from it.

Frequently asked questions

Can I use OAuth 2.1 + PKCE like Claude does?

Not through Power Platform’s Generic OAuth 2.0 today. Copilot Studio’s custom-connector framework does not send PKCE, so Conduit’s authorization endpoint rejects the request. The service-client (API Key) path is the supported route.

Why is the auth a “Bearer token” pasted into an API Key field?

Power Platform’s API Key auth type lets the connector author choose any header. We use Authorization: Bearer <agent key> so Conduit treats it as a standard MCP bearer. The value is an agent key, not an OAuth access token — which is the point: the connector framework never refreshes a stored credential, and an agent key needs no refreshing.

Do I need a separate service client per agent?

No. One service client can back as many connectors as you want — including per-vendor connectors. Choose per-agent or per-vendor scoping based on how you want to revoke independently.

Can end users see other end users’ tool calls?

No. Each invocation runs under the service-client identity on Conduit’s side, but Power Platform records the end user who initiated the invocation. Conduit’s audit log shows the service-client subject; Copilot Studio’s audit log shows the end user. The two together are the audit trail.

Will this work for an agent published to Teams / a website?

Yes — once the connector is wired and tested in the maker portal, publishing the agent to any Copilot Studio channel carries the connector with it. Each end user completes the one-time per-end-user consent the first time they invoke a Conduit tool.

Connecting an AI client — the OAuth path for MCP-native clients (Claude Desktop, Claude Code, Cursor, etc.).
Supported clients — the full client compatibility matrix.
Architecture — why Conduit is MCP-native and how non-MCP clients are bridged.
Security — auth model details, including the service-client primitive.