Frontier spoke

Microsoft AppSource — the agent-routable surface for Copilot Studio and the M365 estate

Microsoft AppSource is the discovery layer Copilot Studio reads when it routes inside the Microsoft 365, Dynamics, and Power Platform estate. With 230,000+ organizations now building on Copilot Studio and MCP general-availability shipped in late 2025, an AppSource listing — paired with Verified Publisher status and a registered MCP server — is the difference between being callable by Microsoft's enterprise agents and being invisible inside the customer's chosen platform.

By Chris Mühlnickel · 2026-05-18

What is Microsoft AppSource?

Microsoft AppSource is Microsoft's business-app marketplace, recently unified with Azure Marketplace into a single Microsoft Marketplace surface. An AppSource listing makes a vendor's apps, connectors, and MCP servers discoverable inside Microsoft 365, Dynamics 365, Power Platform, and Copilot Studio — the discovery layer Microsoft's Copilot agents read when routing actions on a user's behalf.

By the numbers

Why it matters

Microsoft routes more agent traffic through Copilot Studio than any other single platform — 230,000+ organizations building custom agents, 120,000+ deployed agents, ~70% of the Fortune 500 with some form of Microsoft 365 Copilot adopted, and 420 million monthly active Copilot users overall. AppSource (now unifying with Azure Marketplace into Microsoft Marketplace) is the discovery layer that all of those agents read when they need to call a third-party capability. A vendor whose buyers run any meaningful Microsoft 365 estate either appears in the AppSource layer or doesn't get routed when the customer's Copilot agent needs their service.

The agent-routable surface inside Microsoft is now MCP-shaped. Microsoft made MCP generally available in Copilot Studio in November 2025, and the durable shape of a 2026 AppSource listing for agent traffic is a listing plus a linked MCP server endpoint. Built-in MCP servers for Microsoft-owned data sources (Dataverse, SharePoint, Outlook, Teams, Dynamics 365) ship alongside third-party MCP servers as peer primitives. The Power Platform connector surface that anchored Microsoft's previous decade still exists — and still earns routing — but new vendors targeting agent traffic should treat the MCP server as the front door and the connector as the legacy fallback.

Verified Publisher status is the routing-tier dividing line. Tenant admins increasingly gate which connectors and MCP servers Copilot can invoke for write operations against the Verified Publisher list. The pattern mirrors AppExchange's Security Review and AgentExchange tier exactly: a basic listing surfaces for read-only retrieval, Verified Publisher / certified listings surface for the higher-value write operations. The Entra ID verification investment that read as compliance theatre for a decade is now an explicit Copilot-routing input — and vendors who skip it are invisible to the half of agent traffic that handles the high-value actions.

Cross-tenant discoverability is what AppSource buys you. Custom MCP servers registered directly in a single Copilot Studio agent work for the tenant that registered them; AppSource-registered listings surface across tenants and feed Microsoft's cross-tenant capability routing. The decision a vendor faces is rarely "AppSource or not" — it's "single-tenant pilot then cross-tenant via AppSource" or "single-tenant only forever." The compounding option is the AppSource path because each new Copilot-using customer brings the listing along by default rather than re-onboarding the capability per tenant.

The cost of being absent compounds across the largest agent surface. Unlike SEO, marketplace absence shows up as opportunities the vendor never sees: the IT admin who couldn't find your connector in AppSource installed a competitor's, the Copilot agent that needed your capability called a Verified Publisher's instead, the Dynamics 365 admin whose custom flow needed your service used a built-in Power Automate template. Each absent invocation re-trains Microsoft's routing layer that you're not a candidate. Inside the largest agent install base in B2B software, that drift is expensive.

Where it's heading

The unified Microsoft Marketplace becomes the canonical entry point. Microsoft's September 2025 announcement of one marketplace covering AppSource + Azure Marketplace is mostly a UI consolidation in 2026, but expect 2027 to see the unified Marketplace become the canonical surface that Copilot Studio, Power Platform, and Microsoft 365 tooling reference. Vendors who keep separate AppSource and Azure listings rather than consolidating will look out-of-step with Microsoft's first-party messaging.

MCP-server registration becomes a first-class submission primitive. Today, an MCP server is metadata layered onto an AppSource listing. The 2026-2027 trajectory is for the AppSource publisher console to expose MCP-server URL, capability schema, and version-rotation policy as mandatory fields for any new submission targeting Copilot Studio. The same shift happened to Power Platform connectors when the OpenAPI requirement became mandatory; expect MCP to follow the same arc.

Capability-level trust replaces publisher-level trust. Microsoft's compliance tooling (Microsoft 365 App Compliance Program, Microsoft Compliance Manager, Entra Permissions Management) is trending toward per-capability scoping rather than per-publisher scoping. The 2027-2028 endpoint: 'this vendor's MCP server is trusted for read operations on calendar data but requires elevated permission for write operations on financial records.' Vendors who declare narrow scoped permissions per capability rather than broad publisher-level scopes will earn preferential routing under that model.

Copilot routing learns vendor reliability over time. Microsoft is shipping reliability and quality scoring across the MCP server tier — invocation success rate, latency distribution, schema-drift incidents. The trajectory parallels what Apple did with App Store rankings: marketplace presence is necessary but no longer sufficient; the routing layer measures actual reliability and surfaces the most reliable candidates preferentially. Vendors who can sustain low-failure invocations across long time horizons compound; vendors with intermittent reliability decay quickly.

Cross-platform capability registries emerge underneath. The Linux Foundation Agentic AI Foundation (Microsoft is a platinum member) is positioned as the venue for a single capability declaration that surfaces in AppSource for Copilot, in AgentExchange for Agentforce, in Google's surfaces via A2A, and in the public MCP directory. The 2027 vendor reality is one MCP server registered through one publisher console, surfaced through every major agent marketplace via federation — provided the vendor modeled their capability as MCP from the start.

Agent-callable pricing models replace per-seat metering. Copilot's existing per-user pricing model is the human-era artifact. Vendors who can price their AppSource-listed capability per agent invocation rather than per seat align with how Microsoft is increasingly modeling Copilot itself. Expect AppSource publisher tooling to expose per-invocation metering as a first-class billing primitive through 2026-2027.

Common mistakes

  • Treating the Power Platform connector as a substitute for an [MCP server](/learn/agent-protocols/model-context-protocol). Connectors still earn routing, but Microsoft is investing the agent-roadmap energy on MCP. New integrations should ship the MCP server first; legacy connector-only listings should plan an MCP layer for 2026.
  • Listing on AppSource without pursuing Verified Publisher status. The Verified Publisher tier is the routing-tier dividing line for write operations across Copilot Studio. Skipping the verification is functionally invisibility for the higher-value half of agent invocations.
  • Registering an MCP server only inside a single Copilot Studio agent. The single-tenant registration path works for pilots but doesn't surface the capability across tenants. AppSource-registered MCP servers compound; per-tenant-registered ones don't.
  • Declaring blanket Microsoft Graph or Dataverse scopes. Copilot Studio's routing layer downweights connectors and MCP servers requesting broader scopes than their declared capability needs. Vendors who scope narrowly per capability earn preferential routing; vendors who request blanket access look like trust risks to tenant admins.
  • Letting an AppSource listing's capability metadata go stale. AppSource listings rot fast as the underlying product ships features. A listing claiming capabilities your MCP server no longer exposes leads to failed invocations that train Copilot's reliability scoring against you.
  • Skipping the certification surface entirely 'because we sell through direct enterprise contracts.' Direct enterprise deals still flow through customers' Microsoft 365 environments, and the Copilot routing inside those environments still reads AppSource as the discovery layer. Direct-sales vendors who skip AppSource end up invisible to their own enterprise customers' agent layer.
  • Treating AppSource as a Microsoft-only surface. The Linux Foundation Agentic AI Foundation work and Microsoft's MCP commitment mean AppSource-registered MCP servers are increasingly addressable from cross-platform agents via federation. Vendors who publish through AppSource gain incidental cross-marketplace reach as the federation layer matures.

Frequently asked

What's the difference between an AppSource listing and a Power Platform connector?

An AppSource listing is the marketplace entry — what shows up in the catalog browsed by IT admins and the discovery layer Copilot Studio reads when an agent needs to invoke a third-party capability. A Power Platform connector is the actual machine-callable surface — an OpenAPI-described HTTP endpoint that Copilot or a Power Automate flow can invoke. Most agent-routable AppSource listings link to a connector (or an MCP server); the listing is the discovery record, the connector or MCP server is what gets called.

What is Verified Publisher status, and does Copilot care about it?

Microsoft Verified Publisher is the identity-verified tier for Entra ID app registrations and Microsoft 365 publishers. Verified Publisher status is an explicit routing input for Copilot Studio agents: for write operations on sensitive data, tenant admins increasingly gate which connectors and MCP servers Copilot can invoke to Verified-Publisher-only. Listings without Verified Publisher status surface for read operations but get filtered out of the higher-stakes half of agent traffic — the same dynamic AgentExchange applies for Salesforce's Security Review.

Should I register an MCP server, ship a Power Platform connector, or both?

Both, in 2026. Microsoft made MCP generally available in Copilot Studio in November 2025, and built-in MCP servers + built-in connectors now exist side-by-side for Dataverse, SharePoint, Outlook, Teams, and Dynamics 365. The MCP server is the durable agent-callable surface; the connector is the broader Power Platform fabric (Logic Apps, Power Automate, Power Apps) that's been there for years. New vendors targeting agent traffic should ship the MCP server first; legacy vendors with existing connector investments should layer the MCP server on without retiring the connector.

How long does AppSource certification take?

The 'AppSource certified' tier for Microsoft 365 apps typically takes 4-8 weeks from submission, depending on the depth of integration and security-review surface. Dynamics 365 apps tracked through the ISV Connect program take longer — closer to 8-12 weeks — because the customer-data surface is broader. Power Platform connector certification (separate from AppSource certification proper) varies by connector type, with custom connectors faster than verified connectors. Plan AppSource certification as a quarter-long initiative if the integration touches sensitive data.

Does the Microsoft Marketplace unification change anything for AppSource listings?

Microsoft announced in September 2025 that AppSource and Azure Marketplace are unifying into a single 'Microsoft Marketplace' surface. The customer-facing change is one unified browse experience; the publisher-facing change is one unified submission console. Existing AppSource listings carry over; existing AppSource certifications and Publisher Verifications remain valid. The agent-routing implications are minimal in 2026 — Copilot Studio still reads the same metadata it always has — but watch 2027 for the unified Marketplace becoming the canonical entry point that Microsoft's tooling references rather than 'AppSource' specifically.

Will Copilot Studio agents call tools from outside AppSource?

Yes, with friction. Custom MCP servers registered directly in a Copilot Studio agent (the 'Add Tool → MCP → URL' flow Microsoft simplified in late 2025) work for the tenant they're registered to. AppSource registration is what makes the MCP server discoverable across tenants and surfaces it in Microsoft's cross-tenant agent-routing layer. The choice is: ship a custom MCP server for a single enterprise customer and skip AppSource, or ship through AppSource to be discoverable across the install base. The latter compounds; the former doesn't.

What about Microsoft's own MCP servers — do those compete with mine?

They complement, mostly. Microsoft's built-in MCP servers cover Microsoft-owned data sources (Dataverse, SharePoint, Outlook, Teams, Dynamics 365); third-party MCP servers cover everything else (your CRM, your support platform, your industry-specific data). The agent the user invokes typically calls a chain — Microsoft's built-in MCP server to fetch the user's calendar, then a partner MCP server to act on it. Where third-party MCP servers do compete with Microsoft's own is in the 'augmented Microsoft-owned surface' tier (e.g. enhanced SharePoint search) — Microsoft's first-party offering is the default there, and third parties need a clear differentiation hook.