How SkiTable Became the First Agentic Ski Lift Pass Platform

29 May 2026 · Avtor SkiTable Team

engineering ai-agents mcp

Most ski booking systems were built for people clicking through a website. We think the next wave of bookings will come from AI agents acting on a skier's behalf, so we rebuilt SkiTable to be called by software as easily as it is browsed by a person.

This post covers what we shipped and why we made the choices we did.

The bet

Between late 2025 and early 2026, the Model Context Protocol went from preview to stable across the major model providers, and consumer assistants started reaching for tools instead of answering from training data. A resort that an assistant cannot call is a resort that falls off the recommendation list.

The incumbents in ski booking have no agent surface at all. That is the opening, and it stays open only until they react. So we moved.

What we shipped

An agent can now do everything a competent human shopper can do, in one or two round trips:

  • An MCP server with nine tools, covering resort search (free text and by features), region discovery, live pricing, cross-resort comparison, party trip planning, booking, and order status.
  • Three REST endpoints built for agents: search turns a plain-language request into ranked resorts, plan builds candidate itineraries for a party and a date window, and quote returns a firm, time-boxed price.
  • A CLI (pipx install skitable) for developers and agents that shell out rather than speak HTTP.
  • Discovery files so an agent finds all of this in one hop: /llms.txt, /.well-known/agent.json, and /.well-known/mcp.json, plus structured product and price data on every resort page.

Everything is provider-agnostic. MCP is the entry point, but the REST surface works for any agent that speaks HTTP, whatever model is behind it.

Decisions worth calling out

Per-agent keys, not a shared password. Every agent gets its own key with its own quota. That lets us give a genuinely free tier (a thousand requests and fifty distinct resorts a day, attribution required, non-commercial) while keeping per-agent accountability. A key that misbehaves can be capped or revoked without affecting anyone else.

Payments still go straight to the resort. An agent-driven booking uses the same pass-through model as a web sale. The resort is always the merchant of record via Stripe Connect, and the platform never holds funds. We were not going to trade that away for the sake of a new channel. It is the thing that earns resort trust, and it survives intact.

A firm quote, so the price an agent shows is the price it books. When an agent asks for a quote, it gets back a signed token that locks the price for a few minutes. Checkout honours that token instead of re-pricing, so there is no gap between "here is the price" and "here is your booking". The token is bound to the exact product and date it was quoted for, and it is single use, so a quoted price cannot be carried to a different date or replayed.

Query understanding without a per-request model call. The natural-language search reads a request like "family resort in Tirol under sixty euros" with a deterministic parser, not a live model call. It is faster, it costs nothing per request, and it never invents a filter the skier did not ask for. A model-based understanding pass is a clean addition later, sitting in front of the same structured search.

Anti-abuse without locking real agents out

The risk with opening a data surface is that someone tries to vacuum up the whole catalogue. Our defence is quiet and specific: a per-key cap on the number of distinct resorts seen per day. Repeat lookups of the same resort are free, so normal agent behaviour is never affected, but pulling the entire catalogue would take a free-tier key well over a month even at perfect efficiency. The cap is enforced atomically, so it holds under concurrent traffic.

Free-tier keys carry an attribution requirement: an agent surfacing a resort to a skier shows a "via SkiTable" link back. Paid tiers, for higher volume and commercial use, are next.

Three ways to buy

The result is that a skier can buy a lift pass on SkiTable three ways: on the web, through an embeddable shop on a resort's own site, or through an AI agent. The agent route is the new one, and as far as we know SkiTable is the first ski lift pass platform to offer it as a first-class channel rather than an afterthought.

What is next

Phase 1 grows the MCP tool set, adds reusable prompts, ships paid tiers with per-key booking attribution so resorts can see exactly what agent traffic brings in, and brings the same agent surface to more of the catalogue. The foundation is in place. Now we find out which agents pick us.

If you are building a travel agent and want to try it, the free key and the docs are linked from the "For Agents" page.