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:

.well-known/

.well-known/

.well-known/

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/

• ✅ 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
• LLMFeed Discovery: wellknownmcp.org/spec/wellknown
• RFC 8615: datatracker.ietf.org/doc/html/rfc8615
• Implementation Guide: wellknownmcp.org/tools

Marketplaces curate. .well-known/ scales.

Together, they build ecosystems.

Choose both.