{"slug": "capabilities-txt", "title": "Capabilities.txt", "summary": "A new open convention called capabilities.txt allows websites to publish machine-readable lists of actions an AI agent can perform, such as creating support tickets or checking inventory, at a well-known URL. The format complements existing standards like robots.txt and llms.txt by enabling agent discovery of executable capabilities before invocation via protocols like MCP or OpenAPI.", "body_md": "A simple, open convention for a website to publish the capabilities an agent can discover and invoke — at a well-known location.\n\nThe web taught machines to read in layers. `robots.txt`\n\nsays what a crawler may access. `sitemap.xml`\n\nsays what exists. `llms.txt`\n\nsays what's worth reading. Each answers one narrow question for an automated reader.\n\nNone of them answers the question agents now ask: **what can this host actually do?**\n\nAgents have stopped only *reading* the web and started *acting* on it. An agent that lands on your site can summarize your docs — but it has no standard way to discover that you expose a \"create support ticket\" capability, \"check inventory,\" or \"start a return,\" and how to call them. Today that happens through bespoke, one-vendor-at-a-time integrations.\n\n`capabilities.txt`\n\nis the missing layer: a public, well-known file where a host declares the capabilities it offers, so any agent can discover what it can do. A host publishes one or both:\n\n`/capabilities.txt`\n\nHuman- and agent-readable markdown: capabilities grouped by category, each with an id, version, and one-line description.\n\n`/.well-known/capabilities.json`\n\nThe structured form: an array of capability references, each resolvable to a full descriptor.\n\nIt's deliberately small. `llms.txt`\n\nworked because you could adopt it in an afternoon. `capabilities.txt`\n\nfollows the same rule.\n\n```\n# capabilities.txt\n\n> One sentence: what this host is and the capabilities it offers.\n> Structured form: https://example.com/.well-known/capabilities.json\n\n## Support\n\n### Tickets (support.tickets)\n\n- support.create_ticket (v1.2.0) — Open a support ticket\n- support.get_status (v1.0.0) — Check a ticket's status\n\n## Commerce\n\n### Inventory (commerce.inventory)\n\n- commerce.check_stock (v2.0.0) — Check availability for a SKU\n```\n\nLine 1 is `# capabilities.txt`\n\n. A `>`\n\nblockquote summarizes the host. `##`\n\ngroups by category; `###`\n\nnames a group; each capability is a list item with a stable id, optional `(v…)`\n\n, and a short description. It's just markdown — if a human can read it and an agent can parse it, it's valid.\n\n| File | Answers | For |\n|---|---|---|\n`robots.txt` | What may a crawler access? | Crawlers |\n`sitemap.xml` | What pages exist? | Search engines |\n`llms.txt` | What's worth reading? | LLMs reading |\n`capabilities.txt` | What can this host do? | Agents acting |\n\nIt's **not** a replacement for MCP or an API spec. MCP is a stateful connection-and-invocation protocol; OpenAPI describes an HTTP API. `capabilities.txt`\n\nis the layer *before* invocation — a static, public, crawlable advertisement an agent can read with no live connection, that points to your MCP server or API for the actual call. Discovery and invocation are different jobs; capabilities.txt does discovery and hands off invocation.\n\nA real, live `capabilities.txt`\n\n— the governed capability surface of the CHP adapter ecosystem:\n\n[capabilityhostprotocol.com/capabilities.txt](/examples/capabilityhostprotocol.com.txt) — live\n\nAnd how it looks across markets (illustrative templates you can lift):\n\n| Market | Example | Capabilities like… |\n|---|---|---|\n| E-commerce |\n|\n\nNotice the pattern: read-only capabilities are simple; the consequential ones (a transfer, a refill, a deploy) note who must approve and that the action is recorded. That hand-off — from \"what you can do\" to \"may I, and can I prove it\" — is where [CHP](https://capabilityhostprotocol.com) picks up.\n\n1. List the capabilities your site exposes. 2. Write them into `/capabilities.txt`\n\nusing the format above. 3. Optionally publish `/.well-known/capabilities.json`\n\n. 4. [Add yourself to the directory](https://github.com/capabilityhostprotocol/capabilities-txt/blob/main/adopters.md) with a pull request.\n\nAlready have an OpenAPI spec or an MCP server? Generate it — no manual authoring:\n\n```\n# from an OpenAPI description\npython tools/from_openapi.py https://api.yoursite.com/openapi.json > capabilities.txt\n\n# validate any capabilities.txt\ncurl -s https://yoursite.com/capabilities.txt | python tools/validate.py -\n```\n\ncapabilities.txt is only as useful as the agents that read it. The consumer flow is deliberately simple:\n\n`https://host/capabilities.txt`\n\n(or `/.well-known/capabilities.json`\n\nfor structure).A capability that *does* something — a transfer, a refill, a deploy — should also tell a careful agent *whether it may* and *whether the action is recorded*. That governance layer is [CHP](https://capabilityhostprotocol.com); capabilities.txt is the public front door to it.\n\nDiscovery is the first step. Once an agent knows *what* you can do, the next questions are *may I*, *what happened*, and *can I prove it* — invocation, governance, and evidence.\n\nThose are defined by the [Capability Host Protocol](https://capabilityhostprotocol.com), an open protocol for which `capabilities.txt`\n\nis the natural public face. You can adopt `capabilities.txt`\n\non its own; CHP is where it leads if you need the rest.\n\nNo — they're complementary. MCP is a stateful connection that *runs* tools. capabilities.txt is the static, crawlable layer *before* that: an agent (or a search engine) reads it with no connection, then uses MCP/your API to actually invoke. Discovery vs. invocation.\n\nOpenAPI describes the shape of an HTTP API in detail. 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 (MCP, HTTP, gRPC). You can generate one *from* OpenAPI.\n\nEssentially, yes — and that's the point. llms.txt says what's worth *reading*; capabilities.txt says what you can *do*. Same spirit, the next layer.\n\nNo. capabilities.txt stands alone — publish one today, point it at whatever you already run. CHP is where it leads *if* you need governance, permissions, and provable evidence for the actions.\n\nIt 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.\n\nAgentic and IDE tooling already fetches well-known files like llms.txt. capabilities.txt is the same cheap, agent-readable infrastructure — for action, not just reading. It's a proposal; adoption is the work, and your feedback shapes it.", "url": "https://wpnews.pro/news/capabilities-txt", "canonical_source": "https://www.capabilitiestxt.org/", "published_at": "2026-06-25 15:26:40+00:00", "updated_at": "2026-06-25 15:44:43.548330+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools"], "entities": ["capabilities.txt", "robots.txt", "sitemap.xml", "llms.txt", "MCP", "OpenAPI", "CHP"], "alternates": {"html": "https://wpnews.pro/news/capabilities-txt", "markdown": "https://wpnews.pro/news/capabilities-txt.md", "text": "https://wpnews.pro/news/capabilities-txt.txt", "jsonld": "https://wpnews.pro/news/capabilities-txt.jsonld"}}