None
No authentication. Microsoft explicitly does not recommend it for production, and an enterprise tenant admin is unlikely to approve it.
MCP Distribution · Microsoft 365 Copilot
Publishing an MCP server to Microsoft 365 Copilot
Microsoft is the odd one out. There is no submission portal that reads your server and walks you through a listing. You declare the server in an app manifest, and the app is what gets validated and published. Get the manifest right and most of the work is administrative rather than technical.
The shape of it
The connector and the app are two different things
An agent connector is how a Microsoft 365 agent reaches an external system. For an MCP server the connector supplies four things: the network endpoint, the authentication configuration, the tool definitions, and optional metadata that helps an agent pick the right tool. You declare it in the manifest. Once registered, the server is available to any Microsoft 365 agent that can use MCP.
What surprises teams is that the connector and the store listing move on separate tracks. A server can be registered and reachable while the surrounding app package is still in validation, so "is it live?" has two answers depending on which thing you mean. Decide early which one your launch actually depends on, because they do not arrive together.
You need a test tenant to validate against before any of this reaches a customer. That is not optional in practice, and it is the difference between finding a broken redirect yourself and finding it in a reviewer's notes.
The manifest
Declaring the server
Add a root-level agentConnectors array to manifest.json. Each connector needs an
id unique within the manifest.
| Field | What it is |
|---|---|
| manifestVersion | 1.27 on current schemas |
| agentConnectors[].id | Unique within the manifest |
| displayName / description | What the agent and the admin see |
| toolSource.remoteMcpServer.mcpServerUrl | Your endpoint, HTTPS or WSS |
| …authorization.type | One of the five modes below |
| …authorization.referenceId | Points at a configuration registered in Developer Portal |
| …mcpToolDescription | Optional. Omit it for runtime tool discovery |
Microsoft 365 agents open long-lived connections to this endpoint, so it has to be publicly reachable and stable, not a tunnel.
Authentication
Five modes, and when each is right
OAuthPluginVault
OAuth 2.0 tokens held in Microsoft’s vault, referenced by an ID you register in Developer Portal. The default choice for enterprise scenarios.
ApiKeyPluginVault
An API key held in the vault and referenced by ID. Simpler, and weaker: it identifies your app, not the user.
DynamicClientRegistration
Microsoft registers itself as an OAuth client at runtime via RFC 7591. Your server must expose a compliant registration endpoint, return a client_id and client_secret, and support token refresh.
AzureKeyVault
Credentials in your own Key Vault, so you keep rotation, access policies and audit logging. You grant the Microsoft 365 service principal read access to the secret.
Secrets are never embedded in the manifest. Each mode stores the credential somewhere and the manifest
carries only a referenceId. When you configure the OAuth app with your identity provider,
add https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect to the allowed redirect
endpoints. Omitting it produces a failure that looks like a Microsoft problem and is not.
Tool discovery
Static definitions or runtime discovery
Include an mcpToolDescription and you pin inline tool definitions that must match the
schema your server returns from tools/list. Omit it and agents call
tools/list at runtime, picking up added, changed or removed tools without a manifest
republish.
For anything still evolving, dynamic discovery is the better default, and Microsoft recommends it for toolsets that change frequently. The trade is predictability: with runtime discovery, what an agent can do changes when you deploy, which is convenient for you and a governance question for the tenant admin who approved the app. Say which one you have chosen when you ask for that approval.
Before you publish
Validate it yourself first
Validate the manifest with the Microsoft 365 app package validation tool in Developer Portal
Confirm the server answers MCP handshake messages on a public HTTPS or WSS endpoint
Check tools/list returns unique names, clear descriptions and valid JSON Schema for every input
Verify each referenceId resolves to a real secret, and that token refresh works for OAuth
Ensure the endpoint supports TLS 1.2 or higher
Check error messages and retry semantics for failed tool calls
Then test in a tenant with real natural-language requests rather than tool calls: check the tools appear in the agent's available actions, that consent prompts show where they should, that calls succeed, and that failures degrade gracefully. If you need multi-tenant support, test across more than one tenant before you find out the hard way.
Expect validation feedback to arrive as a list of must-fix items rather than a verdict, and expect publishing to take its own time after approval. The engineering is usually finished well before the process is.
FAQ
Microsoft 365 Copilot questions
Do I submit an MCP server to a Copilot marketplace?
Not directly. You declare the server as an agent connector inside a Microsoft 365 app manifest, and it is the app that gets packaged, validated and published. That distinction matters because the two can move independently: the connector can be reachable while the app package is still working through store validation, which regularly confuses teams who expect one submission and one approval.
What is an agentConnectors array?
A root-level array in the Microsoft 365 app manifest where you declare each MCP server. A connector entry needs a unique id, a displayName, a description, and a toolSource pointing at your remoteMcpServer with its mcpServerUrl. Current manifests use manifestVersion 1.27. Once registered, the server becomes available to any Microsoft 365 agent capable of using MCP.
Should I list tools statically or let Copilot discover them?
Omit mcpToolDescription and Microsoft calls tools/list at runtime, so adding or changing tools does not require republishing the app. Include it and you pin an inline definition that must match your server’s tools/list response. Dynamic discovery is the right default for anything still evolving; static definitions suit a toolset that genuinely does not change.
How long does Microsoft validation take?
Longer than the engineering, and it is not a single decision. Validation typically comes back with a list of must-fix issues to close before you resubmit through Partner Center, and store publishing then takes its own time after approval. Plan in weeks rather than days, and keep a named contact on the thread, because progress often depends on a reply rather than on work.
What do I need for OAuth to work?
Register the OAuth configuration in Developer Portal and reference it by referenceId in the manifest rather than embedding secrets. When you set the app up with your identity provider, add https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect to the allowed redirect endpoints. Missing that redirect is a common and undiagnosable-looking failure.
Does the tenant administrator have to approve it?
In practice yes, and it is the gating factor more often than engineering is. The customer’s IT organisation decides what reaches their users. That changes what you should prepare: a clear statement of what data the connector reaches, which authentication mode it uses, and what an admin is approving. Enterprise scenarios should prefer OAuth over API keys for exactly this reason.
The other surfaces
Same server, different reviewers
Publishing to Claude
A submission portal inside your organization settings, which needs a Team or Enterprise plan before you can submit at all.
Publishing to ChatGPT
Identity verification, a .well-known domain challenge, and eight test cases including three the app should refuse.
Want the submission handled, not explained?
Node8 builds the MCP server, gets the manifest, authentication and tenant story right, and takes it through validation. Most first connectors ship in eight to twelve weeks, and the build is rarely the long pole.