Built for machines as well as people
This website can be used by an AI agent, not just read by one
Agents and machine access · Production, on a time-limited origin trial · Inside the Workshop
Most websites expect an agent to scrape them — to fetch the HTML, guess at the layout, and hope nothing moved. This one publishes five tools that an agent can call directly, the same way it would call any other API. Availability, rates, services, the FAQ, and a contact enquiry it can prepare for you to review.
It is the same problem as any integration: two systems that need to exchange something specific, without one of them reverse-engineering the other. That is the work I do for clients, so it seemed reasonable to do it here first.
What is registered on this page
The browser API is write-only — a page registers tools and cannot read them back —
so this list is part of the page rather than a live readout, and saying otherwise would be
a nice claim that happens to be false. Instead the build checks it: if this list and the
tools the site actually registers ever disagree, npm run lint:agent-tool-list
fails and the change does not ship.
pagetech_get_availability— day-by-day consulting availability, as a traffic-light status per date. Past dates are never returned, because they cannot be booked.pagetech_get_pricing— the published rates and what each one suits.pagetech_list_services— the services offered, with a short description of each.pagetech_search_faq— searches the questions and answers published on the page.pagetech_prepare_contact_enquiry— fills in the contact form and reports back. It deliberately cannot submit it; a person presses send.
What your browser can see right now
Checking…
Most browsers will report that they cannot see the tools, and that is expected rather than a fault. The browser API behind this is called WebMCP (a browser version of the Model Context Protocol, a standard way for AI agents to call tools) and is still an origin trial, so it is switched on for a limited period and only for browsers that have shipped it. The tools are published either way — what varies is whether your browser is one that can act on them.
Why a consultancy site bothers with this
Because describing integration work and demonstrating it are different things. Anyone can write “experienced with APIs and system integration” on a services page. This is a working interface, on the site you are already on, that you can point an agent at.
It also reflects how the rest of the site is built. There is one canonical machine-readable description of the business rather than a different one on every page, a plain-text summary for language models, and a humans.txt for people who prefer the older convention. The same discipline that keeps those consistent is the discipline that keeps a client's integrations from drifting apart.
If you want to try it
Point an agent that supports WebMCP at this site and ask it when I am next free, or what the rates are. It should answer from the tools rather than from the page text. If you would rather talk to a person about integration work, get in touch or look at availability.