Guardian Travel WebMCP

A travel itinerary website built for AI agents to read, not just humans to click. Structured WebMCP tools replace brittle UI guessing with grounded site-provided data.

Comment

Inspiration

Modern travel websites are designed for humans, not AI agents.

A traveler can easily understand the difference between a confirmed flight, a hotel booking, an open dining intention, and a rainy-day backup plan. An AI agent that relies on UI scraping, DOM parsing, or screenshots has a much harder job: nested cards, visual chips, labels, and ambiguous text can easily be misread.

We wanted to explore a different approach:

Websites should expose tools to agents, not force agents to guess the UI.

Guardian Travel WebMCP turns an existing travel itinerary into an agent-native website that exposes structured read tools directly through WebMCP.

We do not generate the trip. We make the existing trip readable and adaptable for AI agents.

What it does

Guardian Travel exposes three read-only WebMCP tools:

  • get_trip_summary
  • get_day_itinerary
  • get_rain_backup

These tools let an agent retrieve authoritative, site-provided itinerary data without scraping the interface.

For example, when the user asks:

“It’s raining tomorrow afternoon. What’s my backup plan?”

the agent can call:

  1. get_trip_summary
  2. get_day_itinerary with relative: "tomorrow"
  3. get_rain_backup with relative: "tomorrow", period: "afternoon"

The result is grounded in the itinerary itself. In our demo, the outdoor plan is My Khe Beach and the site-provided backup is a generic café or SPA intention — not an invented business name.

How we built it

The project is a lightweight, dependency-free web application using:

  • HTML5
  • CSS
  • Vanilla JavaScript
  • WebMCP through document.modelContext

The page detects whether a native WebMCP host is available.

When running in a supported native host, the three tools are registered directly with document.modelContext.

For ordinary browsers that do not yet expose WebMCP, the site includes a small in-page compatibility shim so the interface and demo workflow can still be inspected without changing the tool definitions.

The real native WebMCP path was validated in Google Chrome 152 using the native ModelContext implementation. All three tools were discovered and successfully invoked without the shim.

Challenges we ran into

The biggest challenge was making the difference between an entity and an intention explicit.

A travel page may contain a real hotel booking, a confirmed flight, or simply text such as “eat seafood tonight” or “coffee / SPA if it rains.”

A human understands that immediately. An agent scraping the UI may not.

We therefore designed the tool responses to preserve these distinctions and to fail closed when information is unavailable rather than inventing details.

Another challenge was validating the emerging native WebMCP implementation across browser environments. We kept the native path authoritative while using a graceful fallback only for unsupported browsers.

Accomplishments that we're proud of

  • A real native WebMCP host discovers all three tools.
  • All three tools are callable through document.modelContext.
  • The project requires no DOM scraping.
  • Rain-backup queries return only site-provided structured data.
  • The tool layer is read-only and deterministic.
  • The entire public challenge project is only a small set of static files with no backend or API keys.
  • The project is fully open source under the MIT License.

What we learned

The most important lesson was that agent-friendly websites should not depend on agents reverse-engineering presentation layers.

Humans need rich visual interfaces.

Agents need explicit semantic capabilities.

WebMCP gives websites a way to support both.

Instead of treating the web page as something an agent must visually decode, the site itself can provide the agent with the correct tools and structured context.

What's next for Guardian Travel WebMCP

The current challenge version is intentionally read-only and focused.

Future directions could include:

  • richer place details
  • controlled itinerary updates
  • permissioned write tools
  • cross-day adaptation
  • mobile synchronization
  • real-time travel assistance

Any future write capability would remain explicit and permission-gated.

For this challenge, we kept the scope small:

three real tools, one clear travel use case, and no UI guessing.

Built With

Share this project:

Updates

Submission history