We added WebMCP to our website. Here's what we learned.

The Question We Were Trying to Answer

We recently started exploring how to make the Thoughtful Robots website more useful to AI agents.

Our website was already built for people, and much of its content was also available to agents through Markdown pages and llms.txt. But as agents become capable of doing more than simply reading information, we wanted to understand what else a website could make available to them.

That led us to a simple question:

Can we make our website easier for AI agents to interact with, without duplicating what is already there or creating unnecessary infrastructure to maintain?

One of the approaches we explored was WebMCP.

We implemented it on our own website, tested where it added value and where it did not, and came away with a much clearer view of what WebMCP can do — and how early it still is.

What Is WebMCP?

Websites are primarily designed for people. We read pages, understand menus, click buttons and fill in forms. AI agents can increasingly do the same, but they often have to first interpret the page and work out how to interact with it.

WebMCP gives a website a way to explicitly tell an AI agent what it can do.

It does this through tools. In this context, a tool is simply a capability that the website makes available to an agent in a structured way.

Imagine a hotel website. Instead of an agent having to find the booking form, identify the right fields and work out how to use them, the website could expose a check_availability tool that clearly says what it does and what information it needs — such as the check-in date, check-out date and number of guests.

The agent now has a defined way to ask the website to perform that task.

Importantly, this does not replace the website or its interface for people. WebMCP adds an agent-facing way to interact with selected capabilities of the same website.

That relatively simple idea — websites explicitly describing what agents can do — is what makes WebMCP interesting.

Why Is WebMCP Emerging Now?

Until recently, websites could largely assume that the visitor interacting with them was a person. That assumption is beginning to change.

AI agents can now browse the web, gather information and increasingly carry out tasks on behalf of people. But most websites still communicate what they can do through interfaces designed for humans — pages, menus, buttons and forms.

Agents can interpret these interfaces too, but they often have to work out the website's capabilities from the interface itself.

WebMCP explores a different approach: what if the website could explicitly describe those capabilities to an agent?

Instead of relying entirely on an agent to interpret how a website works, the website can provide a structured way for the agent to understand and use selected actions.

As agents become another way through which people interact with the web, that could become an increasingly useful interface to provide.

Where Could WebMCP Be Useful?

WebMCP becomes particularly interesting when an agent needs to do something on a website, rather than simply read what the website says.

Imagine a hotel website exposing a check_availability tool. An agent could provide the dates and number of guests and receive the available options.

A healthcare website might expose a find_appointment tool. An online store could offer a find_products tool. A support website could provide a create_support_request tool.

These tools give the agent a defined way to perform a task, rather than requiring it to work out the task entirely from pages, buttons and forms.

The website owner also decides what each tool can do. A tool might only retrieve information, prepare an action for a person to review, or be permitted to complete certain actions directly.

This distinction is important: making information easier for agents to read and giving agents a structured way to act are two different problems.

And that distinction became particularly important when we implemented WebMCP on our own website.

What We Built at Thoughtful Robots

Before adding WebMCP, we had already taken a few steps to make the Thoughtful Robots website easier for AI agents to understand.

Alongside the normal HTML website, we provide Markdown versions of our pages. Markdown strips away much of the visual presentation of a webpage and presents the important content in a simpler, structured form. This can make it easier for an agent to read and understand what a page contains.

We also provide an llms.txt file. A useful way to think about llms.txt is as a guide to the website for AI systems. Rather than making an agent discover every useful page on its own, the file points it towards important content and machine-readable resources available on the site.

For example, an llms.txt file might effectively tell an agent: here is what this organisation does, and here are the pages where you can learn about its services, products and other important information. The agent can then follow those references to the Markdown versions of the relevant pages.

Together, these already solved much of the reading and discovery problem. An agent did not need a WebMCP tool simply to understand who we are, what we do or what our services are.

So we kept our WebMCP implementation deliberately small. We created three browser tools:

• read_page — provides a defined way to read a page.
• go_to — allows an agent to navigate to an allowed page on the website.
• talk_to_us — helps an agent initiate the contact process.

The third tool is where WebMCP became more interesting for us.

If someone asks their agent to contact Thoughtful Robots, talk_to_us can open our actual contact form with the relevant information filled in. The person can review what has been entered and decide whether to press Send.

Importantly, the tool does not bypass the website's existing safeguards. Turnstile remains part of the normal submission process, and the final decision to submit remains with the person.

This gave us a useful separation: Markdown pages and llms.txt help agents discover and understand our website. WebMCP gives them a structured way to interact with selected capabilities of it.

What We Learned Building It

Building WebMCP on our own website helped us understand an important distinction: just because something can be exposed as a tool does not mean it needs to be.

For us, the website already had good ways for agents to discover and read information through Markdown pages and llms.txt. Creating another tool simply to provide the same information would add relatively little.

That is why the three tools we implemented were useful in different ways.

read_page and go_to give agents a defined way to read and navigate the website. But agents can already read webpages and follow links, so the additional value here is mainly in providing a clearer interaction contract.

talk_to_us was different. It demonstrated where WebMCP could add something more meaningful. Instead of an agent merely finding our contact page, the tool can prepare the actual interaction by opening the contact form with the relevant information filled in. The person still reviews it and decides whether to submit it.

That led us to a useful principle for our website:

Use static content for reading. Use browser tools where they make interaction with the live website meaningfully better.

We also found that the ecosystem is still early. In our testing, agents did not always use the WebMCP tools unless they were explicitly prompted to do so. That makes us cautious about relying on WebMCP for an important user journey today.

So we treated WebMCP as progressive enhancement. The website continues to work normally for people and remains understandable to agents without WebMCP. Where WebMCP is available and useful, it provides an additional, more structured way for an agent to interact with the site.

Perhaps our biggest learning was therefore a simple one:

The question is not "What can we turn into a tool?" It is "Where does giving an agent a tool actually make the experience better?"

Where WebMCP Stands Today

WebMCP is still early.

WebMCP is still an emerging standard. Browser support is currently experimental, and the specification itself is continuing to evolve.

That matters when deciding how much to depend on it.

We think WebMCP is useful to experiment with today, particularly as a way to understand how websites might expose selected capabilities to AI agents. But we would not yet make an important website journey dependent on it.

Our implementation reflects that. The Thoughtful Robots website continues to work normally without WebMCP. Markdown pages and llms.txt help agents discover and understand the site, while WebMCP adds an experimental interaction layer where it is useful.

For us, WebMCP today is an opportunity to start building and learning — and to understand how websites may evolve as AI agents become another way people interact with them.

Exploring WebMCP for your website?

At Thoughtful Robots, we can help organisations explore where WebMCP could be useful, identify which website capabilities are worth exposing to agents, and implement and test them without disrupting the existing experience.

The goal is not to add WebMCP everywhere, but to find where agent interaction can genuinely make the website more useful.

If you're exploring how to make your website ready for AI agents, we'd be happy to work through it with you.

Explore our workshop