Inspiration

The web has traditionally been built for humans: users navigate pages, understand UI elements, apply filters, select options, and complete forms. With the rise of AI agents, we believe the web needs to become equally usable by agents.

Bus booking is a great example of this problem. A user may simply say, "Find me the best bus from Bangalore to Chennai tomorrow evening with good reviews and a window seat." Today, an AI assistant can help explain options, but the actual interaction still requires navigating the booking website.

We wanted to explore what happens when the website itself becomes agent-ready.

With WebMCP, we can expose meaningful capabilities of the bus booking experience as tools that an AI agent can understand and invoke directly. This led us to build BusTravelAssistant — an experiment in making a real-world travel booking journey native to the agentic web.

What it does

BusTravelAssistant enables an AI agent such as ChatGPT to interact with the bus booking experience through WebMCP.

Instead of asking an agent to simply navigate and click through a website, the website exposes high-level capabilities such as:

  • Searching for buses between two locations
  • Exploring available travel options
  • Applying relevant filters
  • Comparing available buses
  • Selecting a bus and travel option
  • Viewing and selecting available seats
  • Progressing through the booking journey

The key idea is that the website provides the capabilities and context, while the AI agent determines how those capabilities should be used to accomplish the user's goal.

This creates a much more natural interaction model:

User → AI Agent → WebMCP Tools → Website → Booking Journey

The user can express an intent in natural language, while the agent can use the website's structured capabilities to execute that intent.

How we built it

We built BusTravelAssistant by exposing key capabilities of the bus booking funnel as WebMCP tools.

The tools are designed around meaningful user actions rather than low-level UI interactions. For example, instead of asking an agent to identify a button and click it, we expose capabilities such as searching for buses, applying filters, and selecting seats.

The architecture broadly consists of:

  1. Web application — the existing bus booking experience.
  2. WebMCP tool layer — exposes booking capabilities to compatible AI agents.
  3. AI agent — understands the user's intent and decides which tools to invoke.
  4. Booking funnel — executes the requested actions and maintains the user's journey.

A key design principle was to keep the tools task-oriented and composable. The agent should not need to understand the internal implementation of the website. It should only need to understand what each capability does, what inputs it accepts, and what information it returns.

This allows the same web experience to serve both human users and AI agents.

Challenges we ran into

One of the biggest challenges was deciding the right abstraction level for WebMCP tools.

If tools are too granular, the agent has to orchestrate dozens of low-level actions. If they are too broad, the tools become difficult to compose and less reusable.

We therefore focused on exposing capabilities that map closely to real user intent while still giving the agent enough flexibility to make decisions.

Another challenge was maintaining the state of a multi-step booking journey. Searching for a bus, applying filters, selecting a specific service, and choosing a seat are all connected actions. The tools need to work together while preserving the context of the user's journey.

We also had to think carefully about validation and safety. An AI agent should be able to explore and narrow down options autonomously, while actions that have real-world consequences should remain appropriately controlled.

Accomplishments that we're proud of

We are particularly proud of demonstrating that a complex, multi-step travel workflow can be exposed to an AI agent through WebMCP without turning the website into a collection of UI automation scripts.

The project demonstrates a different mental model for building websites:

Don't just build pages for agents to navigate. Build capabilities for agents to use.

We also built the tools around an actual booking funnel rather than a simplified demo, which helped us understand the practical challenges of making a production-scale web experience agent-ready.

Most importantly, BusTravelAssistant gave us an opportunity to explore what an agent-native version of a real-world web application could look like.

What we learned

The biggest learning was that WebMCP changes how we think about the boundary between an AI agent and a website.

Traditional browser automation makes the agent responsible for understanding the UI. WebMCP allows the website to communicate its capabilities explicitly.

This creates a much cleaner separation:

  • The website owns the capabilities and business context.
  • The agent owns reasoning and orchestration.
  • The user owns the intent and final decisions.

We also learned that designing good tools is as important as exposing tools. Tool names, descriptions, inputs, outputs, validation, and state management all significantly influence how effectively an agent can use a web application.

What's next for BusTravelAssistant

We see this project as the beginning of an agent-native travel experience rather than simply a WebMCP integration.

The next step is to expand the capabilities exposed through WebMCP across the complete travel lifecycle — from discovery and booking to managing trips and finding relevant services around a journey.

We also want to explore richer agent interactions where the user can express a high-level goal and the agent can intelligently combine multiple web capabilities to accomplish it.

Ultimately, our vision is simple:

The future web should not only be human-readable. It should be agent-readable, agent-understandable, and agent-actionable — while keeping humans in control.

BusTravelAssistant is our experiment toward that future.

Built With

Share this project:

Updates

Submission history