AyMateo Tickets

• 

  Initial WebMCP state — the demo event is loaded and the shared cart starts empty.

• 

  WebMCP reserves tickets and the human-visible Shared Cart updates with the temporary hold.

• 

  Checkout prepared — the agent stops before payment and explicit human confirmation is required.

• 

  Human experience — users can open the full seating map and select seats manually without WebMCP.

• 

  1. Three seats selected and reserved in the standard human checkout flow before payment.

Inspiration

Ticket buying is usually designed for only one kind of user: a human clicking through a website.

But AI agents are increasingly helping people search, compare options, and complete multi-step tasks. We wanted to explore what ticketing could look like if a website were designed for both humans and agents from the beginning.

AyMateo already had a pre-existing ticketing platform with event pages, seat inventory, temporary holds, carts, and checkout infrastructure. For the WebMCP Challenge, we extended that platform with a structured agent-native interaction layer instead of building a disconnected chatbot or a demo that only returns static data.

Our goal was simple: let an AI agent help a person discover a Bolivian cultural event, compare tickets, reserve real inventory, and prepare checkout while the human can see and understand every action happening on the same page.

What it does

AyMateo Tickets exposes seven WebMCP tools directly from the website:

• search_events
• get_event_details
• get_ticket_options
• add_tickets_to_cart
• remove_tickets_from_cart
• get_cart_summary
• prepare_checkout

An agent can search for cultural events using natural language, retrieve structured ticket information, reserve tickets, inspect the cart, and prepare an order.

The important part is that these actions are not isolated from the normal website.

When the agent adds tickets, the human-visible Shared Cart updates too. The same browser session contains the ticket hold, prices, expiration state, and prepared checkout. The Agent Activity panel also makes the agent's actions visible instead of hiding them behind an invisible automation.

Humans can still use the normal ticketing experience, including the full seating map.

Payment is intentionally excluded from the WebMCP action surface. prepare_checkout only creates a pending order, and final payment still requires explicit human confirmation.

How we built it

The project uses Next.js, React, TypeScript, PostgreSQL, Prisma, Docker, and WebMCP's imperative API.

On the /webmcp page, the application registers tools through:

document.modelContext.registerTool(...)

Each tool connects to real server-side ticketing logic rather than mocked frontend state.

Event discovery reads published events and current ticket availability from PostgreSQL. Ticket mutations create real temporary seat holds using the same transactional inventory system used by the human ticketing experience.

The WebMCP page and the normal website share the same browser checkout session, which allows human and agent actions to stay synchronized.

For the challenge deployment, we created an isolated WebMCP environment with its own PostgreSQL database and fictitious Bolivian cultural-event data. The demo is publicly available over HTTPS at:

https://webmcp.aymateo.com/webmcp

The public submission repository is also separated from the private development history and was scanned for secrets before publication.

Challenges we ran into

One of the biggest challenges was making WebMCP interaction truly stateful.

Searching for an event is easy, but reserving tickets means the agent must interact with temporary inventory holds, browser-session state, expiration rules, backend validation, and the same cart the human sees.

We also encountered browser lifecycle issues while registering imperative WebMCP tools. Tool execution needed to remain stable even when React state changed, so registration and handler lifecycles had to be carefully separated.

Another challenge was natural-language discovery. A strict substring search worked for controlled test inputs but could fail when an agent sent a phrase such as "Find me a Bolivian cultural or folklore event under Bs 100." We improved the search logic so it remains deterministic while handling meaningful words from natural agent requests.

Finally, we wanted the agent to be useful without giving it unsafe authority. That led us to draw a clear boundary: agents may search, compare, reserve, and prepare checkout, but they cannot complete payment.

Accomplishments that we're proud of

We are especially proud that WebMCP is not just decorative in this project.

The agent can perform a complete, visible journey:

event discovery → ticket comparison → real temporary reservation → shared cart → prepared checkout.

The ticket reservation is backed by actual PostgreSQL inventory and transactional seat-hold logic rather than a fake demo cart.

We also built the experience so that human and agent interactions remain inspectable. The Shared Cart and Agent Activity panels show what the agent changed, while the normal seating-map experience remains available for people who prefer to interact manually.

The complete WebMCP flow is deployed publicly and has been tested end-to-end using the Model Context Tool Inspector.

What we learned

The biggest lesson was that agent-native websites should not necessarily replace human interfaces.

WebMCP is most interesting when the agent and human can collaborate with the same application state.

Structured tools give an agent a safer and more reliable way to interact with a website than interpreting buttons and rendered text, while the visual interface still gives the human context, control, and confidence.

We also learned that tool design matters as much as implementation. Clear schemas, read-only annotations, untrusted-content boundaries, backend validation, and explicit limits on high-impact actions are essential when an agent can mutate real application state.

What's next for AyMateo Tickets

The next step would be expanding the agent-native experience beyond a single-event demo.

Future work could include richer event discovery, multiple performances, accessibility preferences, price and seating recommendations, and agent-assisted seat selection on the visual seating map.

We would also like to explore standardized confirmation flows for actions with higher impact while preserving the principle demonstrated here:

AI agents can do the repetitive searching, comparing, and preparation, while humans remain in control of the final decision.

Built With

• caddy
• docker
• github
• graphile
• next.js
• node.js
• pnpm
• postgresql
• prisma
• react
• typescript
• webmcp
• worker