Our site now has tools, not just pages
An AI agent that visits actmorehuman.com has, until now, done what every agent does on every site. It read the HTML, guessed which div was the search box, and clicked something that looked like a button. When we shipped a redesign, it broke. When a modal opened, it got lost.
That is over. As of today the site hands agents a typed list of the things it can do, and they call those things directly.
The standard is WebMCP, a W3C proposal that lets a page declare tools to whatever agent is looking at it. We shipped ten of them.
What an agent can now do
Four read-only tools, which change nothing and can be called freely:
search_guidesandget_guidereach every guide on the site, fourteen of which are published in eleven languageslist_assistantsandget_setup_stepsreturn where ChatGPT, Claude, Gemini, Grok, Perplexity and Copilot each hide their custom-instructions setting, and what to put in it
Three that build something:
get_wizard_optionsandbuild_humanizer_promptproduce the prompt the site's wizard produces, without the visitor clicking through the wizardhumanize_textrewrites AI text in one of four tones, from 20 to 6,000 characters
Three that touch commerce or a mailbox:
list_productsreturns what we sell and what it costs today, including a priced Company Voice configuration with add-onsstart_checkoutopens a Stripe sessionsubscribe_to_updatesasks to send one confirmation email
The full descriptions are the ones agents read, and they name their own limits. list_products says the list may be short because it returns only what is on sale. humanize_text says it costs money per call and should not be retried on the same text. An agent that plans against a vague description makes worse plans.
Writes stop and ask
start_checkout and subscribe_to_updates do not resolve until a person approves them in a dialog on the page. The dialog names the product, the price and the email address before anyone clicks anything. A tool that asks for confirmation and has nothing specific to show fails the build, so "are you sure?" with no object attached cannot ship.
Subscribing is double opt-in on top of that. The tool sends one confirmation email and returns the fact that it sent it, not a subscription. Ignore the email and nothing happened. An agent cannot put an address on a list, and neither can we.
humanize_text drives the visible form rather than fetching quietly behind it. The visitor watches their text arrive in the box and get rewritten. That is the whole premise of a shared surface: you are meant to see what the agent did on your screen, on the page you are looking at.
Agents that are not in a browser
The same tools are served over MCP at /api/mcp, so a coding agent or a desktop assistant with no browser can call them too. Both transports run the same pipeline, which is the only reason their guards cannot drift apart.
The read-only tools are open there. humanize_text is not, and the reason is boring and worth stating: the remote endpoint has no authentication, so exposing a tool that spends model budget would let any page a visitor loads spend ours through their browser. Reads stay open. Spending needs a caller we can identify.
The scorecard, including the bad part
The webmcp.com directory scanned six pages and graded the result an A. It found nine tools, which is correct. The tenth, humanize_text, sits behind the same feature flag as the humanizer page, and while that flag is off the tool is never registered and never listed. Advertising a capability that fails on call is worse than not having it.
The scan liked the descriptions and the input constraints, and it named one real gap: no output schemas on any tool. Every tool declares exactly what goes in, and none of them declare what comes back. An agent has to parse our output to find out. That is a fair hit and it is on the list.
For scale, the directory holds 522 verified sites and 3,387 tools. Across all of them, 51% drive the page, 44% only answer questions, and 5% touch money or a commitment. We land in all three buckets.
Why we did this
Assistants already read this site. People ask ChatGPT where Claude's custom-instructions box lives and get an answer shaped by pages we wrote. Being read is good. Being usable is different, and it is the next thing.
There is also an argument here we would make anyway. The agentic web can go two ways. Either agents scrape sites and the sites become passive surfaces to be parsed, or sites keep their own logic and expose it on their own terms, with their own guards, their own rate limits and their own confirmation dialogs. We would rather run the second one. A checkout that only proceeds when a human approves it in a dialog is not friction. It is the site staying in charge of its own behaviour.
Two rounds of security review found four issues before this shipped, all fixed: open CORS on the MCP route, an error path that swallowed retry timing before the agent could see it, a bridge that accepted callers with no origin, and a handler branching on another module's error text. 898 tests pass across 67 files, 254 of them new.
Try it
Open the site in a WebMCP-capable browser and ask your agent to find a guide on em dashes, or to price a Company Voice engagement with add-ons. It will call search_guides or list_products and tell you what came back. Ask it to buy something and it will stop and hand the decision to you.
The scorecard is public at webmcp.com. The output schemas are next.
---
This was written with AI. Every claim in it was checked by a human before it went out. If AI writing can't survive that check, it isn't ready to publish.