Come SkiTable è diventata la prima piattaforma agentica di skipass

La maggior parte dei sistemi di prenotazione sciistica è stata costruita per persone che cliccano su un sito web. Riteniamo che la prossima ondata di prenotazioni arriverà da agenti IA che agiscono per conto di uno sciatore, perciò abbiamo ricostruito SkiTable per essere richiamata dal software con la stessa facilità con cui viene consultata da una persona.

Questo articolo descrive cosa abbiamo realizzato e perché abbiamo fatto queste scelte.

La scommessa

Tra la fine del 2025 e l'inizio del 2026 il Model Context Protocol è passato dall'anteprima alla versione stabile presso i principali fornitori di modelli, e gli assistenti di largo consumo hanno cominciato a ricorrere a strumenti invece di rispondere dai dati di addestramento. Una località che un assistente non può richiamare è una località che esce dall'elenco dei consigli.

Gli operatori affermati della prenotazione sciistica non hanno alcuna superficie per agenti. È questa l'apertura, e resta aperta solo finché non reagiscono. Perciò ci siamo mossi.

Cosa abbiamo realizzato

Un agente può ora fare tutto ciò che può fare un acquirente umano competente, in uno o due scambi:

• Un server MCP con nove strumenti, che coprono la ricerca di località (testo libero e per caratteristiche), la scoperta delle regioni, i prezzi in tempo reale, il confronto tra località, la pianificazione di viaggi di gruppo, la prenotazione e lo stato degli ordini.
• Tre endpoint REST pensati per gli agenti: search trasforma una richiesta in linguaggio naturale in località ordinate, plan costruisce itinerari candidati per un gruppo e un intervallo di date, e quote restituisce un prezzo fermo a tempo limitato.
• Una interfaccia a riga di comando (pipx install skitable) per sviluppatori e agenti che preferiscono richiamare un programma invece di parlare HTTP.
• File di scoperta perché un agente trovi tutto questo in un solo salto: /llms.txt, /.well-known/agent.json e /.well-known/mcp.json, oltre a dati di prodotto e di prezzo strutturati su ogni pagina di località.

Tutto è indipendente dal fornitore. MCP è il punto di ingresso, ma la superficie REST funziona per qualsiasi agente che parli HTTP, qualunque sia il modello dietro.

Decisioni da evidenziare

Chiavi per agente, non una password condivisa. Ogni agente riceve la propria chiave con la propria quota. Questo ci permette di offrire un piano davvero gratuito (mille richieste e cinquanta località distinte al giorno, attribuzione richiesta, uso non commerciale) mantenendo al contempo la responsabilità per agente. Una chiave che si comporta male può essere limitata o revocata senza toccare gli altri.

I pagamenti vanno ancora direttamente alla località. Una prenotazione avviata da un agente usa lo stesso modello di pagamento diretto di una vendita web. La località è sempre l'esercente ufficiale tramite Stripe Connect, e la piattaforma non trattiene mai fondi. Non avremmo rinunciato a questo per un nuovo canale. È ciò che conquista la fiducia delle località, e resta intatto.

Un preventivo fermo, perché il prezzo mostrato sia il prezzo prenotato. Quando un agente chiede un preventivo, riceve un token firmato che blocca il prezzo per qualche minuto. La cassa onora quel token invece di ricalcolare, così non c'è scarto tra "ecco il prezzo" ed "ecco la tua prenotazione". Il token è legato al prodotto e alla data esatti per cui è stato emesso, ed è monouso: un prezzo offerto non può quindi essere riportato a una data diversa né riutilizzato.

Comprensione delle richieste senza chiamata al modello per ogni richiesta. La ricerca in linguaggio naturale legge una richiesta come "località per famiglie in Tirolo sotto i sessanta euro" con un analizzatore deterministico, non con una chiamata al modello in tempo reale. È più veloce, non costa nulla per richiesta e non inventa mai un filtro che lo sciatore non ha chiesto. Una fase di comprensione basata su modello è un'aggiunta pulita per più avanti, posta davanti alla stessa ricerca strutturata.

Anti-abuso senza escludere gli agenti veri

Il rischio, aprendo una superficie di dati, è che qualcuno provi a risucchiare l'intero catalogo. La nostra difesa è discreta e specifica: un tetto per chiave sul numero di località distinte viste al giorno. Le consultazioni ripetute della stessa località sono gratuite, così il comportamento normale di un agente non è mai colpito, ma estrarre l'intero catalogo richiederebbe a una chiave gratuita ben più di un mese anche a efficienza perfetta. Il tetto è applicato in modo atomico, quindi regge sotto traffico concorrente.

Le chiavi gratuite portano un obbligo di attribuzione: un agente che presenta una località a uno sciatore mostra un link "via SkiTable". I piani a pagamento, per volumi maggiori e uso commerciale, arriveranno poi.

Tre modi per acquistare

Il risultato è che uno sciatore può acquistare uno skipass su SkiTable in tre modi: sul web, tramite un negozio integrabile sul sito di una località, o tramite un agente IA. La via degli agenti è quella nuova, e per quanto ne sappiamo SkiTable è la prima piattaforma di skipass a offrirla come canale di primo piano e non come ripensamento.

Cosa viene dopo

La fase 1 amplia l'insieme di strumenti MCP, aggiunge prompt riutilizzabili, rilascia piani a pagamento con attribuzione delle prenotazioni per chiave affinché le località vedano esattamente quanto rende il traffico degli agenti, e porta la stessa superficie per agenti a una parte più ampia del catalogo. Le fondamenta ci sono. Ora scopriamo quali agenti ci scelgono.

Se stai costruendo un agente di viaggio e vuoi provarlo, la chiave gratuita e la documentazione sono collegate dalla pagina "Per gli agenti".