OpenAI's Connector Registry + LLMFeed: The Complete Discovery Stack

At DevDay 2025, OpenAI announced AgentKit's Connector Registry—a unified admin panel for managing agent data sources across ChatGPT and API.

On the surface, this looks like "just another enterprise feature."

But look closer: It's the missing piece that makes LLMFeed's web discovery enterprise-ready.

Here's why they're better together than either alone.

What OpenAI's Connector Registry Solves

The Enterprise Data Access Problem

Before Connector Registry:

Agent needs data from:
- Dropbox (personal account)
- Google Drive (company account)
- SharePoint (team sites)
- Microsoft Teams (multiple workspaces)
- Internal APIs (various auth methods)

Each requires separate:
- Authentication setup
- Permission configuration
- Security review
- Maintenance overhead

Result: Integration nightmare for enterprise deployments.

The Connector Registry Solution

Unified Admin Panel:

┌────────────────────────────────────────┐
│  CONNECTOR REGISTRY                    │
├────────────────────────────────────────┤
│  ✓ Dropbox          [Connected]       │
│  ✓ Google Drive     [Connected]       │
│  ✓ SharePoint       [Connected]       │
│  ✓ MS Teams         [Connected]       │
│  ✓ Internal CRM     [Pending Review]  │
│  + Add Connector...                    │
└────────────────────────────────────────┘

Key Features:

1. Consolidation

• All data sources in one panel
• Single configuration point
• Unified permissions model

2. Pre-built Connectors

• Dropbox
• Google Drive
• SharePoint
• Microsoft Teams
• More coming

3. Third-Party MCP Support

• Custom APIs
• Internal systems
• Proprietary tools

4. Cross-Platform Consistency

• Works in ChatGPT Enterprise
• Works via OpenAI API
• Same connectors, everywhere

What Connector Registry Doesn't Solve

The Discovery Problem

Scenario: You want to connect to a new SaaS tool.

With Connector Registry:

Step 1: Wait for OpenAI to build connector
Step 2: Hope it gets approved for enterprise
Step 3: Admin configures in registry
Step 4: Users can access

Timeline: Weeks to months

What if the connector doesn't exist yet? What if it's a niche internal tool? What if you need it NOW?

The Custom Integration Problem

You need to connect to:

• Your company's internal analytics platform
• A partner's proprietary API
• A regional SaaS tool not in OpenAI's list
• An experimental service still in beta

Connector Registry approach:

• Build custom MCP connector
• Configure in admin panel
• Limited to your organization

What if:

• Other companies need the same connector?
• The SaaS vendor wants to publish their own?
• You want cross-platform compatibility?

What LLMFeed Adds to the Stack

Web-Scale Connector Discovery

LLMFeed approach: Let any service publish their own connection spec.

json
// SaaS vendor publishes at:
// https://analytics.example.com/.well-known/mcp.llmfeed.json
{
  "feed_type": "mcp",
  "metadata": {
    "title": "Analytics Platform API",
    "origin": "https://analytics.example.com",
    "description": "Real-time analytics and reporting"
  },
  "capabilities": [
    {
      "name": "generate_report",
      "method": "POST",
      "path": "/api/v1/reports",
      "description": "Generate custom analytics report"
    },
    {
      "name": "query_data",
      "method": "GET",
      "path": "/api/v1/query",
      "description": "Query real-time analytics data"
    }
  ],
  "authentication": {
    "type": "bearer",
    "endpoint": "/api/v1/auth",
    "scope": "read:analytics write:reports"
  },
  "trust": {
    "signed_blocks": ["capabilities", "authentication"],
    "certifier": "https://llmca.org"
  },
  "signature": {
    "value": "cryptographic_proof",
    "created_at": "2025-10-12T10:00:00Z"
  }
}

Now:

• ✅ Any agent can discover this connector
• ✅ Any platform can use it (not just OpenAI)
• ✅ Vendor maintains it (not waiting for OpenAI)
• ✅ Cryptographically verified (signatures)
• ✅ Instantly available (no approval delay)

The Complete Stack: Registry + Discovery

Layer 1: Web Discovery (LLMFeed)

Purpose: Universal connector discovery

javascript
// Agent discovers connectors via .well-known/
const connectors = await discoverConnectors([
  'https://analytics.example.com/.well-known/mcp.llmfeed.json',
  'https://crm.vendor.com/.well-known/capabilities.llmfeed.json',
  'https://erp.internal.company/.well-known/mcp.llmfeed.json'
]);

// Verify signatures
const verified = await verifySignatures(connectors);

Benefit: Decentralized, vendor-published, web-scale

Layer 2: Admin Registration (Connector Registry)

Purpose: Enterprise approval & configuration

Admin workflow:
1. Discovery: Agent finds connector via .well-known/
2. Review: Security team validates connector
3. Configure: Admin adds to Connector Registry
4. Deploy: Available to all enterprise users

Benefit: Centralized control, security gate, compliance

Layer 3: Runtime Access (AgentKit)

Purpose: Execution & orchestration

Agent workflow:
1. Discovers connector (LLMFeed)
2. Checks registry approval (Connector Registry)
3. Executes via AgentKit (orchestration)
4. Logs to session feed (audit trail)

Benefit: Secure execution, full observability

Real-World Integration Example

Scenario: Enterprise Deploys New Analytics Tool

Traditional approach (Registry only):

Week 1: Request OpenAI build connector
Week 4: OpenAI prioritizes request (maybe)
Week 12: Connector released (if approved)
Week 13: Admin configures in registry
Week 14: Users can access

Timeline: 3+ months

LLMFeed + Registry approach:

Day 1:  Analytics vendor publishes /.well-known/mcp.llmfeed.json
        → Instantly discoverable by all agents

Day 2:  Agent discovers connector automatically
        → Security team reviews feed signature

Day 3:  Admin approves in Connector Registry
        → Available to enterprise users

Day 4:  Users access via ChatGPT & API
        → Full integration complete

Timeline: 4 days

Time saved: 3 months → 4 days

Technical Architecture

The Complete Flow

┌─────────────────────────────────────────────────┐
│  VENDOR PUBLISHES                               │
├─────────────────────────────────────────────────┤
│  1. Creates /.well-known/mcp.llmfeed.json       │
│  2. Signs with vendor key                       │
│  3. Gets LLMCA certified                        │
│  4. Publishes to web                            │
└──────────────┬──────────────────────────────────┘
               │
               ↓
┌─────────────────────────────────────────────────┐
│  AGENT DISCOVERS (LLMFeed)                      │
├─────────────────────────────────────────────────┤
│  • Fetches .well-known/mcp.llmfeed.json         │
│  • Verifies signature                           │
│  • Checks trust level                           │
│  • Presents to user/admin                       │
└──────────────┬──────────────────────────────────┘
               │
               ↓
┌─────────────────────────────────────────────────┐
│  ADMIN APPROVES (Connector Registry)            │
├─────────────────────────────────────────────────┤
│  • Reviews connector capabilities               │
│  • Validates security compliance                │
│  • Adds to approved registry                    │
│  • Configures org-wide access                   │
└──────────────┬──────────────────────────────────┘
               │
               ↓
┌─────────────────────────────────────────────────┐
│  USERS ACCESS (AgentKit + ChatGPT)              │
├─────────────────────────────────────────────────┤
│  • Connector appears in available tools         │
│  • Authentication via registry config           │
│  • Execution via AgentKit orchestration         │
│  • Audit trail in session feeds                 │
└─────────────────────────────────────────────────┘

The Hybrid Connector Model

Pre-built Connectors (OpenAI)

Examples:

• Dropbox
• Google Drive
• SharePoint
• Microsoft Teams

Characteristics:

• ✅ Built by OpenAI
• ✅ Deeply integrated
• ✅ Automatically updated
• ❌ Limited to OpenAI's roadmap

LLMFeed enhancement:

json
// Even pre-built connectors publish feeds
{
  "connector": "google-drive",
  "vendor_feed": "https://drive.google.com/.well-known/mcp.llmfeed.json",
  "verified": true,
  "trust_level": "certified"
}

Benefit: Verification even for pre-built connectors

Third-Party MCPs (Custom)

Examples:

• Internal company APIs
• Regional SaaS tools
• Experimental services
• Partner integrations

Characteristics:

• ✅ Built by anyone
• ✅ Vendor-maintained
• ✅ Flexible deployment
• ❌ Requires manual registry addition

LLMFeed enhancement:

json
// Vendor publishes feed themselves
{
  "feed_type": "mcp",
  "vendor_maintained": true,
  "update_channel": "https://vendor.com/.well-known/mcp.llmfeed.json",
  "auto_discovery": true
}

Benefit: Automatic updates from vendor

Enterprise Security Benefits

1. Signature Verification

Without LLMFeed:

Admin sees: "Custom MCP Connector"
Questions:  Is this legitimate?
           Who built it?
           Has it been tampered with?

Decision: Trust the submission

With LLMFeed:

Admin sees: "Analytics Platform Connector"
Verification: ✅ Signature valid
             ✅ Vendor: analytics.example.com
             ✅ LLMCA certified
             ✅ Last updated: 2 days ago

Decision: Trust the cryptography

2. Provenance Tracking

Session feed with connector provenance:

json
{
  "feed_type": "session",
  "actions": [
    {
      "action": "data_query",
      "connector": "analytics-platform",
      "source": "https://analytics.example.com/.well-known/mcp.llmfeed.json",
      "verified": true,
      "trust_level": "certified",
      "timestamp": "2025-10-12T14:30:00Z"
    }
  ],
  "trust": {
    "complete_audit_trail": true,
    "all_sources_verified": true
  }
}

Benefit: Complete audit trail for compliance

3. Supply Chain Security

Problem: Compromised connector

Without verification:

Attacker updates connector code
→ No detection mechanism
→ Enterprise uses compromised version
→ Security breach

With LLMFeed verification:

Attacker updates connector code
→ Signature verification fails
→ Alert: "Connector signature invalid"
→ Automatic block until re-verified
→ Breach prevented

Developer Integration Guide

Publishing a Connector (Vendor Side)

Step 1: Create MCP feed

json
// /.well-known/mcp.llmfeed.json
{
  "feed_type": "mcp",
  "metadata": {
    "title": "Your Service Name",
    "origin": "https://yourservice.com"
  },
  "capabilities": [
    {
      "name": "your_api_action",
      "method": "POST",
      "path": "/api/v1/action"
    }
  ],
  "authentication": {
    "type": "oauth2",
    "authorize_url": "/oauth/authorize",
    "token_url": "/oauth/token"
  }
}

Step 2: Sign the feed

bash
llmfeed sign .well-known/mcp.llmfeed.json --key=your-private-key

Step 3: Get certified (optional)

bash
llmfeed certify .well-known/mcp.llmfeed.json --certifier=llmca.org

Step 4: Deploy

bash
# Deploy to your web server
# Now discoverable at: https://yourservice.com/.well-known/mcp.llmfeed.json

Consuming a Connector (Enterprise Side)

Step 1: Discovery

javascript
// Agent discovers connector
const connector = await fetch('https://service.com/.well-known/mcp.llmfeed.json');

Step 2: Verification

javascript
// Verify signature
const isValid = await verifySignature(connector);
const trustLevel = await checkCertification(connector);

Step 3: Registry Addition

javascript
// Admin adds to Connector Registry
await addToRegistry({
  name: connector.metadata.title,
  source: connector,
  trust_level: trustLevel,
  approved_by: 'security-team'
});

Step 4: Usage

javascript
// Users access via AgentKit
const result = await agent.execute({
  connector: 'service-name',
  action: 'your_api_action',
  params: { /* ... */ }
});

Cross-Platform Compatibility

The Universal Connector Model

A well-designed connector works everywhere:

json
{
  "feed_type": "mcp",
  "platforms": {
    "openai": {
      "connector_registry": "compatible",
      "apps_sdk": "compatible"
    },
    "anthropic": {
      "claude_code": "compatible",
      "mcp_standard": "native"
    },
    "other": {
      "discovery": "/.well-known/",
      "verification": "signature_required"
    }
  }
}

Single connector definition, works across:

• ✅ OpenAI Connector Registry
• ✅ Anthropic Claude Code
• ✅ Any MCP-compatible agent
• ✅ Custom implementations

The Complete Discovery Stack

Layer 5: USER INTERFACE
         └─ ChatGPT, Claude, Custom UIs

Layer 4: ORCHESTRATION
         └─ AgentKit Builder, Agent Logic

Layer 3: CONNECTOR REGISTRY (OpenAI)
         └─ Approved connectors, Admin panel

Layer 2: WEB DISCOVERY (LLMFeed)
         └─ /.well-known/ feeds, Signatures

Layer 1: SERVICES & APIs
         └─ Actual data sources

Each layer is necessary:

• Layer 1: Where the data lives
• Layer 2: How agents find it
• Layer 3: How enterprises approve it
• Layer 4: How agents use it
• Layer 5: How humans interact

Remove any layer, system breaks.

Migration Strategy

For Existing Registry Users

Progressive enhancement:

Week 1: Publish /.well-known/ feeds for existing connectors
        → Enable cross-platform discovery

Week 2: Add signature verification
        → Cryptographic trust layer

Week 3: Reference feeds in registry
        → Single source of truth

Week 4: Enable auto-updates from feeds
        → Vendor-maintained connectors

Result: Registry + discovery, maximum flexibility

For New Deployments

Start with both:

Day 1: Vendor publishes /.well-known/ feed
       → Web discovery ready

Day 2: Enterprise discovers via agents
       → Automatic presentation

Day 3: Admin reviews and approves
       → Registry configuration

Day 4: Users access via platform
       → Full integration

Result: 4-day deployment vs 3-month wait

The Business Case

Cost Comparison

Traditional approach:

Custom connector development:  $50k-$150k
Maintenance per year:          $20k-$40k
OpenAI connector request:      3-12 month wait
Integration effort:            80-200 hours

Total first-year cost:         $70k-$190k

LLMFeed + Registry approach:

Vendor publishes feed:         $5k-$10k (one-time)
Signature setup:               $1k
Registry configuration:        4-8 hours
Ongoing maintenance:           Vendor-handled

Total first-year cost:         $6k-$11k
Savings:                       $64k-$179k per connector

ROI for 10 connectors: $640k - $1.79M saved

Conclusion: Better Together

OpenAI's Connector Registry is brilliant for:

• ✅ Enterprise control
• ✅ Unified admin panel
• ✅ Pre-built connectors
• ✅ Security approval flow

LLMFeed's

.well-known/

• ✅ Vendor self-publication
• ✅ Web-scale discovery
• ✅ Cryptographic verification
• ✅ Cross-platform compatibility

Together, they create:

Universal Discovery (LLMFeed)
  + Enterprise Control (Connector Registry)
  + Cryptographic Trust (Signatures)
  = Complete Agent Connectivity Stack

The opportunity:

"Publish once with LLMFeed, consume everywhere via Connector Registry."

The future:

"Every service has a /.well-known/ feed. Every registry references them. All agents discover everything."

Getting Started

For Vendors

1. Publish

   /.well-known/mcp.llmfeed.json

2. Sign with your key
3. Get LLMCA certified
4. Submit to OpenAI Connector Registry (reference your feed)

For Enterprises

1. Discover connectors via agents
2. Verify signatures
3. Approve in Connector Registry
4. Deploy to users

For Platforms

1. Support

   .well-known/

   discovery
2. Integrate with Connector Registry
3. Verify signatures automatically
4. Enable vendor-maintained connectors

Resources

• AgentKit Connector Registry: openai.com/agentkit
• LLMFeed Discovery: wellknownmcp.org/spec/wellknown
• Implementation Guide: wellknownmcp.org/tools
• LLMCA Certification: llmca.org

Discovery finds connectors.

Registry approves them.

Trust verifies them.

Together, they enable agent-to-data connectivity at every scale.

The complete stack is here.