Inside the Fractured World of AI Agent Marketplaces

How MCP registries, consumer stores, SaaS catalogs, and hyperscaler marketplaces are reshaping how agentic software is discovered, procured, and used.

tl;dr — The idea of a single AI Agent App Store is the wrong mental model.

AI agents and agent-like capabilities are distributed through at least five distinct channel types: open protocol registries, developer workflow catalogs, consumer assistant stores, suite-embedded catalogs, and cloud procurement marketplaces. These channels serve different buyers, different trust models, and different kinds of software.

The most important finding is that the thing being distributed is often not a full autonomous agent. In many cases, what users actually get is an MCP server, connector, chat app, workflow template, skill, action, or suite-native embedded agent. Public consumer stores such as the GPT Store are visible and familiar, but the richest operational inventory often lives elsewhere: in MCP ecosystems, SaaS-native marketplaces, and hyperscaler procurement channels.

So the real question is no longer “Where is the app store for AI agents?” It is: Which distribution channel matters for which type of agentic capability, for which buyer, and with what install path?

Executive Summary

AI agent distribution is not a single market with a single clearinghouse.

It is a fractured distribution stack composed of overlapping channels optimized for different users, commercial models, and deployment assumptions.

At the most open end of the market are protocol-driven registries and developer catalogs, especially around MCP. These surfaces are best understood as infrastructure directories or package ecosystems rather than as retail app stores. Their main value is discoverability of tools and interoperable components, especially MCP servers that give models structured access to systems, APIs, data, and workflows. This is currently one of the densest visible inventories in the market, but it also contains the highest degree of variance in quality, portability, and operational maturity.

A second major channel is the consumer and prosumer assistant store. The clearest example is the GPT Store, which behaves more like a marketplace for custom chat assistants than a marketplace for enterprise-deployable autonomous workers. These surfaces are easy to browse and easy to try, but they often distribute assistant personas, lightweight task-specific tools, or chat-native utilities, not deeply integrated enterprise automation systems.

A third channel is the rise of chat-native app directories and connector ecosystems. These sit between the consumer store and the enterprise catalog. They often distribute apps that are conversational on the front end, but operationally backed by structured APIs, authentication flows, and tool calls. This is where the market begins to blur the boundaries between assistant, app, connector, and agent.

The fourth channel is the suite-embedded catalog. This is where many of the most commercially relevant agentic offerings now live. In ecosystems such as Salesforce, Atlassian, Workday, Oracle, SAP, and ServiceNow, the unit of distribution is often not a portable agent at all. It is a deeply embedded workflow capability tied to the host vendor’s data model, UI, permissions, and business logic. These offerings are often more operationally valuable than public consumer agents, but they are also less portable and less visible to the open market.

The fifth channel is the cloud procurement marketplace. In AWS, Google Cloud, and Microsoft, agentic distribution increasingly looks like enterprise software procurement: searchable listings, partner onboarding, billing, contract alignment, deployable services, and integration into broader cloud infrastructure. These are not just “agent stores.” They are procurement rails for agents, agent tools, guardrails, knowledge bases, services, and development infrastructure.

A key strategic implication follows from this: the unit of distribution matters more than the marketing label. The market frequently uses the word agent to describe fundamentally different things. A GPT, an MCP server, an A2A agent card, a connector, a template, and a suite-native workflow agent should not be treated as the same commercial category. They sit in different channels, solve different problems, and imply different install, integration, and monetization patterns.

For technology leaders, the practical takeaway is that distribution strategy should begin with three questions:

• What exactly is the artifact being distributed?
• Which channel is native to that artifact?
• Who is the real buyer and activation owner?

In other words, a company building a portable tool surface may belong in an MCP registry or developer catalog. A company building a conversational consumer utility may belong in a consumer store. A company building operational enterprise automation may need to win inside a suite marketplace or cloud procurement channel instead.

The headline conclusion is clear: the market is not converging on one App Store for agents. It is segmenting into a channel architecture where discoverability, installability, procurement, and operational use are increasingly separated. The winners will not simply be the companies with the most listings. They will be the companies that understand which channel fits which kind of agentic capability and can meet buyers where those capabilities are actually adopted.

Why the Market for AI Agents Is Not One Market

A strategy analysis of how distribution is fragmenting across open ecosystems, suite-native catalogs, and cloud procurement rails.

I want you to imagine walking into this pristine, futuristic App Store. You’ve got a massive project due, you’re totally overwhelmed, so you pull up this store on your screen to download a fully autonomous AI agent. The dream is to just click install and boom — an AI colleague drops right onto your desktop, ready to do your job for you while you go grab a coffee. It sounds like a beautiful, seamless dream.

But as of March 2026, that dream is completely dead. It is totally shattered. The reality we’re living in right now is infinitely more complex and, frankly, a lot more interesting. The metaphor of the simple agent store is officially gone.

Decoding the Fractured AI Landscape

We really need to decode the reality of AI agent registries and marketplaces. Because it is a mess out there. We have to figure out where these agents actually live, what you are actually downloading when you click that button, and why the incredibly boring-sounding concept of governance is suddenly the most thrilling and terrifying part of the entire AI ecosystem.

We really need to start by redefining our terms, because what we casually call an agent right now is rarely a stand-alone worker. We’re actually witnessing the birth of a massive new software supply chain. When you go looking for an agent, you’re usually just looking for a single puzzle piece in a much larger, highly regulated machine.

The Five Channels of Distribution

I went into these sources looking for the single best place to find an agent, and I immediately realized we can’t even talk about what agents are until we clarify where they are.

The “where” is the whole problem.

If you ask where to find agents, the sources actually point to five entirely different distribution channels. The market had to fracture based on who the buyer is and what they actually need the software to do.

• Open Protocol Registries: Think of the official MCP (Model Context Protocol) registry. This isn’t a retail store where you buy things; it acts as a metadata source of truth. It simply holds the blueprints and points developers to where the code actually lives on the internet.
• Developer Workflow Catalogs: This flows right into places like GitHub’s MCP registry or Docker’s MCP catalog. These aren’t for the everyday consumer; they are built for software engineers to grab code and isolate it in secure containers so they can build bigger applications.
• Consumer Stores: This is the one most people are familiar with — consumer and prosumer stores like OpenAI’s GPT store, where you go to find custom chat assistants. But these first three channels are mostly about open building or consumer experimentation. Once you move into the corporate world, the architecture gets locked down entirely.
• Suite Embedded Catalogs: These include ecosystems like Salesforce Agent Exchange or Atlassian Rovo. The agents here don’t live on their own; they’re deeply, structurally tied to that specific vendor’s data model. An agent built to understand specific customer-led tables inside Salesforce is completely blind if dropped into a random Excel spreadsheet.
• Cloud Procurement Marketplaces: This tackles the absolute highest end of the market with the big guys like AWS, Google Cloud, and Microsoft. Here, massive global enterprises buy agents bundled directly with heavy back-end infrastructure, complete with complex billing systems and iron-clad enterprise contracts.

Cutting Through the Fluff

Looking at the inventory numbers across these channels is hilarious. You have third-party directories like Glama boasting over 20,080 servers, while GitHub lists a highly vetted 89 servers, and Docker hovers around 300.

Those massive 20,000 listings are mostly aggregators scraping duplicate code or pure marketing metrics. It’s total fluff. In 2026, a listing in a directory is a very weak signal of actual market adoption. The real signal is deployability and governability: can a business actually run this piece of code safely? The highly vetted numbers from GitHub and Docker reflect the reality of what is actually usable in a professional setting.

It reminds me of buying a vehicle. Going to the GPT store is like buying a consumer sedan right off the lot — it’s easy, but it’s a closed box and you can’t change how the engine works. The AWS or Google Cloud marketplace is like buying a fleet of commercial logistics trucks for a massive corporation. But going to an MCP registry is like walking into a massive auto parts warehouse to buy a carburetor and a transmission so you can build the engine yourself.

What Are We Actually Downloading?

That analogy perfectly illustrates the most confusing reality of this whole ecosystem. When you walk into that auto parts warehouse, you aren’t walking out with a car; you’re walking out with a component. The sources explicitly state that the unit of distribution in these marketplaces is frequently not a full autonomous agent at all.

In many of these channels, you are actually downloading an MCP server. To understand that, remember that an AI model is just a brain. It doesn’t have hands to type or click a mouse. If it wants to search your computer’s files, it needs a tool, but it doesn’t natively speak the language of your file system. An MCP server acts as a digital translator, a wrapper around a software API that translates the AI’s intent into a command your computer can actually execute.

We also see A2A (Agent-to-Agent) agent cards, which are simply standardized, easily readable JSON text files. Think of them like highly structured digital resumes. They tell other agents on the network their name, the specific tasks they can perform, and the exact data format needed. So in corporate channels, you aren’t downloading a worker; you’re just downloading primitive building blocks, skills, actions, and templates.

The Enterprise Value of Agentic Infrastructure

If I were a department head going to the AWS marketplace expecting an autonomous worker and walking away with a box of Lego bricks, I’d feel frustrated. But this is actually the hallmark of the market maturing. A fully autonomous, pre-packaged agent is generally way too rigid for a real business because it doesn’t know your company’s specific compliance rules, unique data structures, or brand voice.

The real enterprise value lies in what the architectural documents call “agentic infrastructure”. Businesses want the modular components, translation wrappers, and safety guardrails to assemble highly customized, perfectly safe workflows themselves. This explains OpenAI’s deliberate ecosystem split: the GPT store is now strictly for chat personas, while actual MCP-backed logic requires going to the ChatGPT apps directory, which actively blocks apps that don’t meet strict privacy rules.

The Invisible Plumbing: MCP and A2A

With thousands of fragmented components scattered across five different channels, we desperately need a standardized way for those pieces to communicate. Enter the invisible plumbing of the 2026 AI world: the MCP and A2A protocols.

MCP acts as the bridge between the AI and a tool, functioning much like NPM in traditional software to automate installing, upgrading, and configuring libraries.

A2A, heavily driven by Google, standardizes how one AI agent talks to another using JSON RPC over secure HTTP. Think of it like sending a highly structured digital envelope (the JSON RPC dictating the format) through an armored car (secure HTTP ensuring it isn’t tampered with). These complementary protocols are the universal standard plugs of the industry, handling different parts of the conversation.

The Security Nightmare and the Rise of Gatekeepers

This universal connectivity triggers a massive market conflict: protocol power versus storefront power. Protocols prevent vendor lock-in, while massive storefronts want to control billing and keep you exclusively in their curated walled gardens.

But there’s a terrifying logical conclusion: if universal protocols successfully tear down walls and connect powerful modular components directly to sensitive corporate data, a malicious component slipping through the cracks causes total system compromise. A local MCP server doesn’t just read data; it has the ability to execute code. Vulnerabilities like RCE (Remote Code Execution) and token exfiltration mean hackers can run software directly on your machine or secretly grab your digital VIP badges to perfectly masquerade as you.

Because of this, the days of employees openly browsing a public AI store are dead for enterprises. Companies are moving strictly to private catalogs and scoped authorization, bringing in cybersecurity vendors like Okta to treat AI agents exactly like human identities with strict permissions and universal kill switches. JFrog is even stepping in, using its MCP registry as a literal supply chain firewall to scan code before it ever reaches an employee’s machine.

Governance isn’t an optional IT add-on anymore; it is the fundamental prerequisite for the agent existing on the network at all.

Industry-Specific Fortresses

Your actual experience of buying an agent is going to completely depend on the industry you work in.

• Healthcare: Governed by HIPAA, agents here are confined to highly restricted sandboxes and only have access to the exact data needed for a specific task.
• Finance and Insurance: Governed by GLBA, relying on IAM-centric governance. Digital algorithmic bouncers monitor agents in milliseconds to flip a kill switch and revoke tokens before a hallucinating agent can drain an account.
• Retail and CPG: These sectors manage messy logistics and are much more likely to buy embedded agent components directly from cloud marketplaces to manage massive data flows.
• Developer Tools and IT: IT departments can block public registries entirely, forcing software to pull tools only from a custom, heavily vetted corporate URL.

A Redefined Hierarchy of Trust

We have forcibly moved from a consumer mindset of discovery and installation to an enterprise mindset of provenance, identity, and governance. The trend across all serious verticals is converging on the “fleet-managed agent workforce”.

The most provocative realization is this: as identity gatekeepers take over, the very concept of agent identity is becoming standardized. Over the next three to five years, your company will likely issue official corporate IDs to non-human agents, just like they issue an ID badge to you.

So, the next time you wish you could just walk into a futuristic app store, click a button, and download a worker, remember how the workplace dynamic is shifting. The non-human worker becomes the standard for compliance, meaning the AI agent assisting you might end up with a more heavily audited, trusted, and strictly governed digital identity than you do.

The AI Agent App Store Never Arrived

AI agent distribution is not a single market with a single clearinghouse.

It is a stack of overlapping channels optimized for different buyers, trust models, and units of software. In practice, people asking “where do I find agents?” are often mixing together protocol registries, IDE galleries, consumer assistant stores, in-chat app directories, suite-native agent galleries, SaaS marketplaces, cloud procurement marketplaces, and private enterprise catalogs. [1]-[4], [6], [10], [13], [18], [22]-[23], [25]

A second structural point is just as important: the thing being distributed is often not a full autonomous agent. The dominant units of distribution are frequently MCP servers, connectors, chat-native apps, actions/topics/templates, skills, embedded workflow agents, or hosted services wrapped in marketplace and governance layers. That is why “agent marketplace” has become less useful as a single category and more useful as a shorthand for multiple adjacent systems. [1], [3], [6], [8], [18], [22], [32]

Two interoperability rails organize much of this ecosystem. MCP (Model Context Protocol) is the primary tool/data connectivity layer and now has an official registry, downstream registries, and explicit governance/enterprise-readiness work on its roadmap. A2A (Agent2Agent) is the emerging agent-to-agent layer, now under the Linux Foundation, centered on Agent Cards plus JSON-RPC over HTTP(S). The two are complementary rather than substitutive: MCP is mostly about tools and data, while A2A is about agents collaborating as agents. [1], [15], [30]-[31], [36]-[38]

The densest publicly visible “agent-like” inventory is often not in consumer stores. It is usually in MCP ecosystems: the official registry, downstream registries such as GitHub and Docker, and large community aggregators such as Glama and Smithery. Those inventories are easy to overread. Public counts are directional, not adoption metrics, and may include duplicates, forks, uneven quality, or listings that are better understood as tool endpoints than as production-grade agents. [1]-[3], [33]-[35]

Meanwhile, the enterprise center of gravity is shifting away from open browsing and toward control planes: private catalogs, allowlists, policy-mediated installs, delegated authorization, auditability, provenance, and kill-switches. This is where identity and supply-chain vendors such as Okta and JFrog, plus suite-native control layers such as ServiceNow AI Control Tower, are trying to become the system of record for agentic assets. [40]-[41], [44], [46]-[51], [65]

Operationally, three distinctions matter throughout this market:

1. Browsable vs. deployable — a visible listing does not mean a working install path.
2. Deployable vs. procurable — something you can run is not always something you can buy through enterprise commerce rails.
3. Public catalog vs. private catalog — many of the most consequential enterprise deployments happen inside tenant-gated or policy-gated catalogs rather than public storefronts. [12], [17], [19], [39]-[40], [50]

Top conclusions

Fact-plus-synthesis conclusions from the distribution-channel research

• The market is best understood as multiple channel types — registries, directories, stores, procurement marketplaces, and in-product galleries — not as one universal store. [1], [4], [6], [10], [13], [18], [22]
• “Agent listings” often resolve to components: MCP servers, connectors, apps, actions, topics, templates, skills, or embedded workflow agents. [3], [8], [18], [22], [32]
• The MCP Registry is explicitly metadata-first. It points to install targets such as npm, PyPI, Docker, or remote endpoints and is designed to feed downstream registries and marketplaces. [1], [36]-[37]
• GitHub and Docker act as major distribution accelerants for MCP servers: GitHub emphasizes discovery and one-click use in VS Code; Docker emphasizes container packaging, isolation, provenance, and SBOM patterns. [2]-[3], [39]
• Hyperscaler marketplaces increasingly frame discovery as procurement plus governed deployment rather than a consumer storefront. [10], [15], [18]-[19]
• OpenAI splits distribution across at least two materially different surfaces: GPT Store for custom assistants and Apps in ChatGPT / the Apps Directory for in-chat apps built on the Apps SDK and MCP. Their publishing constraints also differ. [4]-[7], [43]
• Microsoft combines marketplace-level distribution with in-product surfaces: Microsoft Marketplace and the Microsoft 365 Copilot Agent Store are explicitly linked through packaging, validation, Partner Center, and admin enablement. [10]-[12]
• Google uses a multi-sourced model inside Gemini Enterprise: Google-made agents, org-built agents, and registered A2A agents; this is tied to procurement through Google Cloud Marketplace and Agent Cards. [13]-[17]
• Public inventory claims vary by channel. The most visible precise counts tend to appear in MCP registries and aggregators, not in consumer agent stores. [2]-[3], [33]-[34]
• Discovery increasingly blends directory browsing with contextual surfacing: suggestions in chat, gallery views in suites, and semantic search in procurement catalogs. [7], [11], [14], [19]

Ten conclusions that matter from the registries/governance

Sources for the preceding table: [1], [30]-[31], [36], [38], [40], [46], [49], [52]-[53], [55], [61]-[62]

Key uncertainties

We identify several unresolved questions that materially affect any ongoing market census or strategic plan:

• whether MCP governance matures into a broadly trusted provenance and policy model rather than remaining a discovery layer;
• whether A2A becomes a widely used runtime interoperability layer rather than mainly a spec and onboarding artifact;
• whether the dominant commercial layer becomes cloud procurement, suite-native stores, or governance/control planes that sit above both;
• whether public listing counts become any better proxy for production deployment or remain mostly weak inventory signals;
• how much compliance burden shifts into registry and marketplace onboarding as enforcement dates approach, especially under the EU AI Act and sectoral U.S. regimes. [10], [18], [30]-[31], [38], [46], [50], [55]-[56]

Definitions and research approach

The core definitions are:

• Registry: a machine-consumable catalog of installable or connectable artifacts, often with standardized metadata and APIs. MCP explicitly frames its registry in these terms and supports compatible sub-registries. [1], [36]-[37]
• Directory: a primarily human-facing listing surface that may not implement standardized install flows or governance semantics. Community MCP directories are the clearest example. [33]-[35]
• Marketplace / storefront: a purchase or contracting channel with billing, legal, or procurement workflows. AWS Marketplace, Google Cloud Marketplace, and Microsoft Marketplace fit this model. [10], [15], [18]-[19]
• Enterprise catalog (private): a curated, allowlisted set of approved artifacts exposed through admin-controlled registry URLs, policy settings, or suite-native controls. VS Code and GitHub both document this pattern explicitly. [40]-[41]
• Control plane / governance inventory: a system of record that inventories agentic assets, enforces policy, supports lifecycle operations, and may mediate access, audit, or revocation. JFrog, Okta, and ServiceNow all explicitly position products in this direction. [46]-[48], [50]-[51], [65]

The research also insist on a practical interpretation rule for any channel census: a channel only “exists” as a distribution surface when there is public documentation and/or a browsable surface with a visible activation path. An announcement without a usable catalog is not treated as a full distribution channel. [1], [11], [14], [18]

Market map of AI agent distribution channels

A practical market map emerges by asking two questions:

1. Who owns the distribution surface?
2. What is the unit of listing?

The same marketing word — agent — can hide very different artifacts and trust assumptions. The channel types that clearly exist as of March 2026 are:

• open protocol registries such as the MCP Registry;
• developer-tool catalogs for MCP servers such as GitHub MCP Registry and Docker MCP Catalog;
• consumer/prosumer assistant stores such as GPT Store;
• chat-native app directories such as Apps in ChatGPT;
• suite-embedded agent stores and galleries such as Microsoft 365 Copilot Agent Store and Gemini Enterprise Agent Gallery;
• SaaS ecosystem marketplaces such as Salesforce AgentExchange, ServiceNow Store, Atlassian Marketplace patterns, Workday Marketplace, and Oracle Fusion’s marketplace;
• cloud procurement marketplaces such as AWS Marketplace, Google Cloud Marketplace, and Microsoft Marketplace;
• downstream community directories and aggregators such as Glama and Smithery. [1]-[4], [6], [10]-[11], [14]-[15], [18], [22]-[23], [25]-[27], [33], [35]

The research adds a useful interpretive insight: today’s “agentic AI distribution” resembles three older software distribution patterns layered together:

1. a package ecosystem pattern (registry -> downstream indexers -> client installers) for MCP servers;
2. a SaaS marketplace pattern (partner certification -> listings -> admin-enabled deployment) for suite-native and SaaS agents;
3. a cloud marketplace procurement pattern (contracting, billing, deployment options, governance) for enterprise-grade purchases. [1], [3], [10], [15], [18], [22]-[23]

Diagram synthesis from [1]-[4], [6], [8], [11], [14], [18], [22], [30], [46], [50]

The layered ecosystem of registries and marketplaces

The research argues that the ecosystem is converging on a nine-layer stack. The layers are not always separate products — many platforms vertically integrate several of them — but the split helps explain where discoverability, installability, procurement, runtime, and governance actually happen.

Sources for the preceding table: [1], [9], [15], [18], [30]-[31], [36], [39]-[40], [43]-[44], [46], [50], [65]

Two structural points stand out:

• the registry layer and the marketplace layer are splitting. Registries optimize for compatibility and discovery, while marketplaces optimize for procurement, validation, and managed deployment; and
• governance is becoming its own monetizable layer, rather than an optional enterprise add-on. [1], [15], [18], [40]-[41], [46], [50], [65]

Evidence of convergence at the protocol layer

MCP’s official registry and roadmap show an intentional move toward enterprise-grade mechanics: open catalog/API semantics, the idea of a single source of truth, compatible sub-registries, and roadmap emphasis on governance maturation and enterprise readiness. [1], [36]-[38]

A2A represents a parallel path for agent-to-agent interoperability. Its public materials highlight Agent Cards, JSON-RPC 2.0 over HTTP(S), asynchronous patterns, SDKs, and Linux Foundation governance. Google’s marketplace and Gemini Enterprise documents make A2A operationally relevant by using Agent Cards and A2A registration flows in actual onboarding mechanics. [15]-[17], [30]-[31]

Public directories vs. official registries

The market currently mixes official registries, platform registries built atop official registries, and downstream community directories. That mix itself is a signal: discovery is hard enough, and registry data is reusable enough, that multiple players are trying to solve browseability, installability, and curation on top of shared metadata. [1]-[3], [33]-[35], [40]-[41]

Master inventory of registries, marketplaces, app stores, galleries, and catalogs

The table below preserves the main census from the research while standardizing formatting and terminology.

Sources for the preceding table: [1]-[15], [18], [21]-[30], [32]-[35]

Reading guidance. Inventory counts in this table are mixed-quality signals. Some are directly observable on live pages; some are vendor-reported launch counts; some come from community aggregators with unclear deduplication. The research consistently advise treating them as evidence of visible inventory, not as evidence of adoption. [1]-[3], [10], [33]-[34]

How it works in practice: lifecycle from discovery to decommissioning

Creation and packaging

In developer-tool ecosystems, MCP servers are typically packaged in two ways:

• local servers, which run on a developer workstation or inside a containerized environment; and
• remote servers, where authentication, policy, and service boundaries become first-class parts of connection and approval. [3], [39], [42]

VS Code explicitly warns that local MCP servers can run arbitrary code and configures them through mcp.json at user or workspace scope. GitHub's own setup guidance distinguishes local and remote GitHub MCP server configurations and often recommends the hosted remote option. OpenAI's developer docs similarly frame remote MCP servers as the right packaging boundary for ChatGPT apps and API integrations. [39], [42]-[43]

On the A2A side, Google is unusually explicit about packaging: build the AI agent, create its Agent Card, onboard through Producer Portal, then register the agent in Gemini Enterprise. In other words, the packaging boundary is not just code; it is metadata, identity, capability advertisement, and marketplace compliance. [15]-[17], [31]

Discovery and evaluation

Discovery experiences vary sharply by channel:

• in IDEs and developer tools, users browse or search galleries and install into local config;
• in official registries, discovery is catalog/API driven;
• in cloud marketplaces, discovery is oriented around buy-and-deploy workflows; and
• in suite-native stores, discovery is embedded inside the application where work already happens. [1], [11], [14], [19], [22]-[23], [39]

The crucial distinction is that only some discovery channels have a fully documented install path. VS Code, Google Gemini Enterprise, Microsoft publishing docs, and Anthropic’s Desktop Extensions all document what happens after discovery; many community directories do not. [9], [12], [16]-[17], [39], [66]

Approval and governance

Enterprise reality diverges sharply from marketplace rhetoric at the approval stage.

VS Code supports enterprise policy settings that can restrict MCP sources, disable risky auto-approval behavior, and point users to custom registry URLs. GitHub documents organization- and enterprise-level registry configuration, including self-hosting and Azure API Center patterns. OpenAI documents workspace admin controls and RBAC for apps. Microsoft’s publish flow includes validation and, for some cases, responsible AI checks. JFrog reframes the whole issue as an AI software supply-chain problem. [12], [40]-[41], [44], [46]-[47]

In practice, “approval” spans a wide range:

• a simple admin enablement toggle;
• a curated but lightly reviewed listing;
• a supply-chain workflow with provenance, source restrictions, artifact governance, and runtime policy. [40]-[41], [48], [50]

Installation and connection

Installation paths vary by channel:

• one-click IDE installation into config files such as mcp.json;
• registration into an enterprise agent hub such as Gemini Enterprise;
• extension-style packaging for local tool servers, as in Claude Desktop Extensions;
• consumer publishing and public availability gates, as in GPT Store rules. [5], [9], [17], [39], [66]

OpenAI explicitly notes that public GPT publishing can be unavailable when a GPT uses apps, and public actions require a valid privacy-policy URL. That detail matters because it proves the GPT Store and the Apps Directory are not just different UI tabs; they are distinct distribution systems with different governance and review mechanics. [5]-[7]

Authentication and authorization

Delegated access is the boundary between a hobbyist directory and a production ecosystem. OpenAI’s Apps SDK documentation describes a protected-resource metadata flow, dynamic client registration, and OAuth-mediated authorization. That ties agent ecosystems to standard identity specs such as OpenID Connect Dynamic Client Registration. [6], [44]-[45]

Okta extends this identity framing further by treating agents as discoverable, governable non-human identities. Its public materials emphasize agent registration, an Agent Gateway, virtual MCP server ideas, audit/observability, and kill-switch semantics through revocation and universal logout. [49]-[51]

Monitoring, audit, and incident response

The research repeatedly stress that enterprises want agent behavior to be observable and stoppable. VS Code includes tool approval controls. OpenAI states that app calls are logged and available via compliance tooling. Check Point’s published vulnerability analysis reinforces why approval-before-execution and hardening matter in MCP-style ecosystems. [40], [44], [52]-[53]

Billing and procurement

Procurement pathways are a major differentiator among ecosystems:

• AWS Marketplace emphasizes discoverable and purchasable partner solutions with multiple deployment methods;
• Google ties marketplace onboarding to registration and use inside Gemini Enterprise;
• Microsoft links marketplace publishing to in-product appearance after IT enablement and Partner Center workflows. [10], [12], [15], [17]-[19]

A broad pattern emerges: cloud marketplaces increasingly sell agentic infrastructure — tools, guardrails, knowledge bases, governance layers, and services — alongside end-user agents. [10], [15], [18], [21]

Lifecycle synthesis from the research: [12], [15], [17], [19], [39], [42], [44], [50], [53]

What is actually being offered

A recurring source of confusion is that “agent marketplace” can mean many different artifact classes.

Documented artifact classes distributed in practice

• Custom chat assistants such as GPTs in the GPT Store. [4]-[5]
• Chat-native apps inside ChatGPT built with the Apps SDK, often MCP-backed and optionally UI-rich. [6]-[7], [43]
• Connectors that expose enterprise tools and data to a host assistant, especially via MCP. [7]-[8], [43]
• MCP servers distributed via registries, package registries, container catalogs, or remote endpoints. [1]-[3]
• Agent components such as skills, actions, topics, and templates. [22], [32]
• Suite-native workflow agents embedded in collaboration, CRM, ERP, HR, and ITSM suites. [11], [14], [25]-[27], [29]
• Cloud marketplace agent solutions that mix agents, agent tools, knowledge bases, guardrails, and professional services. [10], [15], [18]

Sources for the preceding table: [1]-[4], [6], [8], [22], [26]-[27], [29], [32]

Sources for the preceding table: [11], [15], [18], [22], [39], [46], [50]

Taxonomy by discovery model

The research discovery taxonomy can be rendered compactly as four operating modes:

1. Open public listing (low gate): community directories and “awesome” lists. [33]-[35]
2. Curated registry (medium gate): official registries, verified extensions, and gallery-like install surfaces. [1]-[3], [9]
3. Enterprise allowlisted catalog (high gate): custom registry URLs, source restrictions, tenant-level approval, and admin-managed availability. [17], [40]-[41], [44]
4. Procurement marketplace (commercial gate): billable listings, producer portals, partner validation, and deployment governance. [10], [12], [15], [18]

Sources for the preceding table: [5], [12], [16]-[17], [39], [47], [50]

Taxonomy by governance and trust model

The research imply a five-tier trust model for agentic ecosystems:

1. Unvetted listing — directory-only discovery with no strong runtime guarantees.
2. Curated listing — some screening or verification, but limited operational assurances.
3. Verified publisher plus signed artifact — stronger provenance, still insufficient without runtime policy.
4. Enterprise allowlist plus policy enforcement — approved sources only, least-privilege access, auditability.
5. Fleet-managed agent workforce — continuous monitoring, anomaly detection, kill-switches, lifecycle operations. [40]-[41], [46], [50], [53], [65]

Representative offerings and what can actually be found

MCP server ecosystems

GitHub’s public MCP Registry surface showed servers such as Markitdown, Netdata, Context7, Playwright, and GitHub MCP server. Docker’s catalog described more than 300 verified servers, including partner tools and remote services tied to products such as GitHub, Notion, and Linear. Community directories went much larger: the research observed Glama at 20,080 servers and 1,293 connectors, but explicitly warned that these should be read as broad index coverage rather than as 20,080 production-grade agents. [2]-[3], [33]-[34]

Smithery sits downstream of the official MCP Registry pattern and presents itself as a marketplace for discovering and connecting MCP servers, while Hugging Face documents an Agents hub with an MCP server, skills, and MCP-compatible Spaces that can be consumed by ChatGPT, Claude Desktop, IDEs, and other MCP-compatible clients. [1], [32], [35]

ChatGPT surfaces: GPT Store vs. Apps in ChatGPT

OpenAI as an especially important case because it has at least two distinct distribution surfaces. GPT Store is oriented around custom GPTs, organized into user-facing categories such as writing, research, programming, education, and lifestyle. OpenAI reported more than 3 million user-created GPTs by Jan. 2024 and documented public publishing constraints for GPTs. [4]-[5]

Apps in ChatGPT, by contrast, are in-chat apps built with the Apps SDK and MCP. They can include interactive UI, OAuth flows, and deeper integration semantics. Launch framing highlighted partners such as Booking.com, Canva, Coursera, Expedia, Figma, Spotify, and Zillow. OpenAI’s help documentation makes clear that apps are browsed in the app directory, connected through OAuth, and invoked through UI, app-name selection, contextual suggestions, or @-style mentions; and that GPTs using apps may face different publishing constraints. [5]-[7], [43]-[44]

Claude connectors and Desktop Extensions

Anthropic documents a public connectors directory and separately describes Desktop Extensions as installable packages that enable one-click MCP server installation in Claude Desktop. Public connector listings include integrations such as Airtable, Asana, Atlassian Rovo, and AWS Marketplace. This is strong evidence of an active connector-led distribution surface with curated packaging, even though installation details vary by product surface and plan. [8]-[9], [66]

Hyperscaler procurement catalogs

AWS Marketplace explicitly describes a mixed inventory spanning pre-built agents, software with embedded agents, MCP servers, knowledge bases, guardrails, development solutions, and professional services. Google Cloud Marketplace is more mechanically explicit than most: onboarding requires an Agent Card in JSON form and connects procurement to registration inside Gemini Enterprise. Microsoft Marketplace pairs broad catalog reach with downstream distribution into Microsoft 365 surfaces and the Copilot Agent Store. [10]-[12], [15], [18]-[21], [64]

SaaS marketplaces and suite-native catalogs

Salesforce AgentExchange is framed as a library of actions, topics, and templates for building Agentforce agents, not primarily as a catalog of portable standalone agents. ServiceNow positions its store as a marketplace for AI agents plus broad app and integration inventory. Atlassian publishes more than 20 out-of-the-box Rovo agents — spanning PRD writing/review, release-note drafting, translation, OKR creation, Jira work-item management, support triage, and operations support — and separately documents partner-built Marketplace agents. Workday’s public evidence comes mainly through named launch agents in newsroom materials. Oracle and SAP illustrate two more embedded patterns: Oracle’s validated partner agent marketplace inside Fusion and SAP’s first-party Joule Agents catalog. [22]-[29]

Comparative findings: where the most inventory appears

Where inventory is densest

The merged evidence points to MCP downstream directories and aggregators as the largest raw inventory surfaces. The research directly observed large public counts on Glama; Docker described 300+ verified servers; GitHub displayed 89 servers on its directory page at the time of observation. These are not like-for-like counts, but they do show that protocol-aligned tool ecosystems are currently easier to enumerate than most suite-native or consumer stores. [2]-[3], [33]-[34]

For enterprise commerce catalogs, Microsoft’s reported “over 3,000 AI apps and agents” is large, but the research caution against reading that as “3,000 deployable autonomous agents.” Marketplace categories often bundle apps, agents, tools, services, and integrations together. [10], [15], [18]

Public vs. gated

Protocol registries and developer catalogs are usually publicly browsable. Suite-native agent galleries are often partially or heavily customer-gated. SaaS marketplaces can be publicly visible but only meaningfully usable inside the SaaS tenant and data model. Apps in ChatGPT are in-product, plan-sensitive, workspace-sensitive, and sometimes geography-sensitive. [1]-[3], [7], [14], [23], [26]

Browseable vs. deployable vs. procurable

A useful reality filter is to ask three separate questions:

• Can I browse it? Public registries and many marketplaces say yes.
• Can I deploy it? MCP registries and dev catalogs often say yes, but procurement may be BYO billing.
• Can I procure it like enterprise software? Cloud marketplaces and commercial suite marketplaces are strongest here, though the inventory often includes tools and services in addition to agents. [1], [3], [10], [15], [18]

Industry-by-industry patterns

Vertical differences are structural because agentic assets touch systems of record, regulated data, and operational workflows. The same distribution mechanism can be acceptable in one domain and unacceptable in another. The research emphasize two broad compliance forces shaping 2026:

• the phased implementation timeline of the EU AI Act — entry into force in Aug. 2024, prohibitions and AI-literacy duties from Feb. 2025, GPAI obligations from Aug. 2025, and broader enforceability from Aug. 2026; and
• sectoral U.S. regimes such as HIPAA, GLBA, and PCI DSS, with PCI DSS v4.x future-dated requirements becoming effective on Mar. 31, 2025. [55]-[59], [61]-[62]

Healthcare and life sciences

Healthcare production usage is likely to favor private catalogs of approved capabilities coupled to strong governance. The research ground this in HIPAA’s minimum-necessary and safeguard requirements, then map healthcare use cases to care-coordination domains rather than to generic marketplace metaphors. The implication is that discovery may still be broad, but actual deployment will tend to be identity-mediated, allowlisted, auditable, and centrally decommissionable. [46], [50], [57]-[60]

Sources for the preceding table: [46], [50], [57]-[60]

Financial services and insurance

Finance strongly favors private allowlists, identity-first delegated access, audit-grade logging, and revocation semantics. The research connect this to GLBA’s safeguards expectations and broader model-governance norms, then infer that finance will look more like a tightly governed control-plane market than an open browse-and-install market. [46], [50]-[51], [61]

Retail, e-commerce, and CPG

Retail is more likely than healthcare or finance to adopt cloud-marketplace procurement for agentic tools because it usually operates across heterogeneous vendor stacks but with narrower heavily regulated zones, especially payment environments. PCI DSS pushes payment-related workflows toward more formalized control, inventory, and separation of duties. The research therefore expect more componentized procurement: agent tools, guardrails, search, routing, and embedded software SKUs. [18]-[19], [62]

Manufacturing and industrial

Manufacturing is described as a tool-driven domain touching maintenance, supply-chain coordination, quality management, and OT/IT boundaries. Because interference with physical processes can create safety risk, the research infer governance needs similar to finance and healthcare: allowlists, change control, audit, and cautious treatment of tool servers as supply-chain assets. [39], [46], [52]

Software, IT, and developer tools

This is the fastest-moving and most visible vertical because install flows, registries, and enterprise policies already exist in IDEs and developer platforms. VS Code supports gallery installation, mcp.json, and enterprise AI settings; GitHub documents organization- and enterprise-level registry configuration; Docker packages servers in containers; and MCP itself has explicit registry and security guidance. The research suggest that this vertical is effectively showing the future structure for other industries: registry plus allowlist plus approvals plus standard auth. [1], [3], [39]-[41], [52]

Customer support, contact center, and BPO

The dominant pattern here is likely to be prebuilt workflow bundles distributed through suite-native CRM, ITSM, or contact-center ecosystems rather than through open public agent stores. Audit trails matter because support and dispute-resolution workflows need traceability. This fits the research’ view that skills, actions, and templates often dominate over standalone agents in CRM-centered ecosystems. [22]-[24]

Legal, compliance, and professional services

Anything touching client data is likely to avoid open marketplaces in favor of controlled tool access, strong logging, careful scoping, and a separation between discovery and deployment. The research label this as an inference, but it is consistent with the broader shift toward governance-heavy infrastructure and least-privilege patterns. [44], [46], [50]

HR, recruiting, and workforce operations

Primary risks here include privacy, bias, and tenant-scoped governance. That pushes distribution toward suite ecosystems and tenant-level controls rather than public registries. Workday’s launch materials, Microsoft’s enablement model, and Oracle’s embedded marketplace all fit this pattern. [12], [26]-[28]

Public sector and education

Public-sector adoption is shaped by procurement rules, institutional risk tolerance, and formal compliance regimes. The research also note that in education the GLBA Safeguards Rule can become relevant in some contexts, increasing the role of formal security programs and vendor risk management. [55]-[56], [61], [63]

Marketing, sales, and revenue operations

This vertical often routes through CRM and productivity ecosystems. Sales workflows are frequently distributed as actions, templates, or embedded components rather than as portable autonomous agents.

This again reinforces the general theme: distribution is often inseparable from the host suite’s policy model and admin plane. [11], [22]-[23]

Sources for the preceding table: [22], [40], [46], [50], [57], [59], [61]-[63]

Economics, governance, and competitive dynamics

The economic center of gravity is shifting away from public discovery

Three kinds of evidence support this claim:

1. JFrog positions MCP Registry as an enterprise control plane and software-supply-chain firewall for MCP servers.
2. Okta treats agents as identities to be discovered, registered, governed, logged, and revoked.
3. ServiceNow’s AI Control Tower language centers on visibility, governance, and control across agents and platforms. [46]-[51], [65]

Taken together, the research infer a likely future in which storefronts remain fragmented by platform, while governance layers consolidate around a smaller number of control-plane providers or patterns. [46], [50], [54], [65]

Sources for the preceding table: [40]-[41], [46], [50], [53], [65]

Why install flows are now security-critical infrastructure

The developer-tool case makes the risk concrete. VS Code warns that local MCP servers can run arbitrary code. The MCP project publishes dedicated security guidance. Check Point’s published exploit analysis shows why approval before execution, least privilege, and hardening are not optional. As a result, marketplace dynamics are changing: governance is becoming a prerequisite to broad deployment rather than an enterprise upsell. [39], [52]-[53]

Protocol power vs. storefront power vs. control-plane power

A useful synthesis from the research is to think in three competitive layers:

• Protocol power: MCP and A2A reduce lock-in at the interface layer and create portability. [1], [30]-[31]
• Storefront power: suite and cloud providers win through distribution, billing, admin surfaces, and workflow embedding. [11], [14], [18], [22]
• Control-plane power: identity, policy, and supply-chain layers decide what can actually run. [40]-[41], [46], [50], [65]

A plausible medium-term equilibrium is that protocols commoditize connectivity, storefronts compete for reach and procurement, and control planes capture durable rents by becoming mandatory enterprise infrastructure. [1], [10], [18], [46], [50]

Strategic takeaways and recommendations

For builders and platform teams

• Treat your “agent” as a governed artifact, not just as a feature demo.
• Provide clear capability boundaries, scopes, metadata, versioning, and safe operational defaults.
• If you are distributing tool integrations, MCP-aligned packaging buys multi-surface reach because official and downstream registries already expect MCP-style metadata.
• If your product requires rich UI and interactive workflows inside chat, use app surfaces designed for that rather than trying to force everything into a consumer assistant store.
• If your product depends on a suite data model, expect tenant-gated onboarding, validation, and packaging requirements. [1], [3], [6], [12], [15], [22], [27], [43]

For buyers

• If you want broad technical choice, start with MCP ecosystems and treat the inventory primarily as tool capability.
• If you want business-value agents that work inside ERP, CRM, ITSM, collaboration, or HR suites, shop the relevant suite-native catalog rather than a generic “agent store.”
• If procurement and billing need to resemble enterprise software purchasing, cloud marketplaces and major suite marketplaces are the most mature buy rails — but the inventory will include many tools and services, not just end-user agents. [2]-[3], [10], [15], [18], [22]-[23], [33]

For enterprise IT and security leaders

• Shift the agent program away from ad hoc app evaluation and toward supply-chain plus identity governance.
• Centralize approved MCP servers, A2A agents, skills, and app connections in private catalogs where possible.
• Require auditability, revocation, and bounded delegated access.
• Treat kill-switch capability as a baseline requirement for high-risk integrations. [40]-[41], [44], [46], [50], [53]

For researchers running an ongoing census

• Use the MCP Registry’s own framing — a metadata repository feeding downstream registries — as a clue that counting requires deduplication across registries, package targets, and aggregators.
• Prefer directly observed counts when available, but treat them as inventory rather than usage.
• Where public browseability is weak, use official press releases and onboarding docs to enumerate named inventories and entry requirements. [1]-[2], [26]-[27], [33], [36]

For investors and strategists

Durable value is more likely to accumulate in registry infrastructure, agent identity, policy and audit layers, secure tool gateways, provenance/signing, and compliance automation than in generic storefronts. The evidence is not that storefronts vanish, but that storefronts fragment while governance becomes mandatory. [46]-[50], [54], [65]

For policymakers and standards bodies

The research argue that phased regulation will increasingly land inside registry, procurement, and onboarding requirements. A practical implication is that portable governance signals — provenance, audit schemas, scopes, publisher verification, revocation semantics — matter almost as much as interface standards such as MCP and A2A. [30], [38], [44], [50], [55]-[56]

Three-to-five-year scenarios

1. Federated registry world

What happens. MCP-style registries standardize metadata and APIs; enterprises run private registries that federate from upstream sources; developers publish once and appear in many galleries.

Why it is plausible. MCP explicitly supports an open catalog model and compatible sub-registries. VS Code and GitHub already document custom registry URLs and enterprise registry configuration. [1], [36], [38], [40]-[41]

2. Cloud procurement dominance

What happens. AWS, Google Cloud, and Microsoft become the default buy rails for agents and agent tools, bundling procurement with deployment templates, guardrails, knowledge bases, and usage-based billing.

Why it is plausible. AWS and Google explicitly present marketplace categories that include agent tools and services, not just agents, while Microsoft links marketplace reach to downstream product surfaces. [10], [15], [18], [21], [64]

3. Suite-native agent economies

What happens. Productivity, CRM, ITSM, ERP, and HR suites own a large share of enterprise distribution because agents are embedded where work already happens.

Why it is plausible. Microsoft Agent Store, Salesforce AgentExchange, ServiceNow’s AI marketplace, Atlassian Rovo agents, Oracle Fusion marketplace, SAP Joule Agents, and Workday’s agent pattern all fit this direction. [11], [22]-[23], [25]-[27], [29]

4. Identity and supply-chain gatekeepers

What happens. The decisive question becomes not who can list, but who can run. Identity vendors treat agents as non-human identities; supply-chain vendors treat MCP servers like packages; control planes enforce policy and revoke at runtime.

Why it is plausible. Okta and JFrog already use this language directly, and enterprise policy controls for MCP sources already exist in real tools. [40]-[41], [46], [48]-[51]

Open questions for further research

1. How quickly will registry ecosystems adopt portable provenance and signing standards, and will they interoperate across MCP registries and suite-native stores? [36], [38], [46]
2. Will “agent identity” converge on standardized representations across IAM systems, or remain vendor-specific? [50]-[51]
3. Will A2A be widely used for cross-platform orchestration, or mostly remain inside ecosystems tightly coupled to specific frameworks and enterprise deployments? [15], [30]-[31]
4. How will enterprise buyers operationalize “approval” so that it predicts safe behavior rather than acting as a checkbox? [40], [46], [53]
5. As EU AI Act enforcement approaches, how much compliance burden will shift into marketplace onboarding and registry governance requirements? [55]-[56]

Appendix A: Glossary

• MCP server: a server implementing the Model Context Protocol to expose tools, resources, or prompts to an MCP client. [1], [52]
• Agent Card: the A2A mechanism for advertising agent capabilities and connection details; also used in Google marketplace onboarding and Gemini Enterprise registration. [15]-[16], [31]
• Private registry: an enterprise-controlled catalog endpoint that can block access to public registries or constrain allowed sources. [40]-[41]
• Control tower / control plane: a centralized governance and inventory interface for agentic assets. [46], [50], [65]
• Dynamic client registration: an OAuth/OIDC mechanism that enables runtime client registration; used in OpenAI’s Apps SDK authentication flow. [44]-[45]

Appendix B: Methodology

• prioritize official documentation, platform docs, onboarding guides, standards repositories, and security/governance material;
• treat community directory counts and marketplace listing counts as weak evidence unless directly observed and clearly qualified;
• distinguish between public browseability, installability, procureability, and governability;
• use governance as a cross-cutting lens, broadly aligned with the NIST AI RMF;
• mark industry-specific conclusions that go beyond documentation as informed inference rather than direct product claims. [1], [33]-[34], [40], [50], [54]

Appendix C: Source categories

The unified bibliography groups naturally into four source families:

1. Standards and registries: MCP registry/about/live/roadmap, A2A repo and Linux Foundation announcement, MCP security guidance. [1], [30]-[31], [36]-[38], [52]
2. Platform and marketplace docs: GitHub, Docker, OpenAI, Anthropic, Microsoft, Google Cloud, AWS, Salesforce, ServiceNow, Atlassian, Workday, Oracle, SAP, Hugging Face. [2]-[4], [6], [8], [10], [13], [18], [22]-[23], [25]-[27], [29], [32]
3. Governance and security references: JFrog, Okta, ServiceNow AI Control Tower, Check Point, OIDC dynamic registration. [45]-[51], [53], [65]
4. Regulatory and sectoral frameworks: NIST AI RMF, EU AI Act sources, HIPAA, GLBA, PCI DSS, AHRQ, NACUBO. [54]-[63]

References

[1] Model Context Protocol, “The MCP Registry.” [Online]. Available: https://modelcontextprotocol.io/registry/about. [Accessed: Mar. 2026].

[2] GitHub, “Meet the GitHub MCP Registry: The fastest way to discover MCP Servers.” [Online]. Available: https://github.blog/ai-and-ml/github-copilot/meet-the-github-mcp-registry-the-fastest-way-to-discover-mcp-servers/. [Accessed: Mar. 2026].

[3] Docker, “Catalog.” [Online]. Available: https://docs.docker.com/ai/mcp-catalog-and-toolkit/catalog/. [Accessed: Mar. 2026].

[4] OpenAI, “Introducing the GPT Store.” [Online]. Available: https://openai.com/index/introducing-the-gpt-store/. [Accessed: Mar. 2026].

[5] OpenAI Help Center, “Sharing and publishing GPTs.” [Online]. Available: https://help.openai.com/en/articles/8798878-building-and-publishing-a-gpt. [Accessed: Mar. 2026].

[6] OpenAI, “Introducing apps in ChatGPT and the new Apps SDK.” [Online]. Available: https://openai.com/index/introducing-apps-in-chatgpt/. [Accessed: Mar. 2026].

[7] OpenAI Help Center, “Apps in ChatGPT.” [Online]. Available: https://help.openai.com/en/articles/11487775-connectors-in-chatgpt. [Accessed: Mar. 2026].

[8] Anthropic, “Connectors.” [Online]. Available: https://claude.com/connectors. [Accessed: Mar. 2026].

[9] Anthropic, “One-click MCP server installation for Claude Desktop.” [Online]. Available: https://www.anthropic.com/engineering/desktop-extensions. [Accessed: Mar. 2026].

[10] Microsoft, “Introducing Microsoft Marketplace — Thousands of solutions. Millions of customers. One Marketplace..” [Online]. Available: https://blogs.microsoft.com/blog/2025/09/25/introducing-microsoft-marketplace-thousands-of-solutions-millions-of-customers-one-marketplace/. [Accessed: Mar. 2026].

[11] Microsoft 365 Developer Blog, “Introducing the Agent Store: Build, publish, and discover agents in Microsoft 365 Copilot.” [Online]. Available: https://devblogs.microsoft.com/microsoft365dev/introducing-the-agent-store-build-publish-and-discover-agents-in-microsoft-365-copilot/. [Accessed: Mar. 2026].

[12] Microsoft Learn, “Publish Agents for Microsoft 365 Copilot.” [Online]. Available: https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/publish. [Accessed: Mar. 2026].

[13] Google Cloud, “Agents overview | Gemini Enterprise.” [Online]. Available: https://docs.cloud.google.com/gemini/enterprise/docs/agents-overview. [Accessed: Mar. 2026].

[14] Google Cloud, “Browse agents with Agent Gallery | Gemini Enterprise.” [Online]. Available: https://docs.cloud.google.com/gemini/enterprise/docs/agent-gallery. [Accessed: Mar. 2026].

[15] Google Cloud, “Offer AI agents through Google Cloud Marketplace.” [Online]. Available: https://docs.cloud.google.com/marketplace/docs/partners/ai-agents. [Accessed: Mar. 2026].

[16] Google Cloud, “Register and manage A2A agents | Gemini Enterprise.” [Online]. Available: https://docs.cloud.google.com/gemini/enterprise/docs/register-and-manage-an-a2a-agent. [Accessed: Mar. 2026].

[17] Google Cloud, “Add and manage A2A agents from Marketplace | Gemini Enterprise.” [Online]. Available: https://docs.cloud.google.com/gemini/enterprise/docs/register-and-manage-marketplace-agents. [Accessed: Mar. 2026].

[18] AWS Marketplace, “AI Agent Solutions | Find & Deploy Agents.” [Online]. Available: https://aws.amazon.com/marketplace/solutions/ai-agents-and-tools. [Accessed: Mar. 2026].

[19] AWS Marketplace Buyer Guide, “Discovering AI agents and tools.” [Online]. Available: https://docs.aws.amazon.com/marketplace/latest/buyerguide/ai-agent-discovery.html. [Accessed: Mar. 2026].

[20] AWS, “Introducing AI agents and tools in AWS Marketplace.” [Online]. Available: https://aws.amazon.com/about-aws/whats-new/2025/07/ai-agents-tools-aws-marketplace/. [Accessed: Mar. 2026].

[21] AWS Partner Network Blog, “Introducing AI Agents and Tools in AWS Marketplace.” [Online]. Available: https://aws.amazon.com/blogs/apn/aws-partner-guide-to-ai-agents-and-tools-in-aws-marketplace/. [Accessed: Mar. 2026].

[22] Salesforce, “Salesforce unveils AgentExchange trusted marketplace for Agentforce.” [Online]. Available: https://www.salesforce.com/news/press-releases/2025/03/04/agentexchange-announcement/. [Accessed: Mar. 2026].

[23] ServiceNow Store, “AI Agent Marketplace.” [Online]. Available: https://store.servicenow.com/store/ai-marketplace. [Accessed: Mar. 2026].

[24] ServiceNow, “Your Go-to Marketplace for AI Agents.” [Online]. Available: https://www.servicenow.com/blogs/2025/your-go-to-marketplace-ai-agents. [Accessed: Mar. 2026].

[25] Atlassian Support, “Out-of-the-box agents | Rovo.” [Online]. Available: https://support.atlassian.com/rovo/docs/atlassian-agents/. [Accessed: Mar. 2026].

[26] Workday, “Workday Announces New AI Agent Partner Network and Agent Gateway.” [Online]. Available: https://newsroom.workday.com/2025-06-03-Workday-Announces-New-AI-Agent-Partner-Network-and-Agent-Gateway-to-Power-the-Next-Generation-of-Human-and-Digital-Workforces. [Accessed: Mar. 2026].

[27] Oracle, “Oracle Launches Fusion Applications AI Agent Marketplace.” [Online]. Available: https://www.oracle.com/news/announcement/ai-world-oracle-launches-fusion-applications-ai-agent-marketplace-to-accelerate-enterprise-ai-adoption-2025-10-15/. [Accessed: Mar. 2026].

[28] Oracle, “Oracle’s AI Agent Marketplace enhances business apps.” [Online]. Available: https://www.oracle.com/artificial-intelligence/ai-agents/oracle-announces-ai-agent-marketplace/. [Accessed: Mar. 2026].

[29] SAP, “Joule Agents | AI Use Cases for Every Business Function.” [Online]. Available: https://www.sap.com/products/artificial-intelligence/ai-agents/agent-use-cases.html. [Accessed: Mar. 2026].

[30] Linux Foundation, “Linux Foundation Launches the Agent2Agent Protocol Project.” [Online]. Available: https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents. [Accessed: Mar. 2026].

[31] A2A Project, “Agent2Agent (A2A) is an open protocol enabling communication and interoperability between opaque agentic applications.” [Online]. Available: https://github.com/a2aproject/A2A. [Accessed: Mar. 2026].

[32] Hugging Face, “Agents.” [Online]. Available: https://huggingface.co/docs/hub/agents-overview. [Accessed: Mar. 2026].

[33] Glama, “Popular MCP Servers.” [Online]. Available: https://glama.ai/mcp/servers. [Accessed: Mar. 2026].

[34] Glama, “MCP Connectors.” [Online]. Available: https://glama.ai/. [Accessed: Mar. 2026].

[35] Smithery, “Smithery — Connect agents to MCPs in minutes.” [Online]. Available: https://smithery.ai/. [Accessed: Mar. 2026].

[36] Model Context Protocol Blog, “Introducing the MCP Registry.” [Online]. Available: https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/. [Accessed: Mar. 2026].

[37] Model Context Protocol, “Official MCP Registry.” [Online]. Available: https://registry.modelcontextprotocol.io/. [Accessed: Mar. 2026].

[38] Model Context Protocol Blog, “The 2026 MCP Roadmap.” [Online]. Available: https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/. [Accessed: Mar. 2026].

[39] Visual Studio Code, “Add and manage MCP servers in VS Code.” [Online]. Available: https://code.visualstudio.com/docs/copilot/customization/mcp-servers. [Accessed: Mar. 2026].

[40] Visual Studio Code, “Manage AI settings in enterprise environments.” [Online]. Available: https://code.visualstudio.com/docs/enterprise/ai-settings. [Accessed: Mar. 2026].

[41] GitHub Docs, “Configure an MCP registry for your organization or enterprise.” [Online]. Available: https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-mcp-usage/configure-mcp-registry. [Accessed: Mar. 2026].

[42] GitHub Docs, “Setting up the GitHub MCP Server.” [Online]. Available: https://docs.github.com/en/copilot/how-tos/provide-context/use-mcp/set-up-the-github-mcp-server. [Accessed: Mar. 2026].

[43] OpenAI Developers, “Building MCP servers for ChatGPT Apps and API integrations.” [Online]. Available: https://developers.openai.com/api/docs/mcp/. [Accessed: Mar. 2026].

[44] OpenAI Developers, “Authentication.” [Online]. Available: https://developers.openai.com/apps-sdk/build/auth/. [Accessed: Mar. 2026].

[45] OpenID Foundation, “OpenID Connect Dynamic Client Registration 1.0.” [Online]. Available: https://openid.net/specs/openid-connect-registration-1_0.html. [Accessed: Mar. 2026].

[46] JFrog, “JFrog Unveils Universal MCP Registry, Delivering a New AI Software Supply Chain.” [Online]. Available: https://jfrog.com/press-room/jfrog-unveils-universal-mcp-registry-for-ai-software-supply-chain/. [Accessed: Mar. 2026].

[47] JFrog, “MCP Registry Solution page.” [Online]. Available: https://jfrog.com/ai-catalog/mcp-registry/. [Accessed: Mar. 2026].

[48] JFrog, “From Agentic Risk to Agentic Confidence: The JFrog MCP Registry.” [Online]. Available: https://jfrog.com/blog/announcing-general-availability-of-the-jfrog-mcp-registry/. [Accessed: Mar. 2026].

[49] Okta, “Okta announces new blueprint for the secure agentic enterprise.” [Online]. Available: https://www.okta.com/newsroom/press-releases/showcase-2026/. [Accessed: Mar. 2026].

[50] Okta, “Govern AI agent Identity at Scale.” [Online]. Available: https://www.okta.com/products/govern-ai-agent-identity/. [Accessed: Mar. 2026].

[51] Okta, “The blueprint for the secure agentic enterprise.” [Online]. Available: https://www.okta.com/solutions/secure-ai/agentic-enterprise-blueprint/. [Accessed: Mar. 2026].

[52] Model Context Protocol, “Security Best Practices.” [Online]. Available: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices. [Accessed: Mar. 2026].

[53] Check Point Research, “RCE and API Token Exfiltration Through Claude Code Project Files.” [Online]. Available: https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/. [Accessed: Mar. 2026].

[54] NIST, “Artificial Intelligence Risk Management Framework (AI RMF 1.0).” [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf. [Accessed: Mar. 2026].

[55] European Commission, “AI Act | Shaping Europe’s digital future.” [Online]. Available: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. [Accessed: Mar. 2026].

[56] AI Act Service Desk, “Timeline for the Implementation of the EU AI Act.” [Online]. Available: https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act. [Accessed: Mar. 2026].

[57] U.S. HHS, “The HIPAA Privacy Rule.” [Online]. Available: https://www.hhs.gov/hipaa/for-professionals/privacy/index.html. [Accessed: Mar. 2026].

[58] U.S. HHS, “Summary of the HIPAA Privacy Rule.” [Online]. Available: https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html. [Accessed: Mar. 2026].

[59] U.S. HHS, “Summary of the HIPAA Security Rule.” [Online]. Available: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html. [Accessed: Mar. 2026].

[60] AHRQ, “Chapter 3. Care Coordination Measurement Framework.” [Online]. Available: https://www.ahrq.gov/ncepcr/care/coordination/atlas/chapter3.html. [Accessed: Mar. 2026].

[61] FTC, “Gramm-Leach-Bliley Act.” [Online]. Available: https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act. [Accessed: Mar. 2026].

[62] PCI Security Standards Council, “Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x.” [Online]. Available: https://blog.pcisecuritystandards.org/now-is-the-time-for-organizations-to-adopt-the-future-dated-requirements-of-pci-dss-v4-x. [Accessed: Mar. 2026].

[63] NACUBO, “Privacy and Data Security Resources.” [Online]. Available: https://www.nacubo.org/Topics/Privacy-and-Data-Security/Privacy-Data-Security-Resources. [Accessed: Mar. 2026].

[64] Google Cloud, “Google Cloud AI Agent Marketplace.” [Online]. Available: https://cloud.google.com/blog/topics/partners/google-cloud-ai-agent-marketplace. [Accessed: Mar. 2026].

[65] ServiceNow, “ServiceNow AI Control Tower.” [Online]. Available: https://www.servicenow.com/products/ai-control-tower.html. [Accessed: Mar. 2026].

[66] Claude Help Center, “Installing Claude Desktop.” [Online]. Available: https://support.claude.com/en/articles/10065433-installing-claude-desktop. [Accessed: Mar. 2026].