A marketing director at a 120-person SaaS company asks her assistant to shortlist vendors for a website rebuild and get intro calls into the diary with the two that have slots next week. The assistant reads five sites, summarises them, and hands back five contact forms for her to fill in herself.
The other half of that errand
The reading half already works. The doing half is what is being specified right now. The proposal is called WebMCP: a draft browser API that lets a page register a short list of things an agent can call. Check availability for a date. Look up the price of a configuration. Return the right datasheet for a machine model. A named function with a described input, instead of a form the agent has to work out from the page. If it lands, a website stops being a document that agents interpret and becomes something they can operate.
Where the proposal actually stands today
Early, and the specifics matter more than the label. One client ships support: ChatGPT Desktop, branded Site tools, inside the desktop app’s built-in browser, on two of its model variants and not in Enterprise or Edu workspaces. Brave has an experiment in its Leo chat that the engineer building it called “still very experimental” in August. Chrome 149 and Edge 150 are running origin trials that both expire on 17 November 2026. WebKit’s recorded standards position is oppose and Mozilla’s is neutral, the W3C TAG review is open with security, privacy, accessibility and internationalisation all marked pending, and the spec is a Draft Community Group Report that is not on the W3C standards track. Nobody can forecast from that, and nothing below is a forecast.
What you could hand an agent
Start from a question your sales team answers by email over and over, and ask what it would mean for a buyer’s agent to get that answer directly.
| What you sell | A lookup worth exposing | What the buyer’s agent could do with it |
|---|---|---|
| B2B software with a demo funnel | Next available intro slots | Propose a time and put it in the buyer’s calendar instead of returning a form |
| Multi-market ecommerce | Stock and lead time for a SKU in a country | Answer “can I have this in Austria by Friday” without anyone digging |
| Industrial manufacturing | The document that matches a model and voltage | Fetch the correct datasheet rather than four candidates |
| Services with tiered pricing | A price for a described scope | Give a real number rather than a range scraped off a page from 2024 |
| Venues and events | Availability for a date and a headcount | Build a shortlist already filtered by who can actually host it |
None of those are new capabilities. Every one of them is something a person on your team does by hand today, usually a day later than the buyer wanted it. The change would be that the answer sits on the page as a function anyone’s agent can call, at the moment they are comparing you against four other companies.
That is also the reason the technical work is smaller than it sounds and the content work is bigger. A function that answers “is this date free” needs a system that knows what a date and a slot are. A function that returns the right datasheet needs a content model where a document is attached to a model number rather than uploaded into a folder called Downloads. This is structured content work, and teams that did it for search would find most of it already done.
What it could change about being found and chosen
We wrote in April that your website has two audiences: your own team using AI tools, and the agents arriving on behalf of someone else. Tool calling would give that second audience hands.
Think about a shortlist that a buyer’s assistant assembles rather than the buyer. It is filtered by what the assistant could establish about each vendor. Today that is whatever it could read: your pages, your claims, your adjectives. A site that can also be queried hands it facts instead. A site that can be acted on hands the buyer a finished step rather than a task on their list. A lot of this would amount to a better contact form. The part that could matter more is the step the buyer would never have to take, because their agent could complete it first.
Honest limit: nobody can tell you what share of buying will run this way. No vendor publishes usage figures for these clients, the browser trials are switched on per site, so there is no denominator and any percentage you read is invented. What you can do is check your own numbers. If assistants can already read and cite your pages, that is measurable in your analytics and your search console today, and it is the leading indicator that matters.
What stays on the human path
The caller has good reason to be suspicious of anything a website offers it. The spec’s own security chapter names three separate routes for prompt injection, and one of them is the tool description a site supplies. OpenAI’s documentation tells its users the same thing in plainer words: treat what a site declares, and whatever it hands back, as untrusted. Narrow, boring, obviously read-only tools are the ones that get trusted.
| Reasonable to expose | Keep human |
|---|---|
| Reading availability, stock, lead time | Taking payment |
| A price for a stated scope | Changing an account |
| Returning the document that matches a spec | Deleting or editing content |
| Starting a request a person confirms | Anything with personal data, while consent is still an open issue in the spec’s tracker |
Those hard lines are the same ones we hold for agents working inside a client’s CMS. Billing, user management, destructive edits. A new calling mechanism does not move any of them.
The one tool we run on this site
There is a single tool on every page of essentialcode.eu. No input, no write path, nothing of ours sitting behind it: asked, it hands back the public booking URL as plain text and stops. Inside an embedded frame it does not register at all. That is the whole thing, and it took an afternoon.
We have nothing to report from it. No traffic, no booking, no measurable difference to anything. It answers one question with one public URL, which is about the narrowest thing worth building while the consent primitive is still an open issue in the spec’s tracker.
Where to start, if any of this appeals
Three questions, and none of them need a browser API to answer:
- Which question does your team answer by email most often? That is your first candidate tool, and writing down what a caller would have to supply and what comes back will tell you whether your systems can answer it at all.
- Can an assistant read and cite you right now? Markdown copies of your pages and an llms.txt are the cheap half of this, and an agent that cannot parse your site will never call a function on it either.
- What would you never let an agent do? Decide it before someone asks you to ship the booking flow, not after.
Our AI Visibility Audit scores the second one and fixes what it finds in a week. The origin trials expire on 17 November 2026, and whatever happens to them, the work that makes a site usable by an agent is the same work that makes it readable by one. That half is available now.