A website can explain what a company does very well and still remain opaque to an artificial intelligence agent. A person sees the navigation, interprets the hierarchy, compares services and understands that a form is there to make contact. An agent, by contrast, often has to infer all this by observing text, structure and buttons. This gap is what we have begun to explore at karmina.ai.
We have added an initial WebMCP layer to the public code of Karmina AI Studio’s conversational beta. In an environment where WebMCP is supported and enabled, an agent can discover three specific capabilities: searching public services, recommending a route based on a need and preparing the context for a contact request. Preparing does not mean sending: the form still requires a person to review it, complete the details and decide whether to submit it.
This does not turn karmina.ai into an autonomous website, nor does it mean that any agent can already operate through it. WebMCP remains experimental, browser support is limited and the API may still evolve. That is precisely why this seemed like a good time to test it: early enough to learn, but through a real use case, with explicit boundaries and a website that continues to work exactly as before for anyone not using this technology.
What WebMCP is and how it differs from a conventional website
WebMCP is a proposal that allows a page to describe actions as structured tools for AI agents. Instead of relying solely on a visual interpretation of the interface, the website declares the action’s name, what it does, which data it accepts and what result it returns. The official Chrome documentation ↗ presents it as a way for agents to work with a page’s functionality more reliably and explicitly.
The difference is similar to moving from a sign to an operational contract. A button might say “Contact”, but a structured tool can specify that it only prepares the context, does not send anything, does not accept personal data and requires human review. The agent no longer has to guess part of the behaviour and receives clearer conditions.
Our implementation uses the WebMCP imperative API ↗: the page registers the tools while it is open and removes them when the component disappears. These tools live within the context of the tab. They are not a general public API or a system that continues to operate after the person has closed the website.
It is also important to distinguish WebMCP from MCP. MCP connects AI applications with data and tools that may live on servers or external systems. WebMCP works with the page a person has open, its state and its visible experience. At Karmina, we have not integrated an MCP server into this experiment. We have started with the smallest, most contextual and controllable layer.
Why we tested it on karmina.ai
The Karmina AI Studio website was already evolving towards a consultative experience: content, services, agents, resources and a conversational beta that helps people make sense of a need. The next step was not to add another chatbot, but to ask whether the website itself could explain its capabilities more clearly when the visitor is an agent.
There were three reasons to experiment now:
- Learning through a real need. We did not want to build an isolated demonstration. The tools work with the existing catalogue and form.
- Testing governance before capability. We began with reading or preparation actions, with no transactions or irreversible changes.
- Understanding the future of our clients’ websites. If agents become a new point of entry, brands will need to decide what they may consult, what they may prepare and what requires confirmation.
The experiment also fits the way of working described in our Manifesto: experimenting does not mean removing responsibility, but building control points that allow us to learn without concealing the limits.
What it can do today, exactly
We have registered just three tools. This restriction is deliberate.
1. Search Karmina services
The agent can consult a limited public catalogue of services, agents and training. The search is deterministic, works in Catalan, Spanish and English, and returns no more than five results, each with a title, description, category and localised route.
If someone asks, “Can Karmina help us reduce repetitive tasks?”, the agent can connect that need with process automation and display the corresponding page. It does not crawl the internet, access the CRM or invent a new offering: it works with sixteen selected public entries.
2. Recommend a route
The agent can turn a challenge into a maximum of three useful pages. A query such as “we need to train the team and understand the AI Act” may lead to AI literacy, in-company training and governance.
The response is guidance, not a commercial decision or a diagnosis. The person decides what to open, what to dismiss and whether they need to speak to the team.
3. Prepare a contact request
The agent can write the project context into the form’s visible field and take the person to it. It does not complete the name, email or consent fields. It does not press the submit button. If the field already contains different text, the tool stops rather than overwriting it.
This is our Human Gate: AI can reduce the friction involved in getting started, but external communication only takes place once a person has seen the result, completed the details and confirmed the action.
What this first version does not do
Explaining the boundaries is part of the product. Today, the three WebMCP tools on karmina.ai:
- do not send forms or emails;
- do not fill in personal data or consent fields;
- do not replace text that a person has already written;
- do not access CRM systems, calendars, budgets or private documentation;
- do not buy, book, publish or alter external information;
- do not retain persistent memory between visits;
- do not turn the chat into an MCP server;
- do not make decisions on a person’s behalf.
This scope is not an accidental shortcoming. It is the boundary we chose in order to test the mechanism with low risk and a visible outcome.
What really took the work
Registering three functions was the shortest part. The important work was turning a human experience into a set of actions that an agent could interpret without receiving more power than it needed.
Moving from pages to a structured catalogue
The website already contained services and content, but an agent needs consistent names, categories, descriptions, keywords and the correct route for each language. We built a selected public catalogue and avoided exposing anything that was not necessary for the search.
Defining strict contracts
Each tool declares an input schema. Search accepts a query, an optional category and a constrained limit. Recommendation accepts a challenge and returns a small number of routes. Contact only accepts non-confidential context. We reject unknown fields, text that is too short or too long, and values outside the expected ranges.
This detail is essential. A tool with an ambiguous description or open-ended input forces the model to interpret too much and makes its behaviour harder to anticipate.
Making security a behaviour, not just a label
WebMCP can indicate whether a tool is read-only or may have consequences. These annotations help the agent, but they do not replace validation. That is why the form protection is implemented in the code: there is no submission call, existing text is preserved and the result explicitly states that human action is still required.
Chrome’s security guidance ↗ notes that models remain exposed to prompt injection and that a tool may operate within an authenticated session. Security cannot rest on the good intentions of descriptive text; it needs permissions, controls and boundaries in the actual logic.
Working with an API that is still changing
The community specification ↗ remains a draft rather than an established W3C standard. Chrome has opened a WebMCP origin trial ↗ starting with Chrome 149. It remains an experimental phase and does not guarantee a general launch.
We needed to test discovery and execution in an experimental Chrome environment, verify the tools’ lifecycle and maintain a safe fallback for browsers that do not provide the API. If WebMCP is unavailable, the website does not fail: it simply continues without this layer.
Testing more than the happy path
Seeing one correct response was not enough. We tested searches in three languages, result limits, permitted routes, invalid inputs, tool registration and removal, overwrite protection and the absence of any contact submission. Automated tests verify that the implemented contract matches the logic, but we still need to validate discovery and execution continuously across different browser and agent combinations.
We are not giving a figure for the number of hours involved because we did not approach the experiment as a fixed-budget project. The relevant cost, for now, is the knowledge gained: what needs to be organised, what can fail and which decisions must be made before exposing an action to an agent.
The most important decision was not technical
We could have turned many more parts of the website into tools. We chose not to. The best-practice documentation ↗ recommends avoiding redundant or overly broad catalogues because they consume context and make it harder to select the right tool.
We preferred three small, understandable capabilities. Two only retrieve information. The third prepares a reversible action and leaves it visible. None of them acts in the background or completes a sensitive operation.
This is an idea that applies to any agent project: do not begin by asking everything AI could do, but what the smallest action is that delivers value while remaining governable.
What it gives us now
We do not yet have a business metric or enough volume to claim that WebMCP improves conversion. What we do have is a functional proof that has produced five lessons:
- Less visual inference. The agent can use an explicit contract instead of inferring the meaning of a button.
- Greater consistency. Recommendations come from a controlled catalogue rather than an improvised response.
- Observable governance. The boundaries are not a generic statement; they can be tested.
- Progressive enhancement. The experimental layer coexists with the conventional website without replacing it.
- Transferable knowledge. What we learn on karmina.ai can inform future projects involving consultative websites, agents and client processes.
We are not presenting these points as results at scale. They are evidence from the implementation that allows us to ask better questions for the next phase.
What it could offer other organisations
The pattern may have different applications depending on the sector. Not every organisation needs WebMCP, nor should every organisation expose the same actions.
| Context | Possible first capability | Required Human Gate |
|---|---|---|
| Service catalogue | Search and compare options | The person chooses and validates the fit |
| Training | Recommend content based on role and level | The team confirms the pathway and enrolment |
| Customer support | Classify an enquiry and retrieve public information | A person handles incidents and sensitive cases |
| Ecommerce | Compare products or prepare a selection | Confirmation before purchase, payment or change |
| Public administration | Locate a procedure and prepare its requirements | Identification, review and submission through official channels |
The value does not depend on the protocol alone. It first requires a Knowledge Foundation, current content, accountable owners, permissions and a clear definition of an unacceptable error. A reliable tool working with bad data merely accelerates the error.
What remains experimental
The integration code is published, but availability is not universal. WebMCP remains in incubation, requires a compatible browser and agent, and may change before it matures. The tools exist while the page is open; they are not a permanent service or a headless automation.
Nor have we yet demonstrated correct selection across a broad variety of agents, real-world volume, production telemetry or business impact. The evaluations recommended by Chrome ↗ include checking whether the agent selects the right tool, extracts the parameters correctly, follows the order of the flow and knows when not to act. This will be a central part of the work if we expand the experiment.
That is why we describe this as an experimentation phase. It is not a label intended to lower expectations, but an obligation to distinguish between what works, what we do not yet know and the conditions that would make an expansion responsible.
How we are preparing for the future
We do not want to tie Karmina’s entire architecture to an API that is still evolving. We are preparing by separating three layers:
- A human website that is accessible and useful in its own right. The content, navigation and forms must continue to work without agents.
- WebMCP as a contextual layer. Small, visible and temporary actions for agents visiting the page.
- MCP or backend APIs when they are genuinely needed. For persistent data, integrations, authentication or processes that do not depend on an open tab.
This separation avoids confusing a browser experiment with an enterprise architecture. It also allows us to replace the technology if the standard changes, because the catalogue, rules, permissions and Human Gates will continue to have value.
Our next step is to observe compatibility, selection quality, errors and real-world usefulness. We will only expand the number of tools if a new capability reduces friction without disproportionately increasing risk, maintenance or the review burden.
A website prepared for agents is not the one that automates the most
It is the one that explains more clearly what can be done, with which data, within which boundaries and who makes the final decision. WebMCP has allowed us to turn this idea into a concrete experiment within karmina.ai.
The experiment is small: three tools, a public catalogue and a form that never submits itself. But it forces us to think about the website differently. It is no longer just a surface that communicates; it can also become a layer of governed capabilities.
You can try Karmina’s conversational beta and explore our work on AI-enabled websites. If you are considering how to prepare a digital experience for people and agents, tell us about the context: we will not begin with the tool, but with the action, the risk and the responsibility.