Spécification de conversion pour la réservation de restaurants

Objectif

Notre objectif est de permettre à ChatGPT d’invoquer directement les plugins de partenaires pour des cas d’usage où l’intention de passer à l’action est forte, comme la réservation d’un restaurant.

Une fois que les partenaires nous fournissent un flux de données pour la recherche, nous pouvons connecter leurs serveurs MCP pour effectuer des actions de conversion en fin de parcours. Pour cela, les plugins des partenaires doivent respecter un contrat standardisé portant sur le nom du widget, le nom de l’outil et les données d’entrée de l’outil.

Si vous souhaitez créer un plugin conforme à cette spécification, demandez un accès via le formulaire ChatGPT pour les commerçants.

Expérience utilisateur

Lorsque les utilisateurs recherchent des restaurants à proximité, la fiche du restaurant et la barre latérale proposent un bouton Réserver qui peut ouvrir l’interface du prestataire de réservation du restaurant.

Bouton Réserver dans l’interface du restaurant :

Fenêtre modale de réservation ouverte depuis ce bouton :

Contrat requis à ce jour

Pour l’intégration actuelle des réservations, seuls les éléments suivants sont requis :

• Nom du widget : ui://widget/restaurant-reservation.html
• Nom de l’outil : restaurant_reservation

restaurant_reservation doit définir :

_meta.ui.resourceUri = "ui://widget/restaurant-reservation.html";

Tout outil appelé directement depuis un widget doit définir :

_meta["openai/widgetAccessible"] = true;

Données d’entrée de restaurant_reservation

Données minimales (toujours envoyées) :

{
  "restaurant_id": "string"
}

Nous pouvons également envoyer les données ci-dessous. Vous pouvez les utiliser pour un rendu optimiste dans la fenêtre modale (par exemple, pour éviter d’afficher des squelettes de chargement ou des indicateurs de chargement pendant l’hydratation des données) :

{
  "restaurant_name": "string",
  "restaurant_image": "string",
  "restaurant_address": {
    "address": "string",
    "city": "string",
    "state": "string",
    "zipcode": "string",
    "country": "string"
  }
}

Flux requis (intégration de la recherche)

Pour permettre le routage depuis le bouton Réserver, nous ingérons un flux de données sur les établissements fourni par les partenaires.

Objectif et périmètre

Ce contrat de flux définit :

• Les données minimales sur les établissements nécessaires à la mise en correspondance et au classement.
• Une API de liste paginée.
• La détection des modifications pour éviter les récupérations complètes inutiles.

Enregistrement d’un établissement (champs minimaux requis)

Un objet Business doit inclure :

• id (string) : stable et unique au sein du fournisseur.
• name (string)
• address (object ou string formatée)
• location (object avec latitude/longitude)
• phone_number (string, de préférence au format E.164)
• website_url (string, URL)
• platform_url (string, URL de votre fiche canonique)

Structure minimale recommandée :

{
  "id": "biz_123",
  "name": "Acme Coffee",
  "address": {
    "line1": "123 Market St",
    "line2": "Suite 5",
    "locality": "San Francisco",
    "region": "CA",
    "postal_code": "94105",
    "country": "US",
    "formatted": "123 Market St, Suite 5, San Francisco, CA 94105, US"
  },
  "location": {
    "latitude": 37.793,
    "longitude": -122.396
  },
  "phone_number": "+14155551234",
  "website_url": "https://acmecoffee.example",
  "platform_url": "https://provider.example/biz/biz_123"
}

Si les composants structurés de l’adresse ne sont pas disponibles, address peut être une seule chaîne formatée, mais son format doit être cohérent et lisible par un humain.

Point de terminaison de liste paginée

Exemple de point de terminaison :

• GET /v1/businesses

Paramètres de requête :

• Pagination : utilisez une seule méthode
• page + page_size
• offset + limit
• ou next_page_token (token opaque ; à privilégier si cette méthode est prise en charge)
• changes_token (string, facultatif) : indique si les données ont changé depuis le dernier point de contrôle de synchronisation.

La réponse doit inclure :

• checksum (boolean) : indique si des modifications ont eu lieu depuis le point représenté par changes_token fourni (ou true si aucun n’a été fourni).
• businesses (Business[]) : données de la page actuelle.
• Métadonnées de pagination pour la méthode choisie :
• page, page_size, total_pages (facultatif), ou
• offset, limit, total (facultatif), ou
• next_page_token (string | null)

Exemple de requête et de réponse

Requête :

GET /v1/businesses?page=1&page_size=2&changes_token=sync_2026_03_10

Réponse :

{
  "checksum": true,
  "page": 1,
  "page_size": 2,
  "total_pages": 120,
  "businesses": [
    {
      "id": "biz_123",
      "name": "Acme Coffee",
      "address": {
        "line1": "123 Market St",
        "locality": "San Francisco",
        "region": "CA",
        "postal_code": "94105",
        "country": "US",
        "formatted": "123 Market St, San Francisco, CA 94105, US"
      },
      "location": {
        "latitude": 37.793,
        "longitude": -122.396
      },
      "phone_number": "+14155551234",
      "website_url": "https://acmecoffee.example",
      "platform_url": "https://provider.example/biz/biz_123"
    },
    {
      "id": "biz_124",
      "name": "Golden Diner",
      "address": "200 Howard St, San Francisco, CA 94105, US",
      "location": {
        "latitude": 37.789,
        "longitude": -122.391
      },
      "phone_number": "+14155559876",
      "website_url": "https://goldendiner.example",
      "platform_url": "https://provider.example/biz/biz_124"
    }
  ]
}

Comment nous utilisons ce flux pour la recherche

Nous utilisons le flux de données sur les établissements comme un index de recherche. Lors d’une requête, nous récupérons les candidats par correspondance approximative (nom + localisation/adresse), puis nous les classons et supprimons les doublons en fonction de la similarité des noms et des adresses. La localisation, le numéro de téléphone et l’URL servent de signaux supplémentaires.

Extension utile (non requise à ce jour)

Pour permettre de finaliser l’ensemble du parcours dans la discussion, nous recommandons d’ajouter :

• refresh_availability
• make_reservation
• reservation_confirmation