An AI helper can only buy what it can read. A computer-readable offer is a short, fixed-format description of your tool. It states what the tool does, what goes in, what comes out, the price, the trial, who is responsible and how to get permission. It sits at the same address as your sales page, so the helper can decide before it spends.
The problem
You own a company that sells a tool for checking freight quotes against carrier tariffs. Your sales page is good. It has a video, three case studies, a pricing page with a "contact us" button, and a login for existing customers.
A logistics firm's AI helper arrives at that page with a job to do. It needs a price per check, a description of what it must send, what it will get back, and a way to get permission. It finds a video and a contact button. It cannot fill in a form or wait for a sales call. So it moves on to a tool it can read, even a worse one.
You never see this happen. There is no bounce in your analytics, no lost lead in your inbox. Just a slow drift of business toward tools that helpers can understand.
Why this keeps happening
Web pages were written for eyes. An AI helper needs the same facts in a fixed order, in a form a program can check. Three shortcuts get proposed, and none of them do this job.
The first is a text file at a fixed address that summarises your site. People search "what is llms.txt" and "llms.txt for ecommerce" hoping it is the answer. As of September 2026 Google has said no AI system uses it, and advises keeping it out of the search index. The second is a product feed, like the file format OpenAI publishes for shopping checkout. That describes goods in a cart, not a tool that gets called again and again. The third is letting a helper ask for a page in plain text instead of a web layout, which Cloudflare supports. Community proposals with names like agents.json aim at describing software to helpers in the same spirit.
Each of these helps a helper read. None tells a helper what one use costs, whether its owner may use your tool, what to send, or who answers when something is wrong. That is what an agent-readable product catalog needs, and it is what your page is missing.
Even the newest standard for describing one AI helper to another stops short of price. The agent-to-agent standard that Google started defines its description card this way.
"Agent Card: A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements."
Linux Foundation, Agent2Agent (A2A) Specification v1.0 (2026)
Identity, skills, an address and a login method. No price, no trial, no proof of payment, no refund rule. It stops exactly where a sale starts. The official registry for tool servers stops in the same place. As of September 2025 it stores what makers report about themselves, and expects marketplaces above it to add the rest.
Most tools that helpers call speak MCP, a standard way for AI helpers to use tools. That standard already lets your developer publish a list of what your tool can do, with the shape of each request. Developers call the commercial layer on top of that list an mcp server manifest, which is a plain description a computer can read. Here is what it contains, in your words rather than theirs.
| What it states | In plain words | Why the helper needs it before spending |
|---|---|---|
| Name and version | A short, stable name and a version number | Pins exactly what will run; other tools can depend on a version |
| Publisher and keeper | Who published it and who keeps it current, with a last-updated date | A fact source with no keeper is stale by definition |
| What it does | One or two plain sentences | The helper matches it to the job it was given |
| What goes in, what comes out | The shape of a request and of an answer | The helper checks it can ask and can use the reply |
| Price | The model (per call, per unit, per result, monthly, yearly), the amount, the unit | Compared against the budget the owner set |
| Trial | How many free sample calls, and whether they use sample data | Lets the helper try before its owner is charged |
| Access | Whether the tool needs to reach the buyer's own systems, and which ones | Decides whether the buyer must grant access first |
| Where it runs | On your machines, on the marketplace's, or inside the buyer's own | Tells the buyer where their data goes |
| How to get permission | Buy through the marketplace; no key to hunt for | The helper knows to ask for access rather than look for a password |
| Who gets credit | Which contributors are named on each receipt | Lets earnings be split from the receipt itself |
Notice what is not on the list: your source code, your passwords, or a back-door address for a person to copy. The description is an address and a promise, not the asset. Protection comes from the payment check, not from hiding the link.
How to fix it
- Write the ten lines above for your tool. Do it in a plain document first. If you cannot fill in a line, that is a gap in your offer, not in the format.
- Give the offer one stable address. The page for people and the description for helpers live at the same address. Do not rename it later; a rename is a new offer.
- Put a real price on it. "Contact us" is unreadable to a helper. If you must vary price by customer, publish the standard price and handle exceptions by hand.
- Name the keeper. One person or team, and how often they refresh. Buyers of facts will look for this line first.
- Offer a small free trial on sample data. Helpers try before their owner is charged. Three sample calls is enough.
- Have your developer publish it. Either as a description next to your page, or through a marketplace that generates it from your answers.
Here is how a careful helper walks through it. It reads the description without logging in. It checks it understands the format and can supply what your tool needs. It compares your price with the budget its owner set, per job and per month. It asks whether its owner already paid for your tool. It checks whether your tool needs access to the owner's systems. Then it lands in one of five states: already allowed, can buy within budget, must ask a person, needs a connection, or unavailable. Only the first two go ahead. Nothing is spent in the other three.
What BlueBear's marketplace does about it
During the pilot, you do not write the machine-readable offer yourself. You give BlueBear the plain facts. A short name and a version. A price in credits, where one credit is one US dollar. One or two sentences on what a buyer gets. What your tool touches and where it runs. Your trial and refund terms. BlueBear publishes a public page and the computer-readable description at the same address, on your behalf.
A buyer's helper can find that page, read the price, and buy access within a limit the buyer set. Every job produces a signed receipt: what ran, for whom, at what price, and what came back. Your earnings are recorded from the receipts. If a buyer rejects a result, the job is refunded. Lines for the keeper and for credited contributors are optional; a simple offer pays you directly.
Once your tool has a description like this, other people's workflows can depend on it by name and version. A workflow that needs your tool and cannot find it does not half-run; it stops and asks. That is how your tool gets pulled into other people's work instead of found by accident.
This description is BlueBear's own format, not an industry standard. It sits on top of the tool lists and agent cards that standards already publish, and points to them rather than replacing them. Nobody has to adopt it to keep using those.
What is still early. The marketplace is a pilot and publishing is by invitation. There is no ranking and no self-serve dashboard. Payouts are made by hand. The part where a helper reads the description, checks budget and buys on its own has been proven during the pilot, not opened to everyone.
What to do next
Write the ten lines this week, in plain English, and hand them to your developer. If a line is blank, fix the offer before you fix the format. Then set your price using what a fair price looks like.
For the buyer's side, how buyers set spending rules for their helpers shows the budget your price gets compared against. What an AI audit trail is shows where the receipt for each job ends up. Why buyers want a curated list of tools explains why a readable, accountable offer gets chosen over a bare address.
To see a finished offer and its human page, open any listing on the public marketplace page. When you are ready, what BlueBear needs from you to list your tool is the next step.
Questions people actually search for
- what is llms.txt and do i need it
People asking what is llms.txt usually mean a plain-text summary of a website, placed at a fixed address, meant for AI systems to read. As of September 2026 Google has said no AI system uses it and advises keeping it out of the search index. It is cheap to publish, so it does no harm. But it carries no price, no description of what goes in and out, no permission rules and no responsible person. It cannot make a sale. A proper offer description is a different thing.
- how does an ai helper decide to buy my tool
It reads your offer description before spending anything. It checks that it understands the format, that it can supply what your tool needs, and that the price fits the budget its owner set. It asks the marketplace whether its owner already paid for your tool. It checks whether your tool needs access to the owner's own systems. Then it lands in one state: already allowed, can buy within budget, must ask a person, needs a connection, or unavailable. It only goes ahead in the first two.
- what should a machine-readable offer include
At minimum: a stable name and a version, who publishes it and who keeps it current, what it does, what goes in and what comes out, the price and the unit, any free trial, how the helper gets permission to use it, whether it needs access to the buyer's own systems, and where it runs. Optional extras say what kind of tool it is and which contributors should be credited on each receipt. A good machine-readable offer answers every question a careful buyer would ask, in a fixed order.
- do i have to write the description myself
Not on BlueBear during the pilot. You supply the plain facts: a short name, a version, a price in credits, one or two sentences on what a buyer gets, what your tool touches and where it runs, and your trial and refund terms. BlueBear turns those into the public page and the computer-readable description at the same address, on your behalf. Publishing is by invitation. If you publish elsewhere, your developer writes the description, and the checklist in this article is what it needs to contain.