trip_world

home page
Webmcp

Inspiration

Travel planning is usually spread across search engines, hotel websites, maps, booking platforms, and personal notes. People have to repeatedly copy information between different services, while AI agents struggle to work with websites that were designed only for visual human interaction.

We wanted to explore a different model: a travel workspace where humans and AI agents can work with the same structured information and the same itinerary. The goal was not to remove the human from the process. The goal was to make discovery and planning easier while keeping important decisions visible and human-controlled.

This idea became trip_world — a shared WebMCP travel workspace built around the principle:

You go. We go.

What the project does

trip_world helps users search destinations, compare travel options, inspect details, and build an itinerary in one place.

The interface starts with a focused destination view instead of displaying the entire world catalog at once. Users can search by city, country, region, travel style, or destination highlight. Only a small number of destination cards are shown at a time, and navigation controls allow users to browse further places without overwhelming the screen.

After selecting a city, the workspace displays options belonging to that destination. These options include hotels, flights, activities, parks, tourist spots, transport references, and offers. Users can filter and compare records using information such as price, rating, tags, duration, accessibility, and cancellation details.

Every selected item can be added to the shared itinerary. The itinerary displays selected items, source links, INR prices, the running total, and an activity ledger showing recent human and agent actions.

How WebMCP is used

WebMCP is the central technical feature of the project. It allows compatible AI agents to use structured capabilities exposed by the webpage instead of relying only on visual screen interpretation or fragile DOM scraping.

trip_world registers 37 WebMCP tools covering:

Destination discovery.
City selection.
Travel dataset search.
Category and budget filtering.
Hotel, flight, park, activity, tourist spot, and offer discovery.
Option comparison.
Details and source-link inspection.
Price and recommendation analysis.
Shared itinerary updates.
Trip-change previews and human review.

The human and the agent use the same application state. When an agent searches for Goa hotels or adds an option to the itinerary, the visible interface updates and the activity ledger records the action. This makes the collaboration understandable instead of hiding agent behavior in a separate conversation.

The project also separates planning from sensitive actions. Payment and checkout are not exposed as WebMCP tools. Reservation-related actions remain human-controlled through the visible interface, and the Razorpay integration is limited to test mode.

How we built it

The frontend was built with React, TypeScript, and Vite. The backend uses Node.js, Express, and TypeScript. The WebMCP integration is implemented through the imperative tool-registration API.

The travel data is stored in a structured TypeScript dataset containing city metadata and catalog records. Cities include information such as country, region, climate, local currency, ideal stay duration, daily budget guidance, travel styles, and highlights. Travel options include structured fields for category, price, rating, tags, duration, accessibility, cancellation details, and reference links.

The application uses a shared state model for:

Selected destination.
Current search query.
Active filters.
Search results.
Itinerary items.
Activity events.
Pending trip-change proposals.

For safety, itinerary entries are validated against the known catalog. The server recomputes reservation totals from server-side data rather than trusting a client-provided amount. Razorpay signatures are verified server-side, and secret credentials are never included in the client bundle or GitHub repository.

The interface was designed with a responsive editorial style. It includes a compact destination carousel, contained scrolling for the itinerary and activity panels, responsive mobile behavior, source links, visual feedback, and lightweight animations.

What we learned

The most important lesson was that agent-ready websites need more than a visually attractive interface. They need clear capabilities with predictable names, strict input schemas, useful descriptions, and outputs that an agent can reliably understand.

We learned that shared state is essential for human-agent collaboration. A tool call is much more useful when its result is immediately reflected in the same interface that the human is watching.

We also learned that tool annotations and action boundaries matter. Read-only discovery tools should be separated from state-changing tools. Actions that change an itinerary need clear review behavior. Payment and checkout require a stronger human boundary than ordinary travel research.

Another lesson was the importance of data quality. A large dataset is useful only when its records have consistent fields, stable identifiers, meaningful categories, source links, and predictable filtering behavior. Structured records make it possible to produce explanations such as destination comparisons and budget recommendations without manually writing every response.

Challenges

Making WebMCP registration reliable

Browser APIs may become available after the page has mounted. We added retry behavior, duplicate-registration protection, awaited tool registration, and strict JSON schemas so the tool surface becomes available reliably when supported by the browser.

Preventing stale destination results

When a user or agent changes destinations, previous results can become misleading. We updated the state flow so selecting a destination clears stale filters and results before loading the new destination's options.

Designing for a large dataset without overwhelming the user

The application contains a world-scale structured catalog, but displaying every destination immediately would make the interface difficult to use. We solved this with search, pagination-style carousel controls, focused result cards, filters, and an explicit no-results state.

Protecting sensitive operations

Travel planning and payment have different risk levels. We kept discovery and itinerary assistance available to agents but intentionally excluded payment and checkout from WebMCP. Test payment credentials remain server-side, and payment signatures are verified by the backend.

Keeping local and hosted behavior consistent

The project supports local Express execution and Vercel serverless deployment. We added a Vercel API adapter and routing configuration so the frontend and backend routes can be deployed together while preserving the local development workflow.

Creating a useful demonstration

A project like this needs to be shown functioning, not only described. The most important demo flow is a live destination search, city selection, option filtering, WebMCP tool execution, itinerary update, proposal preview, and human approval. This demonstrates the difference between a static travel interface and a collaborative agent-ready workspace.

Current limitations

The current travel catalog is a structured demonstration dataset. It is not a live hotel inventory, real-time flight feed, or guaranteed commercial offer source. Prices and offers are intended for exploration and demonstration.

The Razorpay integration is configured for test mode only. A production version would need persistent storage, webhook validation, rate limiting, monitoring, refund handling, current provider data, and additional compliance review.

The next version could connect authorized live travel providers, add persistent user accounts, include maps and route planning, support calendar export, and provide more advanced trip proposals.

Why this project matters

trip_world demonstrates how the open web can become more useful to both humans and AI agents when websites expose structured, understandable capabilities.

The human remains the decision-maker. The agent becomes a capable planning partner. Both can work with the same information, see the same itinerary, and understand what changed.

That is the future we wanted to explore with trip_world: