How does an AI agent discover what your API can do?
Suppose an agent has been asked to buy a token, and your service can do that. How does it find out?
Not from your homepage — it cannot reliably read a JavaScript app, and marketing copy does not tell it which endpoint to call. Not from your docs site, which assumes a reader who already decided to integrate. If discovery depends on a human having read something and then written code, your service is not agent-accessible; it is human-accessible with an API attached.
Convention beats registration
The mechanism that solves this is old and boring: put the metadata at a path everyone has already agreed on.
That is what /.well-known/ is for. Because the location is fixed by convention, a client can simply ask — no registry to join, no directory to be listed in, no negotiation. It is robots.txt generalised, and it is the reason discovery works at all without a central authority.
BT365 publishes two documents there. /.well-known/agent.json is an ERC-8004 discovery document, the emerging convention for agent identity and capability. /.well-known/ai-plugin.json is the OpenAI plugin manifest, which predates it and is still widely fetched. Both describe the same service; they exist in parallel because you do not get to choose which convention the caller implements.
There is also llms.txt at the site root — a plain-text summary of what the service does and how to integrate, aimed at a model reading the site directly rather than at a client parsing a manifest. And robots.txt explicitly allows GPTBot, ClaudeBot and PerplexityBot, because none of the above matters if the crawler was disallowed before it got there.
Write the model's description separately
The single highest-leverage detail in any of these manifests is that the plugin format has two description fields, and they are not the same text.
description_for_human is positioning. It is what you would put on a pricing page.
description_for_model is operational, and it should read like a note to an engineer with no time. Ours names the concrete capabilities — swap execution across specific venues, token launch, agent creation, portfolio tracking — and then names the endpoints for the common path: search to find a token, quote for a price, swap to build the transaction.
That last part is what earns its place. A model choosing between services is not deciding whether it likes your brand; it is deciding whether it can accomplish a task and, if so, in what order to call things. Telling it directly removes the step where it guesses, and guessing is where integrations fail. Pasting your marketing tagline into that field wastes the most valuable few hundred characters you have.
Discovery has to be free, which is not the same as unguarded
Both manifests are public and require no authentication. That is not an oversight, and it is worth being explicit about why, because it looks inconsistent with charging for the API.
You cannot gate the document whose job is to tell callers you exist. An agent that must authenticate before it can discover what you offer will never get to the part where it pays you. So discovery is open, and the payment boundary sits at the individual endpoints — where a caller either presents payment for the call, a pre-issued key, or falls into a sponsored allowance.
Open does not mean unlimited, though. Both discovery routes are rate-limited to a hundred requests a minute. A manifest is cheap to serve and trivially scriptable, and there is no scenario where one caller legitimately needs more than that.
One honesty note if you are reading our manifest: it declares auth: none. That describes the manifest and the free surface, not every endpoint behind it. A caller that reads it as "everything here is free" will meet a 402 on its first priced call — which is precisely what the 402 is for, since it comes back with the price attached rather than a refusal.
The manifest is not the contract
A manifest tells an agent that you exist and roughly what you do. It is deliberately not a full description of your interface, and trying to make it one is a mistake.
The actual contract is the OpenAPI document the manifest points at. That is generated from the running service rather than maintained by hand, which matters more for machine callers than human ones: a human reading stale docs gets confused and asks; an agent reading a stale spec constructs a call that fails, and has no idea the spec was the problem.
Two layers, two jobs. The manifest is an advertisement with a fixed address. The spec is the machine-readable truth. Keep the first short and the second generated.
Then there is MCP, which is a different question
Everything above is about an agent that speaks HTTP finding an HTTP API. The Model Context Protocol answers something adjacent: how a model inside a client gets tools at all.
The distinction is worth keeping straight. Discovery manifests make your API findable by any program that fetches URLs. MCP makes your capabilities available as tools inside an assistant, without that assistant's author having integrated you specifically. One is about being findable; the other is about being installed. We expose the trading surface both ways, over stdio and HTTP transports, authenticated by key rather than per-call payment — because a tool inside a session is an ongoing relationship, not a one-shot request.
Why this is worth an afternoon
The audience for all of this is small right now. It is also the cheapest distribution work available, and it does not decay.
Two manifests, a text file, a crawler policy, and a generated spec is perhaps a day of work, most of it writing. What it buys is that software written by people who have never heard of you can find you, understand what you do, and call you — and, with a payment method it can complete unattended, become a customer in the same session.
Compare that with the alternative channel, where a human searches, reads, evaluates, signs up, and integrates over some number of weeks. Both are worth having. Only one of them is currently uncontested.
Part of our guide to making an API usable by AI agents.
BT365 exposes its trading surface to agents over x402, MCP and machine-readable discovery. Explore the platform or read the API documentation.