How to get your MCP server into Microsoft Copilot

Here’s the part nobody warns you about with Microsoft Copilot: there’s no place to submit your MCP server. Anthropic and OpenAI take your server and review it. Microsoft doesn’t work that way. To earn the verified status, the partner agent inside the Microsoft 365 Copilot Agent Store, you build a Copilot agent that wraps your server and submit that instead. Your MCP server is the engine. The agent is the car you actually ship.

One thing to get straight before the steps. An agent that wraps your server gives Copilot a way to call your tools. What it can’t hand over is the judgment about what should happen, and in what order, and that part still lives in the process, not the model. We’ve written more about that idea across the AI and the future of work hub.

On Microsoft you submit an agent, not a server

The Microsoft 365 Copilot Agent Store is the hub where people find and install agents. Microsoft describes it as bringing together “agents from Microsoft, trusted partners, and your own organization,” and the docs are clear that prebuilt partner agents are “already built and verified.” That verified-partner status is the Microsoft equivalent of getting accepted into Anthropic’s directory. What’s different is the thing you submit to earn it.

You don’t hand Microsoft an MCP server. You hand it a Copilot agent. The agent is a thin declarative wrapper that points at your server, exposes its tools to Copilot, and carries the branding and metadata the store needs. The server does the work. The agent is the shippable package around it.

Think product, not protocol.

There are really three layers here, in rising order of effort. Any maker can connect your server to their own Copilot Studio agents inside their tenant, today, with no submission at all. A developer can build and submit a partner agent to the Agent Store through Partner Center, which is the verified target. And separately, you can get a Power Platform connector certified so it surfaces for every Copilot Studio customer. Most teams start at the bottom and climb only when the demand is real.

The server underneath still does the real work

The wrapping agent doesn’t excuse you from building a proper server. If anything, Microsoft assumes you already have one. The same strict package every program wants applies here: a remote HTTPS server on Streamable HTTP, OAuth 2.0 with user consent, tools annotated with accurate read-only and destructive hints, a public privacy policy, and a demo account a reviewer can log into and use.

Transport is the one spec to get exactly right. Microsoft’s Copilot Studio docs note that “given that SSE transport is deprecated,” Copilot Studio “no longer supports SSE for MCP after August 2025.” Streamable HTTP is the only path. If you’re still serving SSE anywhere, fix that before anything else.

Get the transport wrong and nothing else gets a chance.

There’s also a positioning point that helps. These programs reject pass-through middleware, a thin relay to someone else’s API, so a connector to your own product is first-party by definition and clears that gate. Tallyfy’s server is first-party to one product, and it already speaks Streamable HTTP with OAuth, so the wrapping agent had nothing to work around. If you want the mechanics of how an agent actually calls your tools, our piece on how agents talk to your tools over MCP walks through it.

The agent is the new work here. The server isn’t, if you built it right the first time.

Building the wrapping agent and getting it verified

The build is more approachable than it sounds, because the tooling does the wiring for you. Microsoft’s guide to declarative agents with MCP lays out the flow in the Microsoft 365 Agents Toolkit: you “Choose Add Action -> Start with an MCP server in the toolkit,” enter your server URL, and “that’s all you need - the toolkit will fetch the server’s list and description of its tools and automatically generate a plugin spec from it.” It scaffolds the files, wires the OAuth, and hands you a one-click provision-and-debug that sideloads the agent into Copilot for testing.

Once the agent runs locally, getting it verified goes through Microsoft Partner Center. You “distribute your Copilot app package through the Microsoft 365 and Copilot program of Microsoft Partner Center,” submitting it “under the offer type Apps and agents for Microsoft 365 and Copilot.” Microsoft validates the package against its marketplace and store policies. When it’s approved, your agent lands in the Microsoft Commercial Marketplace, and after an IT admin enables it, it appears in the Agent Store inside Microsoft 365 Copilot.

If you don’t want to wait on any of that, there’s a self-serve path that works right now. Through the Copilot Studio MCP onboarding wizard, any maker adds your server’s URL, picks an auth type (none, API key, or OAuth 2.0 with dynamic client registration), and attaches it to their agent. It runs on Power Platform connector infrastructure, so it inherits the tenant’s data-loss-prevention policies without extra work. It’s per-tenant rather than a public listing, but it’s how customers can use your server while you build toward the verified one.

The toolkit reading your schema and writing the wiring is the part that makes this whole path worth walking.

Is the Agent Store worth the build?

Be clear about which outcome you actually need. If the goal is just letting Microsoft customers use your server, you already have it: point them at the Copilot Studio wizard and ship a setup doc. That’s a few minutes of their admin’s time and none of Partner Center’s queue. The verified partner agent in the Agent Store is a different commitment. It’s a real declarative-agent build, a Partner Center registration, and a validation pass, and it pays off when public credibility and store discovery actually move deals.

So the realistic sequence is to ship the self-connect path first, get customers using your server, then build the partner agent once there’s demand to point at. You don’t have to climb all three layers at once. Microsoft’s tooling means each one reuses the same server you already built, which is the saving grace of an otherwise heavy path.

Microsoft is the surface where “getting listed” is the most work and the most concrete. There’s a real verified status waiting at the end, but you reach it by shipping a product rather than feeding a server through a form. For the shape of a server that’s already scoped to a process, our Tallyfy MCP server walkthrough lays it out, and Tallyfy’s AI control layer shows how an agent stays on the rails after it connects. The same server gets you into Claude’s directory, an app in ChatGPT, and a custom data store in Gemini, each with its own quirks.

Microsoft’s real starting point isn’t Partner Center. It’s standing up the declarative agent in the Agents Toolkit, pointing it at your server, and watching the wiring generate itself. Get that working, let customers self-connect through Copilot Studio in the meantime, and the verified partner agent becomes a deliberate choice rather than a prerequisite.