Romain Sestier · · 10 min 
The Best MCP Gateways for Microsoft Copilot in 2026
Table of Contents
An MCP gateway gives Microsoft Copilot — Copilot Studio agents and Microsoft 365 Copilot (M365 Copilot) declarative agents alike — one governed MCP connection to many business systems, instead of a sprawl of one-off servers. Microsoft already governs the client side well: Power Platform DLP, Advanced Connector Policies, and the Agent 365 registry decide which MCP servers agents may reach. What Microsoft doesn’t supply sits behind that policy plane: deep third-party connectors, per-user credentials, tool lists that respect Copilot’s 128-tool cap, and tool-call-level audit. Verdict: StackOne for governed depth on systems of record; Zapier for breadth-first pilots; Workato if you’re already a Workato shop.
Does Microsoft Copilot support MCP?
Yes — in two places, with different rules. (Throughout, MCP means agents acting on systems through tools — distinct from Copilot connectors, the Graph connectors that ground Copilot’s answers in your content.) The verified state of Copilot MCP support as of June 2026:
Copilot Studio (GA)
MCP support in Copilot Studio is generally available (announced May 29, 2025). The short version: makers add an MCP server from the agent’s Tools page (Add a tool → New tool → Model Context Protocol); transport is Streamable HTTP only (SSE unsupported after August 2025); auth is none, API key, or OAuth 2.0; tools run with end-user credentials by default (mcp-add-existing-server-to-agent, doc dated 2026-05-28). Server-side tool changes reflect dynamically, and makers can view and disable individual tools (mcp-add-components-to-agent). The number that shapes everything: max 128 tools per agent, with 25–30 recommended; each child agent in multi-agent orchestration gets its own 128 budget (add-tools-custom-agent, doc dated 2026-01-29). MCP connectivity rides on Power Platform connector infrastructure — which matters for governance, below. For the maker-level detail — wizard auth modes, custom connectors from an OpenAPI spec, certification, environment governance — see the dedicated Copilot Studio guide.
Microsoft 365 Copilot declarative agents (GA)
MCP in declarative agents for M365 Copilot reached GA on December 15, 2025: developers wire MCP servers in via the Microsoft 365 Agents Toolkit, wrapped as API-plugin actions and distributed through the Agent Store or admin deployment. One structural difference from Copilot Studio: tool discovery is static by default — the tool list is frozen in the agent manifest, server-side changes require republish and revalidation, and dynamic discovery is rolling out to Microsoft-published agents first (build-mcp-plugins, updated 2026-05-12; plugin-dynamic-tool-discovery, doc dated 2026-06-04).
One reconciliation worth stating plainly, because two true facts on this page look contradictory: wiring an MCP server into a declarative agent through the Agents Toolkit works today — that’s the GA above. What doesn’t yet reach declarative agents is the other route: tenant-level Agent 365 BYO registration (next section). The two are independent; picking a gateway for M365 Copilot means using the Toolkit path now.
Microsoft’s governance plane
Three layers, all client-side:
- Power Platform DLP / Advanced Connector Policies. Because Copilot Studio MCP rides on connectors, Microsoft’s docs are explicit: “if a data policy regulates Power Platform connectors, it also regulates access to the MCP server and its tools.” Advanced Connector Policies went GA on June 4, 2026 — an allowlist-model redesign where admins block an MCP server like any connector and disable individual actions, per environment or environment group.
- Agent 365. The Microsoft 365 admin center’s Agent Tools Registry lists MCP servers in the tenant, with Block/Unblock enforced at runtime across client surfaces. Bring-your-own registration (preview) goes through the Agent 365 CLI with admin approval and Entra consent; BYO-registered servers route through the Agent 365 Tooling Gateway, monitorable in Defender advanced hunting. Caveat: BYO-registered servers are not yet usable in M365 declarative agents — today they reach Copilot Studio, VS Code, Claude Code, and the GitHub Copilot CLI, with Azure AI Foundry also unsupported (manage-tools-for-agent, doc dated 2026-06-04). As above: this BYO limit doesn’t block the Agents Toolkit path into declarative agents, which is separate and GA.
- Purview. Agent interactions are audited at the interaction level (Workload=Copilot, TargetAgentName) (plugin-dynamic-tool-discovery, doc dated 2026-06-04).
Licensing, briefly: Copilot Studio runs on Copilot Credits; a Microsoft 365 Copilot seat zero-rates classic answers, generative answers, and Microsoft Graph tenant grounding in Copilot Chat and Teams — but tool and action calls, including MCP tool calls, still consume Copilot Credits — and includes the right to extend with Copilot Studio agents (billing-licensing, doc dated 2026-04-27). Which makes tool curation a cost lever as well as a quality one: a tool list agents select from correctly the first time burns fewer credits per task.
What don’t Microsoft Copilot’s native MCP controls cover?
Microsoft’s plane governs which MCP servers agents reach, and deliberately stops there: “when you connect to a non-Microsoft product, including an external MCP server, you’re responsible for the tools and resources you access from within Copilot Studio” (agent-extend-action-mcp, doc dated 2026-04-17). A gateway is never a replacement for DLP, ACP, or Agent 365 — it’s the layer those policies point at. The gaps it fills:
- No supplied connectors for third-party depth. Agent-grade write actions into HRIS, ERP, and ITSM behind an MCP interface are yours to find, build, or buy.
- Tool curation under Copilot’s limits. Nothing condenses a sprawling server’s tool list for you — connect three raw API-wrapper servers and you blow Microsoft’s recommended count before lunch. In M365 Copilot declarative agents the same sprawl costs more: every tool-list change forces a manifest republish and revalidation.
- Per-user credentials into external systems. The MCP server must actually implement per-user auth into each downstream system.
- Tool-call-level audit. Which arguments went to which tool against which system of record lives with the server operator, not Purview or Defender.
- Tool-response security. Microsoft’s guidance on indirect prompt injection and tool poisoning in MCP (April 28, 2025) recommends AI Prompt Shields, spotlighting, and supply-chain checks — a responsibility Microsoft explicitly leaves with you when you connect non-Microsoft servers.
What to look for in an MCP gateway for Microsoft Copilot
Each criterion maps to a verified Copilot constraint:
| Criterion | Why it matters for Copilot |
|---|---|
| Streamable HTTP remote MCP, OAuth 2.0 (manual + dynamic registration) | The Copilot Studio wizard accepts nothing else — SSE-only or stdio-only gateways won’t connect |
| Tool curation under the 128 cap | 128 max, 25–30 recommended; curated actions or meta-tools, not thousands of raw endpoint wrappers |
| Stable tool surface for M365 Copilot declarative agents | Static tool discovery freezes the tool list in the agent manifest — every server-side tool change forces a republish and revalidation; a gateway whose tool surface stays constant avoids that churn |
| Per-user (end-user credential) auth end-to-end | Copilot defaults to end-user credentials; the gateway must carry that identity into each downstream system, not flatten it to a service account |
| Plays inside Power Platform governance | One MCP connector that DLP/ACP can scope beats fifty ungoverned ones |
| Depth beyond the certified-connector catalog | Agent-grade reads and writes into HRIS, ERP, ITSM, CRM |
| Tool-call-level audit logs | Complements Purview’s interaction-level audit with which tool, which arguments, which provider call |
The best MCP gateways for Microsoft Copilot, compared
Scoped to options genuinely relevant to a Copilot deployment; full 12-vendor comparison in the hub post.
| Platform | Catalog | Curation under the 128 cap | Per-user credentials | Tool-call-level audit | Pricing |
|---|---|---|---|---|---|
| StackOne | 310+ connectors / 20,000+ actions | Two meta-tools or scoped action lists | End-user OAuth 2.1 | Request logs down to provider calls | Free plan (full catalog) |
| Workato Enterprise MCP | Workato connector library | Recipe/connector selection | Verified User Access (identity inheritance) | Workato platform audit logs | Not published |
| Zapier MCP | 9,000+ apps (automation-shaped) | App/action allowlists | User’s existing Zapier connections | Zapier task history | In existing Zapier plan; each call = 2 tasks |
| Merge Agent Handler | ”Thousands of tools”; per-system catalog not published | Tool Packs scoping | Guided end-user flow; SCIM | Audit logs on all plans | Free tier; Pro $1,000/mo |
| Microsoft native stack (Agent 365 + certified connectors) | Certified connector catalog | Registry Block/Unblock, ACP action disable | Entra-native | Purview interaction-level; Defender hunting | Included in M365/Power Platform licensing |
| Microsoft mcp-gateway (OSS) | Bring your own servers | None built in | You implement it | You build it | Free (MIT) |
1. StackOne
StackOne is the enterprise layer for AI agents to safely act on any application — 310+ managed connectors exposing 20,000+ agent-optimized actions across HRIS, ERP, CRM, and ITSM, behind one governed MCP endpoint. Against this page’s criteria: it’s a managed remote MCP server with end-user OAuth 2.1 account linking — verified end-to-end through Copilot Studio’s MCP wizard — where users sign in through SSO and approve which linked accounts an MCP client may use: the per-user model Copilot Studio’s end-user credential default calls for, rather than flattening everyone to a service account. On the 128-tool cap, the answer is structural: agents get two meta-tools, search and execute, instead of thousands of definitions, so context stays constant whatever the catalog size (a 460× reduction versus loading every definition) — and the search half carries the design, with 92.8% first-try tool-selection accuracy, the leading score in our published comparison. The same property pays off twice for M365 Copilot declarative agents: a tool surface that never changes as the catalog grows means the manifest-frozen tool list under static discovery never needs a republish-and-revalidate cycle. Admins scope which actions each project exposes, request logs capture every call down to provider requests (exportable to Datadog or Grafana) to complement Purview, and StackOne Defender scans tool responses for prompt injection — the class of tool-response control Microsoft’s MCP security guidance says is your responsibility to add. Limitation: the catalog focuses on business systems, not consumer applications — for the consumer-app long tail, Zapier’s catalog is far bigger. When a system isn’t in the catalog, the AI Connector Builder builds or extends a connector on the same engine that powers the pre-built ones, so coverage isn’t capped at what ships out of the box.
Best for: Copilot deployments that need governed, deep, per-user actions on systems of record.
2. Workato Enterprise MCP
Workato’s Enterprise MCP extends the automation platform many Microsoft enterprises already run. Its Verified User Access model — agent actions inherit the authenticated user’s identity, so RBAC and audit apply automatically — lines up naturally with Copilot’s end-user credential default. The trade-off: it’s a feature of the Workato platform, not a standalone gateway — adopting it without being a Workato shop means buying an enterprise automation platform to get MCP — and pricing isn’t published.
Best for: existing Workato enterprises pointing Copilot agents at policies they’ve already built.
3. Zapier MCP
Zapier MCP includes the biggest catalog in this comparison — 9,000+ apps, 30,000+ pre-built actions — over a remote MCP endpoint with no-terminal setup. App allowlists and action approval map sensibly onto pilot-grade Copilot Studio governance. The caveats: each tool call consumes two tasks (agents are chatty; a task-metered model was priced for workflows), actions are automation-shaped — broad rather than deep — and curation is per-action, so picking the right 25 of 30,000 actions to stay inside Copilot’s recommended tool count is manual work you own.
Best for: breadth-first Copilot pilots by teams already paying for Zapier, at modest volumes.
4. Merge Agent Handler
Merge’s Agent Handler includes runtime data controls: inline DLP scanning on tool-call inputs and outputs, guardrails that block, redact, or mask, audit logs on all plans, SCIM, SOC 2. Tool Packs give a curation mechanism for the 128-cap problem. The open question is published depth — the catalog is summarized as “thousands of tools”, and while Merge documents per-integration coverage for its Unified API, Agent Handler doesn’t publish an equivalent per-system tool catalog, so verify your specific systems — and pricing is credit-metered (free tier; Pro $1,000/month for 25,000 credits).
Best for: teams that want DLP-style redaction bundled into a managed tool-call path — verify per-system tool coverage on your systems first.
Microsoft’s native stack (Agent 365 Tooling Gateway + certified connectors)
The fair baseline: know what your licenses already include. The Agent Tools Registry gives tenant-wide visibility and runtime Block/Unblock; BYO-registered servers route through the Agent 365 Tooling Gateway with Defender hunting; ACP disables individual actions; everything is Entra-native (manage-tools-for-agent, doc dated 2026-06-04). What it is not: a source of connectors. It governs MCP servers — it doesn’t supply deep third-party ones or per-user credential linking into external systems, and BYO registration is preview. Treat it as the policy plane every gateway on this list should sit under, not as the gateway itself.
Best for: every Microsoft tenant — as the governance layer, alongside whichever gateway supplies the connectors.
Microsoft mcp-gateway (open source)
Different product, same name: github.com/microsoft/mcp-gateway (MIT) is a Kubernetes-native reverse proxy with session-aware routing and Entra ID auth — self-hosted plumbing for platform teams that build and operate their own MCP servers, not a managed governance product. Note the preview edges (agents/sessions subsystem in preview; built-in tools unsandboxed); covered fully in the hub post.
Best for: AKS platform teams running in-house servers behind Copilot.
How to connect StackOne to Microsoft Copilot
In Microsoft 365 Copilot declarative agents — the M365 Copilot surface this page is about:
- Scaffold a declarative agent in the Microsoft 365 Agents Toolkit and add the StackOne MCP endpoint as the agent’s MCP server; the Toolkit wraps its tools as API-plugin actions in the agent manifest.
- In StackOne, scope which actions the agent exposes via connector profiles before packaging — under static tool discovery, this is the tool list that gets frozen into the manifest.
- This is where the two-meta-tool mode earns its keep: a search-and-execute surface doesn’t change as connectors are added, so the manifest never needs the republish-and-revalidation cycle a raw server’s tool churn forces.
- Distribute through the Agent Store or admin deployment.
One caveat to plan around: this Agents Toolkit path is independent of Agent 365 BYO registration, which doesn’t yet extend to declarative agents — so tenant-registry Block/Unblock coverage for this route is still catching up to the deployment reality.
In Copilot Studio: open your agent → Tools → Add a tool → New tool → Model Context Protocol, paste the StackOne MCP URL, pick the wizard’s OAuth 2.0 option (StackOne implements the OAuth 2.1 profile MCP clients expect), and keep end-user credentials mode. The full wizard walkthrough, auth modes, and environment governance live in the Copilot Studio guide.
What the tenant admin sees: one MCP surface to govern — a DLP/ACP-scopable connector for Studio agents, one set of API-plugin actions in each declarative agent’s manifest — with scoped action lists, linked accounts, and full request logs in StackOne. What the end user sees: a one-time SSO sign-in and consent screen choosing which of their accounts the agent may use — then Copilot acts as them, in whichever surface they’re in.
When you don’t need an MCP gateway for Copilot
- Agents only touch Microsoft 365. Copilot’s native plumbing covers first-party data; Microsoft’s own governance may be all you need until you cross ecosystems.
- One agent, one or two systems, a maker who owns it. The Add-tool wizard pointed at a single vendor MCP server is simpler and cheaper.
- You’re still proving the use case. Connect a single managed MCP server directly, prove value, then add gateway controls when user count makes credential and tool sprawl real.
The trigger points: the first agent that needs to write to a non-Microsoft system of record, the first tool list creeping toward 30, and the first security review asking who the agent acted as in Workday.
StackOne is the governed layer between AI agents and 310+ enterprise systems with 20,000+ agent-optimized actions — over MCP, A2A, API, and SDKs — with end-user OAuth linking, connectors you can extend, and built-in prompt-injection defense. See StackOne MCP, the full MCP gateway comparison, or how it works per system: Workday, Salesforce, ServiceNow. See pricing or book a demo.
More MCP gateway guides
Every guide in this series applies the same disclosed criteria to a different AI client. Start with the full comparison, or jump to yours: