---
title: 'From Plugin Marketplaces to Web Discovery: The Evolution of Agent Ecosystems'
description: >-
  Anthropic's Claude Code plugin marketplaces solve internal distribution.
  LLMFeed's .well-known/ discovery solves web-scale adoption. Together, they
  represent the evolution from walled gardens to open ecosystems.
date: '2025-10-12T00:00:00.000Z'
lang: en
tags:
  - anthropic
  - claude-code
  - discovery
  - llmfeed
  - mcp
  - open-standards
  - plugin-marketplaces
  - web-scale
  - well-known
format: news
category: ecosystem
contentType: analysis
intent: inform
llmIntent: browse-ecosystem-evolution
llmTopic: plugin-marketplaces-web-discovery
audience:
  - llm
  - developer
  - business
  - architect
priority: high
riskLevel: low
updateFrequency: static
pageType: documentation
interactionComplexity: moderate
slug: plugin-marketplaces-web-discovery-evolution
canonical_url: 'https://wellknownmcp.org/en/news/plugin-marketplaces-web-discovery-evolution'
mcpFeedUrl: /.well-known/mcp.llmfeed.json
llmIndexUrl: /.well-known/llm-index.llmfeed.json
image: /images/news/plugin-marketplaces-evolution.png
subtitle: Why centralized registries and decentralized discovery are better together
autoDiscoverFeeds: true
agentReadiness: true
llmBehaviorHints: suggest-only
feedTypes:
  - mcp
  - llm-index
capabilities:
  - ecosystem-analysis
  - architecture-evolution
trustLevel: signed
technicalLevel: intermediate
estimatedReadTime: 9 min
businessImpact: medium
targetMarket: developers
monetizationPotential: medium
relatedArticles:
  - auto-configuration-mcp-revolution
  - openai-validates-mcp-chatgpt-apps-sdk
  - connector-registry-llmfeed-discovery-stack
---

# From Plugin Marketplaces to Web Discovery: The Evolution of Agent Ecosystems

Anthropic just documented their **Claude Code plugin marketplace** architecture. It's elegant, practical, and solves a critical problem for teams deploying AI agents.

But it also reveals a **fundamental tension** in how agent ecosystems evolve:

**Centralized registries vs. decentralized discovery.**

The answer isn't "one or the other"—it's **both, at different layers of the stack**.

Let's explore why.

---

## What Anthropic Built: Plugin Marketplaces

### The Architecture

At its core, a Claude Code plugin marketplace is a **JSON catalog**:

```json
{
  "name": "company-plugins",
  "owner": "acme-corp",
  "plugins": [
    {
      "name": "database-connector",
      "source": "github.com/acme/db-plugin",
      "description": "Connect to company databases",
      "version": "1.2.0"
    },
    {
      "name": "api-client",
      "source": "git@internal.acme.com/api-plugin.git",
      "description": "Internal API client",
      "version": "2.0.1"
    }
  ]
}
```

### Installation & Discovery

**For developers:**
```bash
# Add marketplace
/plugin marketplace add acme-corp/plugins

# Browse available plugins
/plugin

# Install specific plugin
/plugin install database-connector@company-plugins
```

**For teams:**
```json
// .claude/settings.json
{
  "required_marketplaces": [
    "acme-corp/plugins",
    "partner-team/shared-tools"
  ]
}
```

**Result:** Centralized control, easy distribution, version management.

---

## Why Marketplaces Work (For Their Purpose)

### 1. **Team Distribution**

**Problem:** "How do we ensure all engineers use the approved toolset?"

**Solution:** Required marketplaces in team settings

```json
{
  "required_marketplaces": ["company/approved-tools"],
  "auto_install": true
}
```

**Benefit:** ✅ Guaranteed consistency across team

### 2. **Version Control**

**Problem:** "How do we manage plugin updates?"

**Solution:** Automatic version tracking

```json
{
  "name": "api-client",
  "version": "2.0.1",
  "update_policy": "automatic"
}
```

**Benefit:** ✅ Controlled rollout of updates

### 3. **Source Flexibility**

**Problem:** "How do we support internal + external plugins?"

**Solution:** Multiple source types

```javascript
// Public GitHub
"source": "github.com/owner/repo"

// Private Git
"source": "git@internal.company.com/repo.git"

// Local development
"source": "./my-plugin"
```

**Benefit:** ✅ Works in air-gapped environments

### 4. **Admin Control**

**Problem:** "How do we ensure security compliance?"

**Solution:** Centralized approval process

```
Developer → Submits to marketplace
Security Team → Reviews code
Admin → Approves for org
Engineers → Auto-receive update
```

**Benefit:** ✅ Security gate before deployment

---

## Why Marketplaces Don't Scale (To The Web)

### The Centralization Problem

**Marketplace model:**
```
Developer → Submit to Registry → Admin Approves → Users Discover
```

**Bottlenecks:**
1. Registry owner must approve every plugin
2. Discovery limited to registered plugins only
3. No cross-platform visibility
4. Gatekeepers control access

**This works for:**
- ✅ Enterprise internal tools
- ✅ Curated ecosystems
- ✅ Controlled environments

**This breaks for:**
- ❌ Open web-scale discovery
- ❌ Cross-platform agents
- ❌ Decentralized innovation

### The Example: WordPress Plugin Directory

**WordPress.org plugin directory:**
- 60,000+ plugins registered
- Manual review process
- Approval takes days/weeks
- Centralized gatekeeper

**Result:** Mature but **slow** ecosystem growth

**Alternative that emerged:**
- Developers self-host plugins
- Direct installation from URLs
- Faster innovation, less control

**The lesson:** Centralized registries become bottlenecks at scale.

---

## The LLMFeed Alternative: Web-Native Discovery

### Decentralized Publication

**No registry submission required:**

```bash
# 1. Create your capability declaration
cat > .well-known/mcp.llmfeed.json <<EOF
{
  "feed_type": "mcp",
  "metadata": {
    "title": "My API Service",
    "origin": "https://api.example.com"
  },
  "capabilities": [
    {
      "name": "process_data",
      "method": "POST",
      "path": "/api/process"
    }
  ]
}
EOF

# 2. Sign it (optional but recommended)
llmfeed sign .well-known/mcp.llmfeed.json

# 3. Deploy to your server
# Done. Globally discoverable.
```

**No approval, no gatekeeper, instant availability.**

### RFC 8615 Standard Discovery

Agents discover capabilities via **predictable locations:**

```
https://api.example.com/.well-known/mcp.llmfeed.json
https://api.example.com/.well-known/capabilities.llmfeed.json
https://api.example.com/.well-known/llm-index.llmfeed.json
```

**Benefits:**
- ✅ **Standard location** (RFC 8615 compliant)
- ✅ **No central registry** (self-published)
- ✅ **Web-scale immediately** (CDN-cacheable)
- ✅ **Cross-platform** (any agent can discover)

### Trust Without Gatekeepers

**Problem:** "Without approval, how do we trust capabilities?"

**LLMFeed answer:** Cryptographic signatures

```json
{
  "capabilities": [ /* ... */ ],
  "trust": {
    "signed_blocks": ["capabilities"],
    "certifier": "https://llmca.org",
    "algorithm": "ed25519"
  },
  "signature": {
    "value": "cryptographic_proof",
    "created_at": "2025-10-12T10:00:00Z"
  }
}
```

**Result:**
- ✅ Mathematical proof of authenticity
- ✅ Independent third-party certification
- ✅ No central authority needed
- ✅ Agents verify, don't trust

---

## The Hybrid Model: Better Together

### Why Not Both?

The answer isn't "marketplace vs web discovery"—it's **both, for different purposes**:

| Use Case | Best Solution |
|----------|--------------|
| **Enterprise internal tools** | Plugin Marketplace (Anthropic) |
| **Team-wide distribution** | Plugin Marketplace (Anthropic) |
| **Version-controlled rollout** | Plugin Marketplace (Anthropic) |
| **Open web discovery** | `.well-known/` (LLMFeed) |
| **Cross-platform agents** | `.well-known/` (LLMFeed) |
| **Decentralized innovation** | `.well-known/` (LLMFeed) |

### The Complete Architecture

```
┌──────────────────────────────────────────┐
│  DEVELOPER PUBLISHES                     │
├──────────────────────────────────────────┤
│  1. Creates .well-known/mcp.llmfeed.json │ ← Web discovery
│  2. Signs with company key               │ ← Trust layer
│  3. Gets LLMCA certified (optional)      │ ← Third-party validation
└──────────────┬───────────────────────────┘
               │
               ├─────────────────────────────┐
               ↓                             ↓
┌──────────────────────┐      ┌──────────────────────┐
│  INTERNAL TEAMS      │      │  EXTERNAL AGENTS     │
├──────────────────────┤      ├──────────────────────┤
│  • Add to marketplace│      │  • Discover via URL  │
│  • Team auto-installs│      │  • Verify signature  │
│  • Version controlled│      │  • Trust assessment  │
└──────────────────────┘      └──────────────────────┘
```

**Result:**
- Internal teams get curated control
- External agents get web-scale discovery
- Both share same verified source

---

## Evolution Patterns: App Stores to Open Web

### Phase 1: Walled Gardens (2008-2015)

**iOS App Store, Google Play:**
- Centralized approval
- Gatekeepers control access
- Slow but curated

**Result:** Quality control, but innovation bottlenecks

### Phase 2: Side-loading & Self-distribution (2015-2020)

**Android APKs, Enterprise distribution:**
- Direct installation
- Developer self-publishes
- Faster innovation

**Result:** More freedom, less control

### Phase 3: Hybrid Ecosystems (2020-2025)

**npm, PyPI, Docker Hub:**
- Anyone can publish (decentralized)
- Verification via signatures (cryptographic)
- Marketplaces curate subsets (centralized curation)

**Result:** Best of both worlds

### Phase 4: Agent Ecosystems (2025+)

**Plugin Marketplaces + .well-known/ discovery:**
- Marketplaces for internal/curated (Anthropic model)
- Web discovery for open innovation (LLMFeed model)
- Cryptographic trust for both (signatures)

**We're here now.**

---

## Real-World Migration Path

### Scenario: SaaS Company Publishing API

**Step 1: Internal Distribution** (Marketplace)
```bash
# Create plugin for Claude Code
# Submit to company marketplace
# Team auto-installs
```

**Step 2: Web Publication** (LLMFeed)
```bash
# Publish .well-known/mcp.llmfeed.json
# Sign with company key
# Available to all agents globally
```

**Step 3: Dual Distribution**
```json
// Company marketplace entry points to web source
{
  "name": "api-client",
  "source": "github.com/company/plugin",
  "llmfeed_url": "https://api.company.com/.well-known/mcp.llmfeed.json",
  "verified": true
}
```

**Result:**
- ✅ Internal teams use marketplace (controlled)
- ✅ External agents use .well-known/ (open)
- ✅ Same source, different distribution
- ✅ Cryptographic verification for both

---

## Technical Comparison

### Plugin Marketplace Architecture

**Pros:**
- ✅ Centralized version control
- ✅ Team-wide enforcement
- ✅ Admin approval process
- ✅ Works in air-gapped environments

**Cons:**
- ❌ Requires registry submission
- ❌ Gatekeeper bottleneck
- ❌ Platform-specific
- ❌ Limited web-scale discovery

**Best for:** Enterprise internal tooling

### LLMFeed .well-known/ Architecture

**Pros:**
- ✅ No submission required
- ✅ Instant global availability
- ✅ Cross-platform compatible
- ✅ Web-scale by design

**Cons:**
- ❌ No enforced version control
- ❌ Developers must self-publish
- ❌ Requires public web server
- ❌ Team adoption voluntary

**Best for:** Open web ecosystems

---

## The Bridge: Marketplace + LLMFeed

### Enhanced Marketplace Format

```json
{
  "name": "company-plugins",
  "owner": "acme-corp",
  "plugins": [
    {
      "name": "database-connector",
      "source": "github.com/acme/db-plugin",

      // Enhanced with LLMFeed discovery
      "llmfeed_url": "https://db.acme.com/.well-known/mcp.llmfeed.json",
      "signature_verified": true,
      "trust_level": "certified",

      "version": "1.2.0"
    }
  ]
}
```

**What this enables:**
- ✅ Marketplace provides curation
- ✅ LLMFeed provides verification
- ✅ Both systems work together
- ✅ Best of both approaches

---

## Industry Parallel: npm + CDNs

### npm Registry (Centralized)

```bash
npm install package-name
# → Downloads from npm registry
# → Centralized versioning
# → Package.json dependency management
```

### unpkg.com (Decentralized Web Access)

```html
<script src="https://unpkg.com/package-name"></script>
<!-- → Direct web access -->
<!-- → No npm install required -->
<!-- → Same package, different distribution -->
```

**The lesson:** Both distribution models coexist successfully.

**Agent ecosystem parallel:**
- Plugin Marketplace = npm install
- `.well-known/` = unpkg.com CDN access

---

## Developer Decision Tree

```
Are you building for:

┌─ Internal team only?
│  → Use Plugin Marketplace
│  → Centralized control
│  → Version enforcement
│
├─ Open web agents?
│  → Use .well-known/
│  → Global discovery
│  → Cryptographic trust
│
└─ Both?
   → Publish to .well-known/
   → Reference in marketplace
   → Best of both
```

---

## The Future: Universal Discovery

### Q1 2026: Marketplace Enhancement

```json
// Claude Code marketplace format v2
{
  "plugins": [
    {
      "discovery_method": "llmfeed",
      "url": "https://api.example.com/.well-known/mcp.llmfeed.json",
      "auto_verify": true
    }
  ]
}
```

**Marketplaces become curated pointers to .well-known/ feeds**

### Q2 2026: Cross-Platform Discovery

```javascript
// Universal agent discovery
const capabilities = await discover([
  'marketplace://acme-corp/plugins',      // Marketplace
  'https://api.example.com/.well-known/', // LLMFeed
  'openai://connector-registry/id',       // OpenAI AgentKit
]);

// Verify all sources cryptographically
const verified = await Promise.all(
  capabilities.map(verifySignature)
);
```

**All discovery methods work together**

### Q3 2026: Hybrid Ecosystems

```
Developer workflow:
1. Create capability (universal format)
2. Sign with key (cryptographic trust)
3. Publish to .well-known/ (web discovery)
4. Submit to marketplaces (curated distribution)
5. Available everywhere (maximum reach)
```

**Single source, multiple distribution channels**

---

## Conclusion: Complementary Evolution

Anthropic's plugin marketplaces are **excellent** for what they solve:
- ✅ Team distribution
- ✅ Version control
- ✅ Enterprise approval
- ✅ Air-gapped environments

LLMFeed's `.well-known/` discovery is **essential** for what marketplaces can't solve:
- ✅ Web-scale discovery
- ✅ Decentralized publication
- ✅ Cross-platform compatibility
- ✅ Open innovation

**The thesis:**

> "Centralized registries curate. Decentralized discovery scales. Both are necessary for mature agent ecosystems."

**The opportunity:**

> "Build plugins that work in marketplaces AND publish via .well-known/. Maximum reach, maximum control."

**The future:**

> "Universal agent discovery across all distribution channels, unified by cryptographic trust."

---

## Getting Started

### For Plugin Developers

**Hybrid approach:**

1. Build your plugin
2. Create `.well-known/mcp.llmfeed.json`
3. Sign with your key
4. Submit to relevant marketplaces
5. Reference LLMFeed URL in marketplace entry

**Result:** Internal teams + external agents, maximum adoption.

### For Enterprises

**Progressive enhancement:**

1. Start with internal marketplace (control)
2. Publish `.well-known/` feeds (discovery)
3. Verify signatures (trust)
4. Enable both distribution paths (flexibility)

**Result:** Control + innovation, security + scale.

---

## Resources

- **Claude Code Plugins:** [docs.claude.com/plugin-marketplaces](https://docs.claude.com/en/docs/claude-code/plugin-marketplaces)
- **LLMFeed Discovery:** [wellknownmcp.org/spec/wellknown](https://wellknownmcp.org/spec)
- **RFC 8615:** [datatracker.ietf.org/doc/html/rfc8615](https://datatracker.ietf.org/doc/html/rfc8615)
- **Implementation Guide:** [wellknownmcp.org/tools](https://wellknownmcp.org/tools)

---

**Marketplaces curate. .well-known/ scales.**

**Together, they build ecosystems.**

**Choose both.**