Ticketnauta Seat Concierge

An agent-ready ticketing experience where AI finds, compares, highlights, and holds the best contiguous seats through nine secure WebMCP tools—without touching real inventory.

Comment

Inspiration

Buying tickets looks simple until real-world constraints appear: a group needs seats together, the budget is total rather than per seat, someone prefers a specific zone, accessibility matters, and availability may change while options are being compared. Traditional interfaces leave the user repeatedly adjusting filters and visually scanning a large map.

We built Ticketnauta Seat Concierge to explore a better model: let an AI agent handle the combinatorial search while the person keeps visual context, judgment, and control. Seat selection is an ideal WebMCP use case because it combines structured data, live page state, visual comparison, and consequential actions such as temporary holds.

The project is a completely isolated demonstration. It does not connect to real Ticketnauta inventory, customers, sessions, payments, or production APIs.

What it does

Ticketnauta Seat Concierge lets people and browser agents collaborate on the same interactive seat map.

A user can ask:

Find four contiguous seats under MX$7,000, prioritize centered seats, show me alternatives, and ask before holding the best option.

A compatible browser agent can then use nine purpose-built WebMCP tools to:

  • Search fictional events.
  • Inspect event details, zones, prices, and availability.
  • Find contiguous seat combinations by quantity, total budget, zone, and priority.
  • Highlight recommended seats on the visible map.
  • Select an option.
  • Create or release a temporary hold.
  • Read the cart and hold expiration.
  • Complete an explicitly confirmed simulated checkout.

The interface shows ranked alternatives, accessible-seat markers, selected seats, unavailable seats, prices by zone, a cart summary, and a live hold countdown. Every agent action is reflected immediately on the page.

The conversation timeline distinguishes built-in guided interactions from actual browser-agent calls using separate GUIDED and WEBMCP labels. This makes the experience transparent and avoids presenting a local command parser as an external AI agent.

Every event, venue, seat, price, hold, and checkout result in the demo is fictional. No payment is collected and no ticket is issued.

How we built it

The WebMCP tools are registered directly from the main document—without an iframe—using document.modelContext.registerTool().

Each tool has a narrow JSON Schema, rejects undeclared properties, and reuses the same application functions as the visible interface. This keeps manual interactions, guided requests, and browser-agent calls synchronized.

We deliberately separated tool responsibilities:

  • Read-only tools handle event search, details, seat recommendations, and cart state.
  • Visual page actions handle highlighting and selection.
  • Consequential actions handle holds, release, and simulated checkout.
  • Checkout requires the explicit confirmation value SIMULATE_CHECKOUT.

The frontend uses dependency-free HTML, CSS, JavaScript, and an interactive SVG seat map. The backend is a .NET 10 ASP.NET Core Minimal API using Npgsql and PostgreSQL.

An idempotent bootstrap creates and seeds only the isolated webmcp_demo PostgreSQL schema. Temporary holds use transactional availability checks and event-level locking to prevent conflicting reservations. Expired holds become available again, and the reset operation deletes only runtime demo records.

The application is packaged with a multi-stage Dockerfile and Docker Compose. It includes health checks, Windows/WSL/Linux instructions, an optional self-contained PostgreSQL profile, and a Cloudflare Tunnel profile. The public demonstration runs through HTTPS without opening router ports.

Challenges we ran into

The first challenge was designing tools at the correct level. A single tool that “buys the best seats” would hide too many decisions, while extremely small tools would force the agent to reproduce ordinary UI automation. We designed a focused middle layer where discovery, recommendation, visual feedback, selection, holds, and checkout remain separate.

Another challenge was keeping three interaction paths synchronized: manual controls, the guided concierge, and external WebMCP calls. Every path had to update the same map, recommendations, cart, and activity timeline without creating contradictory state.

Seat recommendations also required more than sorting by price. The algorithm must preserve contiguity, enforce a total budget, consider zones and accessibility, rank proximity or center position, and still return useful alternatives.

Temporary holds introduced concurrency and expiration concerns. We addressed these with PostgreSQL transactions, availability checks, advisory locking, explicit release, and automatic expiration.

Finally, WebMCP is still experimental and requires a compatible browser agent and a secure HTTPS context. We built a deterministic guided experience so visitors can understand the product even without WebMCP support, while clearly identifying which calls come from a real browser agent.

Accomplishments that we're proud of

We are proud that this is a complete, working journey rather than a static interface or isolated tool demonstration.

The project includes:

  • Nine discoverable WebMCP tools with strict schemas.
  • A responsive and accessible interactive seat map.
  • Multi-constraint contiguous-seat recommendations.
  • Visible alternatives and map highlighting.
  • PostgreSQL-backed temporary holds and expiration.
  • Explicit release and simulated checkout flows.
  • A transparent activity timeline for human and agent actions.
  • A fully isolated fictional dataset.
  • A reproducible .NET 10, PostgreSQL, Docker, and Cloudflare deployment.

Most importantly, the agent does not replace the interface. It collaborates through it, and the person can see and evaluate every meaningful action.

What we learned

We learned that WebMCP is not simply a way to add a chatbot to a website. Its real value is giving an agent a structured, browser-mediated contract for what the page can safely do.

Tool design is product design. Names, descriptions, schemas, result shapes, and action boundaries directly influence whether an agent behaves predictably.

We also learned that visual transparency remains essential. Even when an agent can find the mathematically best option, people still want to compare alternatives, understand tradeoffs, inspect the map, and approve consequential actions.

Finally, separating read-only operations from state-changing actions makes both the implementation and the user experience easier to reason about.

What's next for Ticketnauta Seat Concierge

Next, we would expand the fictional demo with richer venue layouts, additional accessibility preferences, multilingual requests, more detailed explanations for recommendation scores, and automated WebMCP regression tests.

We would also explore configurable approval policies so users can decide which actions an agent may perform automatically and which always require confirmation.

The larger vision is an open web where agents do not need to guess how interfaces work from pixels. Websites can expose safe, narrow, purpose-built capabilities while people retain context, visibility, and final control.

Built With

Share this project:

Updates

Submission history