• 

  Torubrick: The AI operating system for tourism professionals

Tourbrick — About the project

Tagline

A shared WebMCP workplace where tour operators, travellers, and their AI agents co-create trips together.

Inspiration

I am a tour guide and tour operator. A good private trip depends on hundreds of details that do not fit neatly into a booking form: relationships with suppliers, scenic roads, seasonal nuances, great meals, rooms with a view, and my professional experience. Much of this knowledge still lives in documents, messages, and people’s heads.

Traditional back-office software can store records, but it struggles to create interesting, inspiring trips with local specifics. General AI can suggest a generic itinerary, but it does not know what the tour company can actually provide, and it should not make silent changes to operational records.

That's why we create Tourbrick — a space where professional tour operators and AI agents can work together.

What it does

Our demonstration begins with a real kind of request that is difficult to serve from a catalogue: a couple wants to spend five days travelling around Estonia and experience the sauna culture. The company has no pre-designed tour for that.

First, ChatGPT uses Tourbrick’s WebMCP tools to read the original message and turn it into a structured brief.

Then, ChatGPT can search Tourbrick’s inventory: individual experiences, suppliers, accommodation options, transfers, etc. From those records, it can assemble a custom trip around four sauna experiences grounded in the real-world services that we work with.

Tourbrick turns the selected records into a five-day itinerary with a stored road route and a timetable for every day. The manager can open day three and see breakfast, the drive south, lunch, the Mooska smoke-sauna experience, the hotel, and dinner in chronological order. Each item remains connected to its supplier record, rate, duration, and conditions. Costs are grouped into accommodation, experiences, transportation, and meals, with every line behind the total.

Nothing is silently committed. Tourbrick first creates a no-write preview. The manager can inspect, edit, or reject it; accepting saves exactly the reviewed version. It does not book a supplier, send a message, or take payment.

Once reviewed, the same trip becomes a customer presentation. For this prototype, we created a sauna-led presentation to give it a personal feeling instead of the fixed website template. The customer page is also WebMCP-enabled. Travellers can open it with their own ChatGPT, focus a specific day, and prepare feedback such as: “Could we replace day two’s spa with a quieter countryside sauna?”

Why WebMCP

A conventional MCP server can expose a database or service even when no webpage is open. That is useful, but it is not the experience we wanted to create.

With WebMCP, the webpage itself becomes the integration and the shared workspace. ChatGPT discovers the tools offered by the page the person is currently viewing and works in the same live context. The manager and the agent can look at the same request, map, timetable, and cost review. When the traveller opens the public proposal, their ChatGPT discovers a separate, customer-safe set of tools without requiring access to the operator’s workspace or a separately configured Tourbrick MCP connection.

Before this, an operator had to manually reconcile records across spreadsheets and back-office screens, or copy incomplete context into a chat. Customer feedback arrived separately and then had to be matched back to the right trip and day. With Tourbrick, both agents work against the relevant structured version while people see and control the decisions on the page.

What we built during the hackathon

Tourbrick builds on an existing tour-operations product direction and domain model. During the WebMCP Challenge, we created the agent collaboration layer and the complete end-to-end experience demonstrated in the video:

• Tour operator tools for reading customer requests, publishing grounded briefs, searching inventory, previewing and creating custom trips, inspecting saved versions, and opening exact itinerary days.
• A visible operator journey from an ordinary customer message to a mapped, costed, day-by-day and hour-by-hour private trip.
• Preview-before-write controls, explicit approval, content hashes, immutable versions, idempotency protection, and loud rejection of stale data.
• Persisted Mapbox routes that are calculated when a new connection is needed and then reused rather than recalculated on every view.
• A separate customer presentation with three public, customer-safe WebMCP tools for reading the shared proposal, focusing a day, and drafting an unsent change request.
• Live deployments for both operator and customer experiences, plus the public source repository, setup instructions, and automated tests.

How we built it

The operator and customer interfaces use React, TypeScript, Vite, and Tailwind CSS. Each top-level page registers typed tools with document.modelContext.registerTool(...), including a clear name, description, JSON input schema, execution handler, and read/write annotations.

The application API is built with FastAPI and Pydantic, with PostgreSQL storing inventory, requests, immutable trip versions, customer presentations, and reusable route geometry. Mapbox provides road routing. The customer presentation runs against a separate public-only backend that does not expose manager routes, API documentation, or the operator MCP surface.

The most difficult part was making agent work operationally trustworthy. A proposal can combine many records and prices, so approval is bound to the exact preview the manager saw. We also had to keep route legs connected to real timetable transfers so the map and itinerary describe the same journey.

The finished workflow was tested end to end using ChatGPT’s in-app browser. The public repository’s 209 frontend tests and 203 backend tests cover tool registration, validation, approvals, versioning, routing, customer isolation, and the visible workflows.

What we learned

The important change about WebMCP is that the human interface and the agent interface no longer need to be separate products. The page can expose precise actions while still giving the person a map, itinerary, evidence, costs, and a clear approval boundary.

We also learned that different people should not receive the same tools. The operator can search inventory and create a trip; the traveller can read the shared proposal and prepare feedback. Both collaborate with AI around the same journey, but Tourbrick preserves the responsibilities and access of each participant.

What’s next

The sauna presentation demonstrates a larger direction: customer proposals do not have to be forced into one fixed website template. An agent could compose the presentation around what matters to that particular traveller — saunas for this trip, wildlife, food, architecture, or accessibility for another — while the underlying itinerary remains structured and reviewable.

The next product steps are live supplier availability, contracted rates, richer operator permissions, and turning confirmed customer feedback into a manager-reviewed itinerary revision.

For my business — and for more than a million tour operators like me — WebMCP moves AI out of a separate chat window and into the work itself.

Built With

• codex
• python
• typescript