COPILOT STUDIO — PROJECT 5🟠 ADVANCED
APIBridge-Agent — connecting to an external, non-Microsoft REST API two ways: a custom connector, and a self-hosted custom MCP server. Static reference only.

Pattern A — Custom Connector

Copilot Studio Action
"Look up shipment status"
↓
Custom Connector
OpenAPI definition + OAuth2
↓
Vendor REST API
GET /shipments/:id

Pattern B — Self-Hosted MCP Server

Copilot Studio — MCP tool picker
generative orchestration required
↓
Your MCP Server (Azure Function)
tools: getShipmentStatus, getETA, fileClaimTool
↓
Vendor REST API
same backend as Pattern A
// MCP tool definition (excerpt)
tool: "getShipmentStatus"
input: { trackingNumber: string }
output: { status, eta, lastLocation }
Shipment Tracking Assistant
Where's shipment TRK-88213?
MCP Tool: getShipmentStatus TRK-88213 is in transit — last scanned in Pune, ETA July 7.
It arrived damaged, I need to file a claim
MCP Tool: fileClaimTool I've started a damage claim for TRK-88213.
⚠ This uses a non-Microsoft, self-hosted MCP server — your team owns vetting this tool's behavior and data handling, per Copilot Studio's external-connection policy.
Type a message…

Cost & ownership comparison

Copilot Credits: identical for both patterns (~5 cr/action) — the meter doesn't care which pattern you chose.

Real trade-off: Pattern B centralizes tool definitions on a server you control — update a tool there and Copilot Studio picks it up automatically, no republish needed.

Accountability: for both patterns, but especially B, your org — not Microsoft — is responsible for vetting the external system's behavior and security.
What this shows: two architecturally different ways to reach the exact same external capability, with identical per-action Copilot Credit cost — the decision between them is about maintainability and governance, not price. The explicit accountability warning reflects Microsoft's own documented policy on non-Microsoft MCP servers.