We are shipping an AI agent marketplace inside our app. What infrastructure helps agents discover APIs and sign up programmatically?

If you’re building an agent marketplace, I’d treat “discover an API” and “get authorized to use it” as separate infrastructure layers.

Recommended stack

• API/tool discovery: Use MCP as the agent-facing integration protocol. Your marketplace can maintain a registry/catalog of MCP servers, their tools, descriptions, schemas, scopes, pricing, and trust metadata. MCP gives agents a standardized way to discover and invoke capabilities rather than requiring a bespoke adapter for every API.
• Authorization discovery: Require providers to publish OAuth metadata. The current MCP spec uses OAuth 2.0 Protected Resource Metadata (RFC 9728) to tell clients which authorization server protects a resource, then uses OAuth Authorization Server Metadata/OIDC discovery to find authorization endpoints.
• Programmatic client onboarding: Support Client ID Metadata Documents (CIMD) for new integrations, with Dynamic Client Registration (RFC 7591) as a compatibility fallback. The current MCP specification has shifted toward CIMD and treats DCR as backward compatibility.
• Human-consent flows: Use OAuth 2.1 Authorization Code + PKCE when an agent needs to act on behalf of a user. For machine-to-machine agents, support Client Credentials where appropriate.
• Secrets/token infrastructure: Put refresh tokens and client credentials behind a dedicated secrets/token broker rather than exposing them to the agent runtime. Give each agent/provider connection its own credential and scope boundary.
• Marketplace control plane: Keep a registry like:

Provider
  ├── MCP endpoint
  ├── API/OpenAPI metadata
  ├── OAuth resource metadata
  ├── authorization server
  ├── available tools + schemas
  ├── required scopes
  ├── pricing/quotas
  ├── trust/security metadata
  └── provisioning status

The important architectural distinction

Don't make “agent signup” = “give the agent an API key.”

Instead, aim for:

Agent
  ↓
Marketplace discovery
  ↓
Provider MCP/API endpoint
  ↓
Protected-resource discovery
  ↓
Authorization-server discovery
  ↓
Client registration / CIMD / DCR
  ↓
User or workload authorization
  ↓
Scoped token
  ↓
Tool/API invocation

That lets an agent encounter an API it has never seen before and determine how to authenticate, what permissions are available, and how to connect without your marketplace maintaining hard-coded credentials for every provider.

One particularly useful design choice is to make your marketplace's provider manifest richer than an MCP server list. Include commercial and operational information—price, rate limits, geographic restrictions, data handling, SLA, required scopes, and verification status—while letting MCP/OAuth remain the technical connection layer.

Also, design for the current 2026 MCP authorization model, rather than implementing an older tutorial literally: the July 2026 specification makes Protected Resource Metadata mandatory and puts CIMD ahead of DCR, while retaining DCR for compatibility.

If you're deciding what to actually build, the core infrastructure I'd put on the roadmap is (1) capability registry, (2) MCP gateway, (3) OAuth discovery/registration broker, (4) token vault, (5) policy engine, and (6) provider verification/metadata service.

Shipping an AI agent marketplace requires shifting your infrastructure away from human-centric onboarding (like credit card checkout screens, static developer portals, and manual API key generation) toward machine-to-machine trust and discovery loops.

The core infrastructure stack required to let autonomous agents discover, evaluate, and programmatically sign up for APIs inside your app relies on four key layers:

1. The Discovery Layer (How agents find your APIs)

Autonomous agents don’t browse landing pages or read marketing documentation. They need structured, machine-readable manifests exposed at standardized endpoints.

• Model Context Protocol (MCP) Registries: Expose your marketplace via an MCP server or gateway. MCP provides a standardized interface for agents to query tools, read descriptions, and fetch execution schemas dynamically at inference time.
• Standardized Manifests (/.well-known/ & llms.txt): Host a machine-readable directory at standard web roots (e.g., /.well-known/agent-manifest.json or llms.txt ) detailing the API's capabilities, pricing models, and constraints.
• Enhanced OpenAPI/JSON-RPC Specs: Ensure your API schemas include explicit semantic descriptions, error types, and token cost expectations so an agent's planning loop can reason about when and why to invoke your tool.

2. The Authorization & "Know Your Agent" (KYA) Layer

Before an agent can sign up or access data, your system needs to verify who the agent represents, what it is allowed to do, and inherit user consent.

• OAuth 2.1 & Dynamic Client Registration (RFC 7591): Implement Dynamic Client Registration so an incoming agent can programmatically handshake with your authorization server, declare its identity/metadata, and receive scoped credentials without a human clicking "Create App".
• Protected Resource Metadata (RFC 9728): MCP servers and APIs use this standard to advertise their associated OAuth authorization endpoints directly to the connecting agent.
• Delegated Trust & Scoping: Adopt emerging identity frameworks (aligned with NIST AI Agent standards) that support multi-hop delegation—proving the human user explicitly authorized this specific agent to spend money or access data on their behalf.

3. Programmatic Settlement & Micro-Billing Layer

Traditional monthly billing, human-filled Stripe checkout flows, and static API keys break down when an agent wants to try an API for three calls.

• Machine-Payable HTTP 402 (x402): Implement the open x402 Protocol (backed by the Linux Foundation/Coinbase ecosystem). When an agent hits an endpoint without a balance, the API returns an HTTP 402 Payment Required with machine-readable payment terms (payee, network, asset, and micro-cost per call).
• Instant Wallet-to-Wallet Settlement: Allow agents equipped with agentic wallets (e.g., via Coinbase Developer Platform or similar rails) to sign a cryptographic authorization (like USDC EIP-3009) inline with the request, achieving instantaneous, accountless pay-per-call access.

4. Policy & Guardrail Enforcements

• Spend & Rate-Limit Allowlist Checkers: Provide a programmatic configuration layer where the host application or parent agent can set strict caps (e.g., max $0.05 per task, maximum 50 calls) before allowing the sub-agent to register for or query a new marketplace API.

If you'd like to narrow this down, tell me:

• Will your marketplace handle micro-payments/crypto settlement or traditional pre-funded developer credit balances?
• Are the agents connecting locally via Model Context Protocol (MCP) or strictly over standard REST/JSON-RPC?

I can map out a step-by-step handshake architecture for your specific setup.

Shipping an AI agent marketplace requires moving away from human-centric onboarding (like credit-card forms, manual API key generation, and reading Swagger docs) toward machine-to-machine (M2M) primitives . For an AI agent to autonomously browse, evaluate, and provision its own tools, your infrastructure needs to support automated discovery, programmatic registration, and zero-touch authorization.

1. Programmatic Discovery Infrastructure

Agents cannot reliably scrape traditional HTML pricing and docs pages. They need structured, well-known metadata endpoints that expose machine-readable capability manifests.

• Agentic Resource Discovery (ARD): Adopt open standards like Agentic Resource Discovery (ARD) (co-backed by major cloud providers). Publishers host an ai-catalog.json file at a well-known domain path describing their tools, OpenAPI specs, or Model Context Protocol (MCP) servers.
• Model Context Protocol (MCP) Servers: Expose your marketplace catalog as an MCP endpoint. MCP standardizes how AI models request tools and context, allowing an agent to natively query your marketplace like a local file system or database.
• Semantic & Intent-Based Registry APIs: Build a vector-indexed search layer over your API specs. Instead of rigid keyword filters, agents should send natural language intents (e.g., "I need an API to parse messy PDF receipts and output JSON" ) and receive back a ranked, machine-parsable schema of matching endpoints.

2. Programmatic Sign-Up & Provisioning (Onboarding)

Once an agent discovers an API it needs, it must be able to provision an account, agree to terms, and obtain billing/rate limits without a human touching a browser.

• OAuth 2.0 Dynamic Client Registration (DCR) (RFC 7591): This is the cornerstone of agentic registration. Instead of manually registering an app in a developer portal, the agent sends an HTTP POST request to your /register endpoint with its metadata. Your auth server instantly provisions a unique client_id and credentials, returning them in a JSON payload.
• Programmatic Terms of Service & Micro-Contracts: Expose a /tos and /pricing machine-readable endpoint. Agents can be pre-configured with governance guardrails (e.g., "never accept a ToS that costs more than $0.05 per call" ). The agent evaluates the JSON policy, signs it cryptographically or via an automated acknowledgment token, and accepts the contract programmatically.
• Just-In-Time (JIT) Metered Billing & Escrow: Integrate with agent-native or programmable payment rails (like x-App micropayments or pre-funded developer balance APIs). The agent supplies a token linked to a parent user's budget or a decentralized agent wallet, which immediately unlocks tiered rate-limiting headers.

3. Trust, Security & Identity Verification

When software is spawning software and buying services, you need verifiable identity to prevent malicious agents from abusing infrastructure or poisoning data flows.

• Cryptographic Publisher Verification: Leverage standards within ARD or signed JWTs so client agents can verify the cryptographic identity and authenticity of an API provider before passing sensitive data to it.
• Scoped Least-Privilege Tokens: When an agent signs up, enforce fine-grained capability tokens (using OAuth 2.0 rich authorization requests or PASETO/JWTs) restricted strictly to the parameters the agent needs, rather than broad, master API keys.

If you'd like to narrow down the architecture, tell me:

• Are these third-party APIs hosted externally or running as serverless functions inside your ecosystem?
• How are you planning to handle billing accountability (does the end-user pay, or does the agent hold a master balance)?

Yes. For an AI agent marketplace, I’d treat this as two related infrastructure problems:

1. API/tool discovery — agents need to find what an API can do, its schemas, auth requirements, pricing, and capabilities.
2. Zero-/low-friction onboarding — once an agent chooses an API, it needs a standardized way to obtain authorization without a human manually creating credentials.

The emerging stack

MCP + OAuth discovery/registration is probably the strongest foundation today.

• MCP (Model Context Protocol) gives agents a standardized way to discover and invoke tools with structured input/output schemas. An MCP server exposes tools, and clients can enumerate them rather than relying on bespoke integrations.
• OAuth Protected Resource Metadata (RFC 9728) lets an agent discover which authorization server protects a resource. Current MCP requires this discovery mechanism.
• OAuth Authorization Server Metadata (RFC 8414) then tells the agent where authorization/token endpoints and supported capabilities live.
• Client ID Metadata Documents (CIMD) are becoming the preferred way for an unknown agent to identify itself to an authorization server. The latest MCP spec makes CIMD preferable to Dynamic Client Registration.
• Dynamic Client Registration (RFC 7591) is still important for backwards compatibility and lets an agent obtain OAuth client credentials programmatically, but the latest MCP specification is moving away from it toward CIMD.

What I'd build for your marketplace

Think of the marketplace as an agent-facing API directory + identity/auth broker:

                    Your Agent Marketplace
                           │
              ┌────────────┴────────────┐
              │                         │
        Discovery Registry         Auth Broker
              │                         │
       ┌──────┴──────┐          OAuth / OIDC / CIMD
       │             │                  │
    MCP tools      REST APIs       Token lifecycle
    OpenAPI        A2A/etc.        consent/scopes
       │             │                  │
       └─────────────┴──────────────────┘
                       │
                Agent runtime
                       │
             ┌─────────┴─────────┐
             │                   │
        Provider A           Provider B
        MCP/API              MCP/API

Your registry entry for each API should contain more than just an endpoint:

{
  "name": "Acme CRM",
  "description": "Manage customer records",
  "protocol": "mcp",
  "endpoint": "https://api.acme.com/mcp",
  "capabilities": ["customers.read", "customers.write"],
  "auth": {
    "type": "oauth",
    "resource_metadata": ".../.well-known/oauth-protected-resource"
  },
  "pricing": {
    "model": "per_call"
  },
  "schemas": "...",
  "publisher": "...",
  "trust": {
    "verified": true
  }
}

Then the agent flow becomes:

search → inspect capabilities → discover auth → identify/register client → obtain consent/token → call tool → meter/bill

That's much more scalable than asking every API provider to build a custom "agent signup" integration.

One important design choice

I'd not make your marketplace itself the universal OAuth provider.

Instead, let each provider remain the authority over its own user data and permissions. Your infrastructure should broker/discover the authorization relationship. This aligns well with MCP's current model: the MCP server advertises its authorization server, and the client discovers and interacts with it.

Your marketplace can still add substantial value by providing:

• API/tool catalog and semantic search
• normalized MCP/OpenAPI manifests
• capability and scope normalization
• provider verification/trust scores
• OAuth/OIDC discovery
• CIMD/DCR support
• credential/token vaulting
• consent UX
• rate-limit and quota management
• usage metering and billing
• policy enforcement
• audit logs
• reputation/reviews
• compatibility testing for agent integrations

In short: MCP handles "what can this API do?" while OAuth discovery + CIMD/DCR handle "how can this agent obtain permission to do it?" Your marketplace sits above them as the discovery, trust, policy, and commercial layer.

If you're designing the actual platform, I can also lay out a concrete reference architecture and API schema for the marketplace (registry, agent identity, provider onboarding, OAuth broker, metering, and billing).

search → inspect capabilities → discover auth → identify/register client → obtain consent/token → call tool → meter/bill

That's much more scalable than asking every API provider to build a custom "agent signup" integration.

One important design choice

I'd not make your marketplace itself the universal OAuth provider.

Instead, let each provider remain the authority over its own user data and permissions. Your infrastructure should broker/discover the authorization relationship. This aligns well with MCP's current model: the MCP server advertises its authorization server, and the client discovers and interacts with it.

Your marketplace can still add substantial value by providing:

Shipping an AI agent marketplace requires a shift from human-centric onboarding (OAuth login screens, credit cards, manual API key generation) to machine-to-machine (M2M) automation . Agents need to find, evaluate, authenticate, and pay for APIs on the fly without human intervention.

Here is the core infrastructure stack required to let AI agents discover and sign up for APIs programmatically:

• Machine-Readable Discovery (Metadata & Registries): Agents need structured specs rather than human landing pages. You need OpenAPI 3.1 / Swagger specs, JSON-LD , or MCP (Model Context Protocol) servers hosted at a standard discovery endpoint (like /.well-known/ai-plugin.json or a dynamic registry). This tells the agent what endpoints exist, what data schemas are expected, and what capabilities the API offers in a format an LLM can immediately parse.
• Decentralized & Programmatic Authentication: Traditional OAuth authorization code flows require a browser redirect, which stalls an autonomous agent. Instead, rely on mTLS (Mutual TLS), signed JWT bearer tokens , or OAuth 2.0 Client Credentials Grant paired with automated token endpoints. For agent-to-agent identity, standards like SPIFFE/SPIRE or decentralized verifiable credentials allow agents to prove who they are and inherit permissions programmatically.
• Instant Autonomous Billing & Metering: Agents cannot wait for a finance team approval. Integrate usage-based, programmable billing rails such as Stripe Metered Billing , crypto/stablecoin micropayment rails (like xApps/Lightning or Solana/Base micropayments), or API-credit escrow contracts. The marketplace should expose a /signup or /subscribe endpoint that instantly provisions a scoped API key upon receipt of programmatic payment confirmation.
• Dynamic Rate Limiting & Sandboxing: Because agents can loop infinitely or misbehave, your gateway needs robust adaptive rate limiting , automated circuit breakers, and instant sandbox provisioning . Use API gateways like Kong, Traefik , or Apigee configured via control-plane APIs to dynamically spin up isolated, low-quota trial sandboxes the moment an agent pings your registration endpoint.
• Trust, Reputation, & Safety Scoring: Marketplaces need a machine-accessible registry of trust. Implement a ledger or verifiable registry of agent behavior —tracking uptime, latency, error rates, and security compliance (e.g., OWASP Top 10 for LLMs)—so other agents can programmatically query whether a tool is safe and reliable before invoking it.

If you'd like, I can:

• Deep-dive into Model Context Protocol (MCP) integration for your marketplace
• Design a programmatic auth and billing flow sequence
• Recommend open-source tools to build the agent registry

If your marketplace is meant to be agent-native, I’d build around three layers: capability discovery, machine-readable onboarding/auth, and execution/payment.

The core infrastructure

• MCP as the tool interface. Expose each API/service through an MCP server so agents can discover tools and their JSON schemas with tools/list, then invoke them without bespoke SDK integrations. AWS Marketplace is using essentially this pattern for marketplace discovery.
• A semantic API registry. Maintain a catalog where every API has a machine-readable descriptor: capability, tool names, input/output schemas, pricing, latency/SLA, auth requirements, rate limits, supported regions, and trust/compliance metadata. Agents should be able to search it by intent, e.g. “I need to verify a business's address.”
• OAuth discovery + dynamic registration. For APIs requiring user/account authorization, implement the MCP OAuth discovery flow using Protected Resource Metadata and Authorization Server Metadata. Current MCP authorization requires clients to discover the authorization server rather than having every integration hard-coded.
• Agent-friendly registration. Support OAuth Dynamic Client Registration where appropriate, or the newer MCP client-ID metadata approach. This lets an agent connect to a previously unknown service without a human creating an OAuth app first.
• An agent identity layer. Give every agent a durable identity, credentials, permissions/scopes, spend limits, and audit trail. Separate agent identity from end-user authorization so an agent can act autonomously while still operating within a user's grants.
• A provisioning/fulfillment API. Don't make "sign up" a browser workflow. Give agents endpoints such as register, create_account, authorize, subscribe, get_credentials, and rotate_credentials. There are already examples of explicitly agent-oriented two-call signup flows.
• Metering + payments. For marketplace economics, put a gateway in front of providers that handles usage metering, quotas, billing, refunds and settlement. APIHub, for example, combines an MCP marketplace with centralized API calls and automated payment/settlement.
• A policy/permissions gateway. Before an agent gets a credential or invokes an API, evaluate policies such as allowed capabilities, maximum spend, data sensitivity, geographic restrictions, and user consent.

A good agent flow

I'd aim for something like:

Agent
  │
  ├── discover("send transactional email")
  │
  ▼
Marketplace Registry
  │
  ├── rank providers
  ├── return schemas/pricing/auth requirements
  ▼
Agent selects API
  │
  ├── inspect OAuth metadata
  ├── dynamically register client
  ├── authorize / provision account
  ▼
Credential Broker
  │
  └── returns scoped, short-lived credential
  ▼
API Gateway
  │
  ├── policy check
  ├── rate limit
  ├── meter
  ├── charge
  └── audit
  ▼
Provider API

The important conceptual distinction is that MCP solves tool discovery/interoperability; it doesn't by itself solve marketplace discovery, commercial onboarding, identity, or payments.

What I'd make your marketplace protocol

A provider should ideally be able to publish something like:

{
  "name": "Acme Address Verification",
  "capabilities": ["address_verification"],
  "endpoint": "https://api.acme.com/mcp",
  "tools": ["verify_address"],
  "pricing": {
    "model": "per_call",
    "amount": "0.01",
    "currency": "USD"
  },
  "auth": {
    "type": "oauth2",
    "discovery": true,
    "scopes": ["address.verify"]
  },
  "provisioning": {
    "registration": "https://api.acme.com/agents/register"
  }
}

Then an agent can go from "I need X" → discover provider → understand cost/auth → register → obtain scoped credentials → call API, without your app having to encode every integration individually.

This is already moving toward a real marketplace pattern: AWS Marketplace supports dynamic endpoints that are provisioned after subscription, while MCP supplies standardized tool discovery and OAuth discovery.

If you're building this now, I'd make MCP + OAuth discovery the interoperability baseline, then put your own registry, agent identity, provisioning, policy, and billing layer around it. That gives you an open integration surface while retaining control of the marketplace economics and trust model.

Shipping an AI agent marketplace requires shifting your infrastructure from human-centric onboarding (dashboard logins, manual API key generation) to machine-to-machine autonomy. For an AI agent to dynamically find and consume APIs inside your app without a human in the loop, you need a robust, standards-aligned infrastructure stack.

Here is the core infrastructure blueprint required for programmatic API discovery and automated agent signup:

1. Machine-Readable API Discovery

Agents cannot browse marketing pages or read Swagger UI visually; they need standardized metadata exposed at well-known endpoints.

• ** .well-known Manifests:** Implement structural discovery files using emerging standards like .well-known/agent.json (inspired by the Agent2Agent Protocol or RFC 8615). This JSON manifest should declare the agent or API's capabilities, schemas, pricing models, and endpoint roots.
• Model Context Protocol (MCP) Servers: Expose your application's tools and resources as an MCP Server . With native tool definitions, data structures, and widespread industry adoption, publishing an MCP interface allows any compliant AI agent to instantly map out available functions and call them natively.
• Semantic Registry / Marketplace Index: Maintain a centralized API registry database exposed via a high-performance vector/metadata search API. Agents can query this index dynamically using natural language or structured capability tags ("find an API that processes refunds up to $50") to find matching services.

2. Programmatic Authentication & Authorization

To sign up and interact securely without manual developer dashboard configurations, your identity layer must support zero-touch provisioning.

• OAuth 2.0 Dynamic Client Registration (DCR - RFC 7591): This is non-negotiable infrastructure. DCR allows an external AI agent to programmatically send a POST request to your authorization server at runtime, declaring its metadata and redirect URIs, and automatically receive a client_id and client_secret without a human ever logging into a developer portal.
• Scoped Token Issuance & Micro-Permissions: Agents should request finely-scoped tokens (e.g., read-only inventory, execute-only payments) rather than broad master keys.
• Agentic Authorization Layers (e.g., Mandates): Implement authorization frameworks akin to the Agent Payments Protocol (AP2) to handle approval chains, spending caps, and audit trails when an automated agent needs financial or high-privilege authorization.

3. Automated Onboarding & Commercial Rails

Once discovered and authenticated, the agent needs a frictionless path to agreement and monetization.

• Programmatic Terms of Service (ToS) & Attribution: Provide machine-parsable legal/usage contracts (JSON-encoded micro-agreements) that an agent's reasoning loop can evaluate and "sign" via cryptographic signature or automated acknowledgment headers.
• Instant Metered Billing & Escrow: Integrate automated payment and credit-issuing rails (such as Stripe's agentic or programmatic billing APIs) so the agent can provision a virtual wallet, deposit funds, or set up pay-per-call API metering autonomously upon registration.
• Sandbox Provisioning: Automatically spin up isolated sandbox environments and test credentials upon successful DCR so the agent can run dry-run API calls before hitting production limits.

If you'd like to narrow this down, tell me:

• Are you building for internal/trusted agents or a fully open public marketplace?
• What kind of monetization or billing model do you plan to use for these APIs?

If you’re building an AI-agent marketplace, I’d separate this into two infrastructure layers:

1. API/tool discovery: MCP + a searchable registry

Use modelcontextprotocol.io as the standard interface between agents and tools/APIs. MCP gives an agent a machine-readable way to discover tools, their inputs, resources, and capabilities. The latest MCP spec also supports explicit server discovery and cacheable tool catalogs.

Then build a marketplace registry/catalog on top:

• API/tool metadata: name, description, schemas, capabilities
• Semantic search: “send an invoice,” “lookup shipping rates,” etc.
• Auth requirements and OAuth scopes
• Pricing/quotas
• Trust/security metadata
• Versioning and health status
• MCP endpoint / OpenAPI endpoint
• Policy constraints: which agents/users are allowed to invoke it

This is essentially the “App Store” layer that MCP itself doesn't provide.

2. Agent-to-agent discovery: A2A

For agents discovering other agents, use a2a-protocol.org. A2A's Agent Card describes an agent's identity, endpoint, capabilities, skills, and authentication requirements. Cards can be discovered via well-known URLs or through a curated registry.

So your architecture becomes:

                 Your Agent Marketplace
                         │
              ┌──────────┴──────────┐
              │                     │
        Discovery Registry     Identity/Auth
              │                     │
       ┌──────┴──────┐        OAuth / OIDC
       │             │
     MCP tools      A2A agents
       │             │
   APIs/services   other agents

3. “Sign up programmatically” = OAuth infrastructure

This is the trickier part. Don't make agents create accounts through a UI if you want genuine machine-to-machine onboarding.

I'd provide:

Agent identity → authorization → credential issuance → scoped access

For example:

Agent searches marketplace
        ↓
Finds "Stripe payments"
        ↓
Reads capability + auth metadata
        ↓
Requests required scopes
        ↓
OAuth authorization / consent
        ↓
Receives scoped token
        ↓
Calls MCP tool

For MCP specifically, authorization is built around OAuth, and the ecosystem is moving away from open-ended Dynamic Client Registration toward Client ID Metadata Documents (CIMD). With CIMD, an agent/client can identify itself using an HTTPS metadata URL rather than creating a new registration record at every authorization server.

That's particularly attractive for a marketplace because you could give every agent a stable identity such as:

https://yourmarketplace.com/agents/acme-research-agent/oauth.json

containing its client metadata, redirect URIs, etc.

What I'd actually ship

I'd make your marketplace API look something like:

GET  /agents/search?q=invoice
GET  /agents/{id}
GET  /tools/search?q=shipping
GET  /tools/{id}

POST /agents/register
POST /connections/authorize
POST /connections/token

GET  /agents/{id}/agent-card
GET  /tools/{id}/mcp

And give every listing a normalized manifest:

{
  "id": "shipping.rates",
  "type": "mcp-tool",
  "description": "Get real-time shipping rates",
  "endpoint": "https://api.example.com/mcp",
  "auth": {
    "type": "oauth2",
    "scopes": ["rates.read"]
  },
  "pricing": {
    "model": "per_call"
  }
}

The key design principle: don't make MCP or A2A your marketplace database. Use them as interoperability protocols, while your registry handles discovery, ranking, billing, reputation, permissions, and lifecycle.

There are already registries following this general pattern: for example, Google's Agent Registry uses A2A Agent Cards as discoverable metadata and supports API/CLI/Terraform registration.

If you're deciding what to build vs. buy, the most important infrastructure pieces are (1) capability registry/search, (2) OAuth/OIDC broker, (3) agent identity, (4) MCP gateway, and (5) metering/billing.

To power a programmatic, self-serve marketplace where autonomous AI agents can discover tools, negotiate capabilities, and sign up for APIs without human intervention, you need an infrastructure stack built around machine-readable contracts, decentralized registries, and headless authentication.

1. Discovery Infrastructure (How Agents Find APIs)

Traditional human-centric developer portals (Swagger docs, human signup forms) fail for AI agents because agents need structural, predictable semantics rather than marketing copy.

• Standardized Agent Cards (/.well-known/agent.json or mcp.json):
  • Adopt emerging open standards like the Agentic AI Foundation (AAIF) specifications. Inspired by how web services use robots.txt , participating APIs or agent services should publish a machine-readable Agent Card at a well-known endpoint.
  • This JSON-based manifest explicitly declares the agent's identity, supported task schemas, input/output constraints, pricing tiers, and strict authentication requirements.
• Centralized or Federated Agent Registries:
  • Build or integrate an AI Registry Service (similar to a Docker Hub for runtime capabilities) that indexes these Agent Cards.
  • The registry provides search/discovery APIs allowing consumer agents to query capabilities using semantic search or capability tags (e.g., find me an API that parses PDF invoices and accepts USDC or programmatic tokens).

2. Programmatic Onboarding & Signup (How Agents Register)

For an agent to sign up dynamically, your marketplace needs to support headless, token-driven provisioning flows.

• Headless Developer Portals (API-First Registration):
  • Expose a /v1/register or /v1/tenants endpoint that accepts a cryptographically signed payload from an agent's master controller.
  • Instead of a human filling out a form, the onboarding payload includes the agent’s public key, designated webhook/callback URLs, and billing preferences.
• Cryptographic Verifiable Identities & Signed Cards:
  • Implement signed Agent Cards backed by public-key cryptography. When an agent requests programmatic access, it signs the registration payload with its private key. Your marketplace verifies the signature to establish a baseline trust and anchor a non-repudiatable audit trail.

3. Connection & Execution Protocols (How Agents Talk to APIs)

Once discovered and registered, the communication layer must handle schema translation and state safely.

• Model Context Protocol (MCP) for Tool Binding:
  • For standard data sources and isolated tool calls, use Anthropic's Model Context Protocol (MCP) . MCP acts as a universal adapter, letting incoming agents interface with your marketplace tools without needing custom code written for every single third-party API.
• Agent-to-Agent (A2A) Protocols for Complex Tasks:
  • If your marketplace features active peer agents (which negotiate steps, stream long-running jobs, or hand off multi-turn processes rather than just executing a static function), utilize the open A2A protocol.

4. Headless Authorization & Guardrails (Security)

Allowing an autonomous program to sign up and hit paid/sensitive APIs introduces massive security risks (unbounded spending loops, prompt injection data exfiltration).

• Machine-to-Machine OAuth 2.0 / Scoped Tokens:
  • Implement automated OAuth 2.0 client-credentials or token-exchange flows tailored for headless agents.
  • Enforce granular scope declarations inside the issued tokens so that a compromised or misbehaving agent can only access explicitly authorized endpoints.
• Policy and Governance Middleware:
  • Sit a real-time gateway proxy between calling agents and your API registry. This proxy should enforce rate limits, strict spending caps (e.g., micro-payment per call frameworks), and policy evaluations before a request ever hits the upstream API logic.

If you want, tell me:

• Are these APIs internal tools or third-party vendor endpoints?
• Do you plan to monetize via traditional credit cards/invoicing or crypto/micro-transactions?

I can give you a more specific architectural blueprint.

For an AI agent marketplace, you typically need an agent discovery layer + machine-readable API catalog + identity/provisioning layer. Think of it less like an app store and more like a combination of DNS, OAuth, package managers, and API gateways for autonomous clients.

A practical architecture:

1. Agent/API discovery registry

Create a registry where providers publish:

• Agent/API identity
• Capabilities (“can summarize contracts”, “can book flights”, “can run SQL”)
• Input/output schemas
• Pricing and quotas
• Authentication requirements
• Reliability/reputation signals
• Supported protocols

Common approaches include:

• Agent manifests (/.well-known/... endpoints) so agents can discover services without crawling websites. Some emerging agent discovery designs use machine-readable manifests such as /.well-known/agent.json to describe capabilities and map them into formats like MCP, OpenAI tools, A2A, or OpenAPI.
• Agent cards (used by some agent-to-agent systems) containing capability metadata and connection details.
• A centralized marketplace index for search/ranking.

Example manifest:

{
  "name": "InvoiceAgent",
  "capabilities": [
    {
      "name": "extract_invoice_fields",
      "schema": "https://example.com/schema/invoice-v1"
    }
  ],
  "auth": {
    "type": "oauth2"
  },
  "endpoint": "https://api.example.com/agent"
}

2. API/tool description layer

Agents need more than an API URL. They need semantic information:

• What does this tool do?
• When should I call it?
• What arguments are required?
• What are the failure modes?
• How much does it cost?

Useful building blocks:

• OpenAPI specifications
• JSON Schema
• Function/tool schemas
• MCP tool definitions
• Agent-to-agent capability cards

Your marketplace can normalize all of these into an internal capability graph.

3. Programmatic signup and onboarding

Avoid “click here to create an account.” Agents need flows like:

discover →
request access →
authenticate →
receive credentials →
invoke API

Typical infrastructure:

OAuth 2.0 / OpenID Connect

For delegated access:

Agent
  |
  | authorization request
  v
Marketplace Identity Service
  |
  | token
  v
API Provider

Support:

• Dynamic client registration
• Scoped API tokens
• Short-lived credentials
• Consent policies
• Usage limits

4. Agent identity

You need to know:

• Which agent is calling?
• Who operates it?
• What permissions does it have?
• Is it trustworthy?

Common primitives:

• Public/private key identities
• Signed agent manifests
• DIDs or equivalent identifiers
• Attestation/reputation systems

Some agent commerce protocols are exploring explicit identity, discovery, negotiation, transactions, and reputation lifecycles.

5. Capability search engine

Your marketplace search should not just be keyword search.

Index:

• Capability embeddings
• Tool schemas
• Example tasks
• Latency
• Success rate
• Cost
• Required permissions
• User ratings

Example query:

“Find an agent that can reconcile invoices from QuickBooks and export audit reports.” Returns:

[
  {
    "agent": "AccountingBot",
    "capability": "invoice_reconciliation",
    "cost": "$0.02/task",
    "latency": "3s",
    "auth": "oauth"
  }
]

6. Execution gateway

Put a broker between agents and providers:

Agent
 |
Marketplace Gateway
 |
+-- auth validation
+-- policy checks
+-- billing
+-- rate limiting
+-- logging
 |
Provider API

Benefits:

• Hide provider credentials
• Enforce marketplace rules
• Meter usage
• Handle retries
• Provide trust scoring

7. Billing and contracts

If agents transact autonomously, add:

• Usage metering
• Subscription plans
• Per-call pricing
• Escrow/payment abstraction
• Refund handling
• SLA tracking

Some emerging agent marketplace protocols explicitly include discovery, negotiation, transactions, and reputation as separate lifecycle steps.

8. Recommended MVP stack

For a first production version:

Registry

• PostgreSQL + pgvector
• Capability manifest store
• Semantic search

Identity

• OAuth 2.1
• OpenID Connect
• Signed manifests

API integration

• OpenAPI ingestion
• MCP adapter
• Tool schema generator

Marketplace gateway

• API gateway (Envoy/Kong/etc.)
• Rate limits
• Usage tracking

Agent SDK Provide:

marketplace.discover(
    task="extract invoice data"
)

marketplace.connect(
    agent_id="invoice-agent"
)

marketplace.invoke(
    tool="extract_invoice_fields",
    input=data
)

Protocols worth watching

• MCP (Model Context Protocol): tool/context exposure between models and tools.
• A2A-style agent protocols: agent-to-agent communication and capability exchange.
• OpenAPI + JSON Schema: still the simplest interoperability layer.
• Agent discovery manifests/registries: emerging patterns for making services machine-discoverable.

A strong marketplace design usually treats discovery, identity, authorization, execution, and reputation as separate services rather than one monolithic “agent store.”