The Website That Speaks AI

Turning a real Italian business website into an agent-ready experience with WebMCP, so AI can understand its services, reason about customer needs, and safely prepare real-world actions.

Comment

Inspiration

Most business websites today are designed entirely for humans.

A customer opens a website, navigates through pages, reads about services, tries to understand whether the company can solve a specific problem, finds the contact page, and finally submits a request.

But the way people use the web is beginning to change.

Increasingly, a user may simply ask an AI:

“My security door is stuck in Ceprano. Find someone who can help me and help me contact them.”

This project explores what happens when a real business website is ready for that interaction.

Our core idea is simple:

The web already has an interface for humans. We created a layer for AI agents.

And that led us to a second idea:

Maybe we do not need to teach agents how to use every website. We can teach websites how to speak to agents.

Instead of forcing an AI to reconstruct the meaning of a business by navigating pages, interpreting the DOM and guessing how the website works, the website itself can expose its business knowledge, services, rules, constraints and available actions directly to compatible agents.

Website knowledge → Agent understanding → Reasoning → Human confirmation → Safe action

What we built

We integrated WebMCP into the live website of Show Room La Finestra, a real Italian business operating in windows, doors, security doors, sunshades, aluminium systems, technical assistance and custom metalwork.

This is not a simulated storefront or a website created specifically for the challenge.

It is a real production Joomla website that existed before the challenge and continues to serve real customers normally.

We added an Agent Interface Layer alongside the existing human interface.

Through WebMCP, a compatible AI can discover structured business knowledge and capabilities directly from the website and use them to understand the business, reason about a customer's request and, when appropriate, prepare a safe action.

The implementation exposes structured capabilities such as:

  • business information;
  • available services;
  • detailed service knowledge;
  • contact options;
  • contact request preparation;
  • confirmation-gated submission.

For example, a customer can ask an AI for help with a blocked security door.

The AI can:

  1. discover the WebMCP capabilities exposed by the website;
  2. understand which business service is relevant;
  3. determine what information is needed from the customer;
  4. prepare a structured contact request;
  5. show the complete request to the user;
  6. ask for explicit confirmation;
  7. only after confirmation, proceed with the existing website contact workflow.

The AI therefore does not need to blindly navigate pages and guess what the company does.

The website can explain itself.

Another important design choice is that WebMCP is intentionally not exposed globally across every page of the website.

Different pages have different purposes, so they can expose different agent contexts.

A homepage can explain the business and its services.

A service page can expose service-specific knowledge, rules and constraints.

A contact page can expose contact options and controlled actions.

A page with nothing useful for an agent can expose nothing at all.

The website does not need one large AI interface. Every page can become its own AI interface when it makes sense.

Why WebMCP

WebMCP creates a new interface between websites and AI.

Traditional websites expose visual interfaces optimized for humans.

AI systems can attempt to interpret those interfaces, but important business meaning may be distributed across navigation structures, text, forms and application logic.

WebMCP allows the website to expose that meaning explicitly.

For a local business, this can mean exposing:

  • who the business is;
  • what services it provides;
  • where it operates;
  • service-specific knowledge;
  • business rules and constraints;
  • what information an action requires;
  • which actions are available;
  • when human confirmation is required.

The result is not about replacing the website.

It is about giving the same business two interfaces: one for humans and one for AI.

One website. Two interfaces: Humans + AI.

We also wanted to explore WebMCP without introducing unnecessary infrastructure.

This implementation does not require a separate MCP server for the agent to discover, configure or connect to.

The WebMCP capabilities live directly on the existing website and are exposed through document.modelContext when a compatible client visits a page where the integration is enabled.

The agent does not connect to an MCP server somewhere else. It visits the website — and the website speaks for itself.

Safety and human control

A key design decision was that discovering and preparing an action should not automatically execute it.

For potentially consequential actions such as sending a customer request, the system follows a human-confirmation pattern:

discover → understand → collect → prepare → review → confirm → act

The AI can do the work required to understand the request, collect the required information and prepare the interaction, but the user remains in control of the final action.

Preparation and execution are deliberately separated.

A prepared contact request contains the exact information that would be submitted.

The agent must show that information to the user.

The request cannot be submitted unless explicit confirmation is provided.

Preparation does not equal execution.

The website also exposes bounded business knowledge.

The agent should not invent prices, availability, timing, warranties or other information that the business has not provided.

When something requires confirmation from the company, the agent must treat it as unknown rather than inventing an answer.

How we built it

The existing production website runs on Joomla + Gantry 5.

Rather than rebuilding the website around WebMCP, we added an agent-facing layer to the architecture that was already working.

The integration is loaded through a small deferred JavaScript loader on the pages where agent capabilities are needed.

That layer registers WebMCP tools through:

document.modelContext

The current implementation exposes six structured tools:

  • get_business_info
  • list_services
  • get_service_details
  • get_contact_options
  • prepare_contact_request
  • submit_contact_request

The existing Joomla website continues to serve human visitors normally.

No Joomla Core modification was required.

No database modification was required.

No external LLM API was required.

No new AI backend was required.

No separate MCP server was required.

The WebMCP layer works as progressive enhancement.

If WebMCP is unavailable in the browser, the normal website continues to work unchanged.

If WebMCP is available, the same website gains an additional structured interface for compatible agents.

We also reused the existing Joomla contact workflow rather than creating a parallel contact system.

After explicit user confirmation, the WebMCP layer can use the website's existing same-origin Joomla form and its current validation and CSRF protection.

This allowed us to explore an important question:

Can an existing real-world business website become agent-ready without replacing the systems that already work?

Our implementation demonstrates that it can.

Challenges

The biggest challenge was not simply exposing tools.

It was deciding what an AI should be allowed to understand and do.

Real businesses contain ambiguity.

Services overlap.

Customer requests can be incomplete.

Location can matter.

Information can change.

An AI should not invent business capabilities, prices or availability.

And an action should not happen simply because the AI is technically capable of performing it.

We therefore focused on:

  • clear business semantics;
  • bounded capabilities;
  • explicit rules and constraints;
  • page-specific context;
  • safe failure behavior;
  • human confirmation before consequential actions.

Another challenge was deciding how much context should be exposed to an agent.

A simple approach would have been to expose the same large set of tools and information everywhere.

Instead, we chose a page-scoped architecture.

Different pages can expose only the knowledge and capabilities that make sense in that context.

This keeps the agent context smaller, more relevant and easier to control.

Another important challenge was integrating this new agent-facing layer without disrupting the existing production Joomla website.

The goal was not to create a WebMCP demonstration website.

The goal was to make an existing website WebMCP-capable while preserving the website that customers already use.

What we learned

The most important lesson was that WebMCP is not only about browser automation.

It can change the relationship between a website and an AI.

Instead of asking:

“How can an AI learn to use this website?”

we can ask:

“How can this website clearly describe itself and its capabilities to an AI?”

That is a very different architectural perspective.

The website stops being only an interface that the agent must interpret.

It can become an active source of structured context.

We also learned that pages can be useful boundaries for agents, just as they already are for humans.

For humans, pages organize information.

For agents, pages can organize context, knowledge, tools and actions.

This means WebMCP does not necessarily need to become one global layer containing everything a website knows.

Capabilities can be progressively exposed only where they are relevant.

Page → Context → Knowledge → Tools → Safe Actions

We also found that supporting agents does not necessarily require adding intelligence to the website itself.

The AI can remain in the client.

The website only needs a structured way to explain itself to that intelligence.

What's next

This implementation focuses on one real Italian business, but the architecture points toward something broader.

Millions of small businesses already have websites.

They already contain business knowledge, services, forms, rules and working processes.

They should not necessarily need to rebuild everything for an AI-driven web.

They may not need a chatbot.

They may not need a new AI backend.

They may not need a separate MCP server.

They may simply need an additional layer that allows their existing website to become understandable and safely actionable by AI.

The current implementation demonstrates the concept on selected areas of the website.

The next step would be to progressively extend the same page-scoped model.

A product page could expose structured product knowledge.

A service page could expose technical constraints and service-specific tools.

A booking page could expose availability and controlled booking actions.

A support page could expose diagnostics and assistance workflows.

Each page could describe only what the agent needs in that context.

The long-term idea is simple:

Do not rebuild the web for agents. Let the existing web learn how to speak to them.

Website knowledge → Agent understanding → Reasoning → Human confirmation → Safe action.

Built With

Share this project:

Updates

Submission history