Des lectures et des limites contrôlées sur données fictives.

Contrôle du 1er octobre 2026 : client du SDK MCP relié en mémoire au serveur Galerie Auto, organisation fictive fixée par la connexion et permission vehicles:read. Le jeu comprend sept fiches. La première comporte deux liens photo fictifs, les suivantes aucun. Aucun accès réseau, téléchargement d’image ou appel CRM réel n’est nécessaire.

Cette méthode teste le contrat des outils. Elle ne teste ni OAuth en production ni l’interprétation d’une consigne par Muse. Ne copiez pas un identifiant de démonstration vers votre CRM : récupérez celui de votre propre recherche autorisée.

Outil : galauto_search_vehicles. Arguments exécutés :

{
  "limit": 5,
  "offset": 0
}

Sur le jeu fictif, le résultat contient cinq éléments dans items, has_more: true et next_offset: 5. Il s’agit de cinq fiches sur sept, pas de tout l’inventaire. Les filtres marque, modèle, prix maximal et statut peuvent ensuite affiner une recherche réelle ; cette fixture ne qualifie pas ces filtres.

Même outil, avec l’offset donné par le résultat précédent :

{
  "limit": 5,
  "offset": 5
}

La fixture retourne deux éléments, has_more: false et next_offset: null. Le parcours a donc consulté sept fiches. Dans votre connexion, utilisez la suite réellement retournée ; ne supposez pas qu’elle vaut toujours cinq. Une limite de pagination signalée demande d’affiner la recherche.

Appelez galauto_get_vehicle en donnant à vehicle_id l’identifiant de la première fiche retournée. Dans cette fixture, photo_count vaut 2 et les deux liens de photo_urls gardent l’ordre d’origine. La lecture d’une fiche de la seconde page retourne zéro lien.

Le contrôle compare aussi les liens de la recherche à ceux de la fiche détaillée. Il ne prétend pas ouvrir les URLs fictives ni afficher une image dans Muse. Pour un essai réel, comparez le numéro de stock avant de réutiliser le résultat.

Exemple original entièrement fictif, SIM-102, fichier rapport-pedagogique-SIM-102.txt, daté du 1er octobre 2026. Aucun fournisseur d’historique ni véhicule réel n’est représenté. Passage présent : « Le 12 septembre 2026, une vidange est consignée dans le relevé pédagogique. »

• Fait citable : Une vidange est consignée le 12 septembre 2026 dans ce relevé fictif. Citez le fichier et le passage ; aucune inspection réelle n’est démontrée.
• Absence utile : une recherche « collision » retourne zéro passage sur la fixture. L’historique complet et le kilométrage restent inconnus. Ce résultat ne prouve pas l’absence d’incident.
• Supervision : Faire vérifier la pièce source et les rubriques absentes par le responsable. Le prix zéro, le statut en attente et le kilométrage absent de la fiche ne changent pas.

Le SDK et la copie du serveur servi ont contrôlé ces lectures en mémoire avec un CRM simulé. Ce contrôle ne teste ni extraction OCR, ni lecture d’un rapport client, ni réponse Muse, ni envoi.

Dans une connexion qui fixe l’organisation, appelez galauto_vehicle_documents avec vehicle_id issu de la bonne fiche, puis document_id issu de la liste autorisée. Complétez ces arguments contrôlés avec ces deux identifiants :

{
  "text_offset": 0,
  "text_limit": 500
}

La fixture contient 1334 caractères ; le serveur retourne des blocs de 500 caractères au maximum. Reprenez next_text_offset dans text_offset jusqu’à null. La concaténation du test correspond exactement au texte fictif ; ce résultat ne certifie pas l’exhaustivité d’un OCR réel.

Pour une recherche dans tout le texte extrait du document choisi :

{
  "query": "collision"
}

La recherche retourne zéro passage pour ce terme, et une recherche « vidange » retrouve la citation ci-dessus. Le contrôle conserve history_certified: false, untrusted_text: true et les dates. Les cas simulés en attente et en échec restituent leur statut avec du texte vide. Les refus de ligne étrangère et d’argument invalide sont des contrôles du serveur sur CRM simulé ; ils ne prouvent pas un filtrage SQL réel.