Make your API agent-ready in 10 minutes

Add a single JSON endpoint. Your API becomes discoverable by every AI agent. No SDK to maintain, no MCP server to build, no partnership to negotiate.

Create your manifest

A manifest is a JSON file that describes your API's capabilities in both human-readable and machine-readable format. Here's the minimal version:

Minimal manifest

{
  "spec_version": "1.0",
  "name": "My API",
  "description": "What my API does in one sentence.",
  "base_url": "https://api.example.com",
  "auth": {
    "type": "none"
  },
  "capabilities": [
    {
      "name": "get_data",
      "description": "Fetch data from the API",
      "detail_url": "/api/capabilities/get_data"
    }
  ]
}

Each capability points to a detail_url — a deeper JSON endpoint that describes exactly how to call it (method, parameters, examples). Agents only fetch these when they need them (lazy drill-down).

Capability detail (at /api/capabilities/get_data)

{
  "name": "get_data",
  "description": "Fetch data by ID",
  "endpoint": "/v1/data/{id}",
  "method": "GET",
  "parameters": [
    {
      "name": "id",
      "type": "string",
      "description": "The data ID to fetch",
      "required": true,
      "example": "abc-123"
    }
  ],
  "request_example": {
    "method": "GET",
    "url": "https://api.example.com/v1/data/abc-123",
    "headers": { "Accept": "application/json" }
  },
  "response_example": {
    "status": 200,
    "body": { "id": "abc-123", "value": "Hello" }
  }
}

Submitting capability details: When submitting your service to the registry, you can include full capability details (endpoint, method, parameters, examples) alongside your manifest using the capability_details field. This is especially useful for services that don't implement their own capability detail endpoints — the registry will store and serve them as a fallback for agents.

Serve it with an SDK

Install the SDK for your framework. It auto-generates /.well-known/agent and all capability detail endpoints with proper CORS and caching headers.

Express.js — npm install agent-well-known-express

const { agentManifest } = require('agent-well-known-express');

app.use(agentManifest({
  name: "My API",
  description: "What my API does.",
  base_url: "https://api.example.com",
  auth: { type: "api_key", header: "Authorization", prefix: "Bearer" },
  capabilities: [
    {
      name: "get_data",
      description: "Fetch data by ID",
      handler: { endpoint: "/v1/data", method: "GET" },
      parameters: [
        { name: "id", type: "string", required: true,
          description: "The data ID", example: "abc-123" }
      ]
    }
  ]
}));
// Auto-generates: GET /.well-known/agent
//                 GET /.well-known/agent/capabilities/:name

FastAPI — pip install agent-well-known-fastapi

from agent_well_known import AgentManifest, Capability

manifest = AgentManifest(
    name="My API",
    description="What my API does.",
    base_url="https://api.example.com",
    auth={"type": "api_key", "header": "Authorization", "prefix": "Bearer"},
    capabilities=[
        Capability(
            name="get_data",
            description="Fetch data by ID",
            endpoint="/v1/data", method="GET",
            parameters=[{"name": "id", "type": "string",
                         "required": True, "description": "The data ID",
                         "example": "abc-123"}]
        )
    ]
)
manifest.mount(app)  # Registers both routes automatically

Next.js — npm install agent-well-known-next

// app/.well-known/agent/route.ts
import { createAgentManifest } from 'agent-well-known-next';

export const GET = createAgentManifest({
  name: "My API",
  description: "What my API does.",
  base_url: "https://api.example.com",
  auth: { type: "api_key", header: "Authorization", prefix: "Bearer" },
  capabilities: [
    { name: "get_data", description: "Fetch data by ID",
      endpoint: "/v1/data", method: "GET",
      parameters: [{ name: "id", type: "string", required: true,
                     description: "The data ID", example: "abc-123" }] }
  ]
});

Spring Boot — agent-well-known-spring-boot

@AgentManifest(
    name = "My API",
    description = "What my API does.",
    baseUrl = "https://api.example.com",
    auth = @AgentAuth(type = "api_key", header = "Authorization", prefix = "Bearer")
)
@SpringBootApplication
public class MyApp { }

// On your controller method:
@AgentCapability(
    name = "get_data", description = "Fetch data by ID",
    endpoint = "/v1/data", method = "GET",
    parameters = { @AgentParameter(name = "id", type = "string",
                    required = true, description = "The data ID",
                    example = "abc-123") }
)
@GetMapping("/v1/data")
public Data getData(@RequestParam String id) { ... }

All SDKs handle CORS headers, caching ( Cache-Control: public, max-age=3600), input validation, and auto-generated request examples. You can also serve the manifest manually without an SDK.

Submit to the registry

Once your endpoint is live, submit your domain. The registry will crawl your manifest, validate it, and make your API discoverable.

Submit your service Test in playground first

Why do this?

Your API becomes discoverable by every AI agent in the world.

✓No SDK to maintain. Agents learn your API from the manifest at runtime.
✓No MCP server to build. The gateway handles all agent-to-API communication.
✓No partnership to negotiate. Just add the endpoint and submit. Open protocol.
✓Your existing API stays the same. The manifest describes your API — it doesn't change it.

Trust & Verification

The registry uses a three-tier trust system to help agents make informed decisions about which services to use.

VerifiedHighest trust

Your service hosts its own /.well-known/agent manifest. The registry crawls it periodically and confirms it's live. This is the recommended path — agents prioritize verified services in search results.

CommunityMaintained by the registry

Services submitted manually and maintained by the AgentDNS team. These are trusted but the service provider doesn't host the manifest themselves. Good for services that don't want to change their infrastructure.

UnverifiedNot yet reviewed

Newly submitted services that haven't been verified yet. Hidden from search results by default. Agents must explicitly opt in to see unverified services.

To get verified status: host your manifest at /.well-known/agent and submit your domain. The registry will crawl your endpoint and verify it automatically.

Monetize your API

Earn revenue from agents that use your API. Connect your Stripe account and add pricing to your manifest — the registry handles billing, invoicing, and payouts automatically.

1. Connect Stripe

Link your existing Stripe account (or create a new one) to receive payments. You manage your payouts, refunds, and tax reporting in your own Stripe dashboard.

Connect with Stripe

2. Add pricing to your manifest

Declare your plans in the pricing field. Agents see this info and guide users through subscriptions.

Pricing in manifest

"pricing": {
  "type": "paid",
  "plans": [
    { "name": "Starter", "price": "$29/mo", "limits": "1,000 requests/day" },
    { "name": "Pro", "price": "$99/mo", "limits": "Unlimited requests" }
  ],
  "plans_url": "https://example.com/pricing"
}

3. Get paid

When an agent subscribes to your API through the gateway, the user is charged via their saved payment method. You receive payouts directly to your bank account through Stripe.

Platform fee

AgentDNS charges a 10% platform fee on all subscriptions. This covers:

•Discovery — your API is searchable by every AI agent
•Auth brokering — OAuth and API key management for users
•Payment processing — billing, invoicing, and payouts
•Support — platform maintenance and reliability

FAQ

Do I need to change my existing API?

No. The manifest is a description of your API, not a modification. Your existing endpoints, auth, and behavior stay exactly the same. You just add one new endpoint that describes them.

What about authentication?

Just declare it in the auth field of your manifest. Supported types: none, api_key, and oauth2. For API keys, you can specify the header name and prefix. For OAuth2, provide the authorization and token URLs.

What about pricing?

The pricing field is optional. You can set it to free, freemium, or paid and list your plans. Agents see this information and can guide users through subscriptions.

How do agents find my specific capability?

Agents search the registry by intent (e.g., "send email"). The registry matches against your service name, description, and capability names/descriptions. Agents then drill down into the specific capability they need — they never load everything upfront.

What if I have dozens of capabilities?

List them all in the manifest. Each one has a short description and a detail_url. Because agents use lazy drill-down, they only fetch the details for the capabilities they actually need. Your manifest stays lean.