By Project Auxo · 2026-06-28
TL;DR. To make your API agent-ready, publish a /capabilities.txt at your site root that declares what your API can do, allow the AI crawlers in robots.txt, and point the file at your existing API or MCP server for invocation. An agent then discovers your capabilities with a single static fetch — no bespoke integration. You can do it in about ten minutes: generate the file from your OpenAPI, publish it, and check it for conformance.
AI agents are the fastest-growing visitors to most APIs, and they arrive with no standard way to learn what your API can do. Today that gap is filled by bespoke, one-vendor-at-a-time integrations — someone hand-writes a wrapper for your API inside each agent platform. That does not scale, and it means your API is invisible to every agent nobody has hand-wired yet.
Being agent-ready closes that gap with static files an agent already knows how to fetch — the same cheap infrastructure that made robots.txt and llms.txt universal.
| # | Step | What you do |
|---|---|---|
| 1 | Generate | Turn your OpenAPI description into a capabilities.txt (or hand the implement prompt to your coding agent). |
| 2 | Publish | Commit the file at https://yoursite.com/capabilities.txt — sibling to robots.txt and llms.txt. |
| 3 | Allow | Welcome the AI crawlers (GPTBot, ClaudeBot, PerplexityBot, CCBot) in robots.txt so they can read it. |
| 4 | Point | Make sure the file references your real invocation endpoint — your API base URL or MCP server. |
| 5 | Check | Run a conformance check for a grade + badge, and list it so agents can discover it. |
If you publish an OpenAPI description, you already have everything needed. Point the generator at it and get a conformant capabilities.txt back in seconds:
# hosted: paste your OpenAPI URL at capabilitiestxt.org/generate # or from the command line: python tools/from_openapi.py https://api.yoursite.com/openapi.json > capabilities.txtNo OpenAPI? Copy the implement prompt and hand it to your AI coding agent — it reads your real routes and writes the file, finding the consequential actions (place order, start a return, open a ticket), not just the read-only endpoints.
Commit the file so it is served at https://yoursite.com/capabilities.txt — a sibling torobots.txt. Optionally also publish the structured form at/.well-known/capabilities.json for agents that want machine-resolvable descriptors.
A declaration nobody can read is useless. Explicitly welcome both the training and search crawlers inrobots.txt so your capabilities are discoverable and citable:
User-agent: GPTBot Allow: / User-agent: ClaudeBot Allow: / User-agent: PerplexityBot Allow: / User-agent: CCBot Allow: /capabilities.txt does discovery; it hands off invocation. The summary blockquote and each capability should make clear where the actual call goes — your HTTP API base URL, or an MCP server if you run one. The agent reads the file with no connection, then calls the endpoint to act.
Run a conformance check for a grade (A–F), a fix list, and a badge for your README. A passing file is automatically discoverable in the directory and capability map, so agents can find you.
An agent-ready API is one an AI agent can discover and call without a custom, per-vendor integration. Concretely: there is a static, crawlable declaration of what the API can do (a /capabilities.txt), the AI crawlers are allowed to read it, and it points at a real invocation endpoint (your HTTP API or an MCP server). The agent reads the declaration, picks a capability, and calls it.
About ten minutes if you already have an OpenAPI description: generate the capabilities.txt from it, commit the file at your web root, add the AI crawlers to robots.txt, and run a conformance check. No OpenAPI? Hand the implement prompt to your coding agent and it writes the file from your real routes.
No. capabilities.txt is invocation-agnostic — it can point at a plain REST API, a gRPC service, or an MCP server. Most sites have an HTTP API and no MCP server, and capabilities.txt works for them today. MCP is one of the endpoints you can hand off to, not a prerequisite.
No. capabilities.txt only advertises what you already expose; it grants nothing. Authentication, rate limits, and authorization stay on your invocation endpoint. Declaring a capability is not the same as leaving it open — it is the equivalent of a menu, not an unlocked door.
OpenAPI describes the full shape of an HTTP API in detail, for developers. capabilities.txt is a one-screen, human- and agent-readable advertisement of what you can do, published at a well-known path, framework-agnostic, and able to point at any invocation method. You generate the capabilities.txt from your OpenAPI — they compose.
Once an agent knows what your API can do, the next questions for any consequential action are may I, what happened, and can I prove it. Those are governance and evidence — defined by the Capability Host Protocol. If your API touches money, health, or other regulated decisions, see how CHP turns an action into a provable audit trail. capabilities.txt is the public front door; CHP is where it leads.
Generate your capabilities.txtFrom OpenAPI, step by stepCompare the standards