Agent-Ready Websites

An agent-ready website is one an AI assistant can use, not just read: its tools are declared in machine-readable files, its forms are labelled so an assistant can fill them, and it is explicitly open to AI crawlers.

Assistants already read your pages. What they cannot do is act: they cannot find your enquiry form reliably, they do not know which of your features is a tool, and they cannot submit anything on a user's behalf. That gap is now a standard problem with a standard answer — and almost no site has implemented it yet.

What an AI assistant can do on a site today

Capability	Without the agent layer	With it
Read and cite your content	Usually yes	Yes, with your own site description
Know what your site can do	Guess, from page text	Read a declared tool list
Fill a text or enquiry form	Unreliable — DOM guessing	Declared as a callable tool (WebMCP)
Run your calculator or converter	Click by trial and error	Declared with its parameters
Upload a file for the user	No	Still no — measured limit, see below

What I implement

llms.txt with a dedicated ## For AI agents section — where your tools are, what is free, how to cite you, and what is off-limits.
agent-tools.json — a machine-readable map of every tool: its page, its real selectors, its accessible labels, whether login is required, and what it returns. Every selector is checked against your actual HTML rather than invented.
robots.txt rules for AI crawlers — explicit entries for GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, CCBot and the rest, so your policy is unambiguous.
Stable, labelled controls — ids, names and aria-labels on the fields that matter, so an assistant targets the right element instead of guessing.
WebMCP declarations — forms and tools declared with toolname, tooldescription and per-field toolparamdescription, plus the origin-trial token wired into your server headers. Browsers without WebMCP ignore all of it.
A verification report — the commands I ran and their output, on your live site, so you can re-run them and see the same result.

Verified on live sites, not mocked up

These are working implementations you can inspect before you talk to me. The third command is the one that matters: it asks the browser itself which tools it recognised.

nocodecsv.com — a tool site

Five tools declared, including a CSV splitter and a JSON⇄CSV converter; file input exists in the DOM so it can be targeted at all; WebMCP enabled for the whole origin.

curl -sI https://nocodecsv.com/ | grep -i origin-trial

A B2B enquiry site

The quotation form is declared as a callable tool with six described fields (name, company, country, email, product family, message).

curl -s https://buildex-1dm.pages.dev/agent-tools.json

A calculator site

A live-recalculating calculator declared with its real inputs, and the declaration states that there is no submit button — the detail assistants get wrong most often.

curl -s https://carecosttool.pages.dev/agent-tools.json

What I measured that nobody else publishes

On a live site with the origin trial active, the browser exposes the tools it has registered. This is the real output for one of the tool pages:

> await navigator.modelContext.getTools()
[
  {
    name: "splitLargeCsv",
    description: "Splits a CSV file that is too large for Excel or Google Sheets
                  into smaller files with a chosen number of rows"
  }
]

And here is the limit, stated plainly rather than left for you to discover: the same call reports {"type":"object","properties":{},"required":[]} when the only field on the form is a file input. We tested it with and without an associated <label> — the parameter stays empty. In practice this means an assistant can be told about a file-processing tool and can hand the user to the right page, but cannot attach the file itself. Text, dropdown and number fields are a different story: they do get declared and can be handled end to end.

How it works

Free audit. Send a URL. You get a short findings note: what already works, what is missing, what I would add — in priority order.
Fixed-scope quote. If you want the implementation, I quote it for your site (page count and whether WebMCP is in scope are the variables). No subscriptions, no lock-in — everything I add is built on open, inspectable files.
Implement and verify. Typically three to six days, ending with the verification report and, if you want it, a short walkthrough.
Re-check. Thirty days later I re-run the checks and tell you if anything drifted — origin trials expire, and it is better to hear that from me than to guess.

Send me your URL — the audit is free

Tell me the one or two actions a visitor should be able to complete on your site, and I will send back what an assistant can and cannot do there today.

Reference material: the free audit script and the full checklist are documented on this site.

What I will not claim

No guaranteed AI mentions or rankings. I implement and verify the technical layer; retrieval is the assistant's decision.
No file-upload automation — measured, not assumed (see above).
WebMCP currently requires an origin trial and expires; the other layers work in every browser, today, and are the part that keeps working regardless of what happens to the trial.

Frequently asked questions

What does “agent-ready” mean?

An agent-ready website is one an AI assistant can not only read but also act on: it declares its tools in machine-readable files (llms.txt, agent-tools.json), allows AI crawlers in robots.txt, labels its form controls so an assistant can target them, and — where supported — declares those forms as callable tools with WebMCP.

Can AI assistants fill in my contact form today?

Partly. Text, dropdown, number and radio fields can be declared and become available to an assistant through WebMCP in Chrome. File-upload fields cannot: we measured the generated tool schema on a live site and it came back as {"type":"object","properties":{},"required":[]} even after associating a label with the input. So an assistant can complete a text enquiry or run a calculator, but a human still chooses files.

Do I need to rebuild my website?

No. The agent layer is additive: new files (llms.txt, agent-tools.json), robots rules, ids and labels on existing controls, and attributes on existing forms. Nothing is rewritten, and the website keeps working exactly as before for human visitors.

Is WebMCP supported in all browsers?

No, and that is expected. WebMCP is in an open origin trial (Chrome 149 to 156 at the time of writing, trial ending 17 November 2026). A site registers the trial, adds the token, and the declarations are then recognised in Chrome; other browsers simply ignore the attributes. The non-WebMCP layer — llms.txt, agent-tools.json, robots rules — works everywhere, today.

How do you verify the work?

On the live site, not locally. You receive the exact commands and their output: fetch agent-tools.json and check it parses, count the declared AI crawlers in robots.txt, confirm the sitemap hosts resolve, and — where WebMCP is enabled — show the browser's own navigator.modelContext.getTools() output listing the declared tools. You can re-run every command yourself.

Do you guarantee AI mentions or rankings?

No, and nobody should. I implement and verify the technical layer that makes a site readable, credit-able and operable. Whether a particular assistant cites you depends on its own retrieval and policy, which no vendor controls.

What does it cost and how long does it take?

The audit is free: send a URL and you get a findings note listing what already works and what is missing. If you then want the implementation, it is quoted as a fixed scope for your site (page count and whether WebMCP is included are the main variables), typically delivered in three to six days including the verification report.