A website AI assistants can operate.
More and more people let an AI assistant do their research: “Find me a freelancer for our frontend and ask whether he is available.” This website is prepared for that. An assistant can read here what I offer and send an inquiry without clicking through the page. This case study shows how that is built and what you can take away for your own product.
Starting point
A contact form is built for people. An AI assistant has to recognize it from a screenshot, guess the fields and hope nothing goes wrong. That is slow and error-prone.
Solution
The website offers the same inquiry as a tool as well: through an MCP server for AI assistants and through WebMCP for agents right in the browser.
Result
Four clearly described tools with the same rules as the form. No additional service, no additional hosting costs: everything runs in the same program as the website.
MCP and WebMCP in brief
The Model Context Protocol (MCP) is an open standard that lets AI assistants use the functions of a piece of software. Instead of operating an interface, the assistant calls a tool, for example “send project inquiry”. Every tool has a name, a description and fixed fields with allowed values. So the assistant knows in advance what it has to provide and what comes out.
An MCP server is the counterpart on the software side: an address on the network where these tools are available. The assistant does not need a browser for it. Think of a switchboard with fixed extensions, as opposed to a reception desk where you have to ask your way through.
WebMCP brings the same idea to the browser. The web page registers its tools with the browser, and an agent working in the user’s browser uses them there. The person sees in the familiar interface what is happening. WebMCP is still a draft that browser vendors are developing in a W3C group and that Chrome is already testing.
Three ways, one inquiry
Person
The form
Visitors fill in the contact form as usual. Nothing has changed for them.
Agent in the browser
WebMCP
If the browser supports WebMCP, the page registers the form as a tool. The agent fills in the visible form, and the user sees there what is sent.
Agent without a browser
The MCP server
An AI assistant connects directly to the MCP server. It reads services and prices there and sends the inquiry as a tool call.
How it is built
One source for all rules
Which fields an inquiry has, which values are allowed and how long a text may be is defined in exactly one place in the code. The form, the MCP server and WebMCP take their description from there. If a rule changes, it changes everywhere, and an inquiry looks the same no matter whether a person or an agent sends it.
A small MCP server in Go
The server offers four tools: two read-only ones for services and fixed-price audits and two that send an inquiry. It uses the Streamable HTTP transport, needs neither sign-in nor sessions and is part of the Go program that also serves the website. Because the scope is so small, it is written directly with the web framework Fiber. For larger servers there is the official Go SDK.
WebMCP as an addition to the form
The server puts the description of the tool right on the form. A short script registers it with the browser if the browser supports WebMCP. The tool fills in the visible form and sends it to the same address as the submit button. In browsers without WebMCP nothing happens, the form works as always.
A signpost for agents
A file called llms.txt summarizes the website for AI models: what I offer, where the MCP server is, which fields are required and which limits apply. That way an assistant finds its way without reading the whole site. You can take a look at this website’s file.
Protection against abuse
An interface for agents is also an interface for spam. Every inquiry triggers emails, so agents face the same limits as the form plus a few more. The protocol comes with its own security recommendations.
Fixed limits
At most three inquiries per hour per sender, two per email address and ten per day in total. The MCP server also accepts only 30 messages per minute from one sender, invalid ones included.
Validated input
Every value is checked against the same rules as in the form. Unknown fields are rejected, control characters removed, disposable addresses and unreachable email domains sorted out.
Clear instructions for the agent
The server marks which tools only read and which trigger something. It instructs agents to ask the user for details instead of inventing them and to have the inquiry confirmed before sending.
Traceability
Every inquiry states the way it came in: form, agent in the browser or MCP server. Rejected calls end up in the log, input from the sender only shortened.
What AI took over and what it did not
AI agents wrote a large part of the code for the server, the checks and the tests. The protocol is well documented, and a task like “implement this tool according to the specification” is something an agent handles quickly today.
The actual decisions were not in any specification: which tools does an assistant really need, and which ones better not? What may an agent trigger without asking? Where are limits that let real inquiries through and keep spam out? That is product and interface design for a new kind of user, and that is the experience I bring. More on the page AI-native software.
What you can take away for your product
Start small
One or two tools for the most common task are enough to get started. Here it was the inquiry, for you it may be “book appointment” or “create quote”.
Define rules only once
If the form and the tools use the same rules, there is no second system to maintain. That keeps effort and running costs low.
Plan protection from the start
Limits, checks and logs belong in the first draft, not in a later stage. An agent repeats a mistake in seconds more often than a person manages in a day.
Documentation for further reading
Model Context Protocol
Introduction, tools, transport over HTTP and security recommendations.
MCP in Go
The official Go SDK and its package documentation.
WebMCP
The draft of the standard, the explainer of the W3C group and Chrome’s post on the preview program.
llms.txt
The proposal for llms.txt and this website’s file.
Frequently asked questions
Do I need MCP if my product already has an API?
An API describes what is technically possible. An MCP server describes in a few understandable actions what an assistant can sensibly do. It usually builds on the existing API, so the effort stays manageable.
Is WebMCP ready for production?
WebMCP is still a draft that Chrome is testing. That is why it is built as an addition here: if the browser does not know it, nothing changes. MCP, on the other hand, is established and supported by the major assistants.
Can an agent do damage with this?
It can only do what the tools allow. Here that means two read-only queries and two inquiries with fixed limits. In products with customer data, sign-in, per-user permissions and a confirmation before critical actions are added.
How do I find out whether my product is ready for agents?
In the fixed-price audit on AI agent readiness you learn whether agents can operate your application and what is missing.
Let's talk about your situation
In a free initial call we take a look at your problem together. You get an honest assessment of whether and how I can help.
The matching solution
Problem
Your software doesn't talk to AI agents yet
Agents struggle through your interface or fail at it. With MCP and WebMCP your product gets an interface that agents understand.