An open standard · with a working reference
capabilities.txt
A public, well-known file where a host declares the capabilities it exposes — so AI agents can discover what they can invoke. A discovery sibling to robots.txt and llms.txt, for the agentic web.
robots.txt advertised what crawlers may read. llms.txt advertised what LLMs should read. capabilities.txt advertises what agents can do.
capabilities.txt is an open standard with its own home at capabilitiestxt.org — the spec, a generator, and a conformance checker. This page is about how CHP grounds it in a real schema and adds governance and evidence.
The format
Two files, dead simple.
/capabilities.txtHuman- and agent-readable markdown: capabilities grouped by category, each with an id, version, and one-line description.
/.well-known/capabilities.jsonThe structured form — an array of capability references, each resolvable to a full descriptor (modes, policy, evidence, schemas).
Grounded in a real, open schema: CapabilityDescriptor.
How it relates
Complementary, not competitive.
vs robots.txt
Tells crawlers what they may access. capabilities.txt tells agents what a host can do.
vs llms.txt
Advertises content for LLMs to read. capabilities.txt advertises actions for agents to take.
vs MCP
A stateful connection + invocation protocol (a client connects to a server and calls tools). capabilities.txt is the static, public discovery layer — crawlable with no live connection — that points to your MCP, HTTP, or CHP endpoint for invocation. Complementary, not competing.
vs OpenAPI
Describes the shape of an HTTP API. capabilities.txt is governance-aware (policy, evidence, provenance) and agnostic about how you invoke.
Where it leads
Discovery is step one. Governed invocation is where it goes.
capabilities.txt answers one question — what can this host do? That is discovery, and it stands on its own. CHP answers the next three an agent or an auditor actually has: may I invoke this (governance), what happened (execution), and can I prove it (evidence). A capability listed in a capabilities.txt can resolve to a full CapabilityDescriptor and be invoked through a host, where every invocation is checked against policy and recorded as replayable evidence. Adopt capabilities.txt on its own; CHP is where it leads.
- 01Read the spec
The format + rules live at capabilitiestxt.org.
- 02Generate
Turn an existing OpenAPI spec into a capabilities.txt with the generator.
- 03Validate
Check it against the conformance checker.
- 04Publish
Serve /capabilities.txt and /.well-known/capabilities.json.
- 05Discover
Agents fetch and parse it — no live connection required.
- 06Invoke
Point the listing at your MCP, HTTP, or CHP endpoint. Through a CHP host, invocation is governed and evidenced.
Questions
What a discovery standard has to answer.
What is capabilities.txt?
A public file at a well-known location where a host declares the capabilities it exposes — named, versioned units an agent can discover and (elsewhere) invoke. A human/agent-readable /capabilities.txt plus a structured /.well-known/capabilities.json.
Why does it need to exist?
Agents increasingly navigate the web autonomously. They can find content (llms.txt) and respect crawl rules (robots.txt), but there is no standard way for a host to advertise what it can do. capabilities.txt is that missing discovery layer.
How is it different from just listing API endpoints?
A capability declaration is governance-aware: it can carry who may invoke it, under what policy, and whether it emits provable evidence — not just a function signature. That is the part an auditor or a careful agent actually needs.
Do I need CHP to publish one?
No. capabilities.txt is a simple, open convention. CHP grounds it in a real schema (CapabilityDescriptor) and gives the capabilities governance and evidence — but the discovery file stands on its own.
Want to publish one — or shape the convention?
It's an open standard with a live reference — spec, generator, and validator. If you expose capabilities agents should find, let's get you on the map.