MCP Tools Reference

Liste exhaustive des 425 outils MCP que Trackily publie, répartis en 26 modules. Pour chacun : son nom, les scopes qu'il exige, son tier, et la première phrase de la description que l'agent reçoit. Le serveur publie aussi 22 resources (resources/list, URIs trackily://…) et 13 prompts (prompts/list), qui ne figurent pas dans ces tableaux.

Légende des colonnes :

• Outil — le nom à passer dans tools/call, champ params.name.
• Scopes — tous requis sur le jeton (cf. Scopes). tools/list ne montre à un jeton que les outils dont il possède tous les scopes : un outil absent de sa liste est un scope manquant, pas un outil manquant.
• Tier — T1 : exécuté dès le premier appel. T2 (99 outils) : le schéma accepte confirm_token ; le premier appel ne fait qu'un aperçu et rend un jeton, le second — mêmes arguments plus confirm_token — exécute. Le jeton sert une fois et expire après 5 minutes (cf. Tier System). Quelques outils ne passent par l'aperçu que pour une partie de leurs actions (compliance_check en mode ai, les bulk_* pour delete, verify_whatsapp_account pour un compte 360dialog, les modèles locaux et les étapes de séquence WhatsApp pour outrepasser un refus contenu_promotionnel) : leur description le dit.
• Description — la première phrase du texte que l'agent lit dans tools/list (les deux premières quand la première tient en moins de 25 caractères), recopiée telle quelle : en anglais pour la plupart des modules, en français pour WhatsApp. Le schéma complet des arguments se lit dans tools/list.

Table des matières

• autopilot-resources — 12 outils : lectures paramétrées du tracker (stats, campagnes, offres, landings, flows, clics, conversions, leads, Automizer)
• autopilot-actions — 17 outils : écritures de base du tracker (campagnes, flows, offres d'affiliation, landings, règles Automizer)
• autopilot-source-actions — 6 outils : pause, budget et enchère directement chez les régies
• autopilot-meta-tools — 9 outils : brief, anomalies, optimisations, santé du tracking, parcours, attribution
• autopilot-content-tools — 15 outils : landings (génération IA, HTML, import, retouche, traduction, conformité)
• autopilot-workflow-tools — 8 outils : workflows de cloaking, en DSL nodes + edges
• autopilot-ecommerce-tools — 10 outils : boutiques externes connectées (Shopify…) et leur catalogue
• autopilot-ecommerce-orders-tools — 14 outils : commandes Shopify, paniers abandonnés, variantes
• autopilot-ecommerce-analytics-tools — 13 outils : KPI Shopify, clients, stocks
• autopilot-ecommerce-marketing-tools — 17 outils : collections, codes promo, script tags, webhooks Shopify
• autopilot-ecommerce-content-tools — 15 outils : pages, blogs, articles, metafields, SEO Shopify
• autopilot-ecommerce-orchestration-tools — 8 outils : briefings Shopify et opérations en masse
• autopilot-native-commerce-tools — 15 outils : produits de la boutique native et zones de livraison
• autopilot-native-orders-tools — 8 outils : commandes et clients de la boutique native
• autopilot-email-tools — 91 outils : e-mail marketing (listes, séquences, SMTP, suppression, déclencheurs)
• autopilot-whatsapp-tools — 47 outils : WhatsApp Marketing (comptes, modèles, listes, séquences, journal, suppression, réglages, voie « web », rotation des SIM)
• autopilot-dm-tools — 18 outils : messages Instagram & Messenger (applications et Pages, contacts, conversations en lecture ; automatisations, simulation, statistiques, publications récentes ; boîte de réception et réponse manuelle)
• autopilot-smartlinks-tools — 9 outils : smartlinks /s/:slug et leur pool d'offres
• autopilot-platform-tools — 12 outils : domaines de tracking, types de conversion, règles de notification
• autopilot-payment-tools — 5 outils : comptes de paiement, lus et activés, jamais leurs clés
• autopilot-truth-tools — 3 outils : Product Truth, la fiche vérifiée d'un produit
• autopilot-theme-tools — 7 outils : thèmes des boutiques natives
• autopilot-funnel-tools — 25 outils : funnels (composition, publication, statistiques, journal)
• autopilot-merchandising-tools — 4 outils : prix barré, marque, options et prix par variante des produits natifs
• autopilot-store-tools — 21 outils : boutiques natives, domaines, duplication par marché, export et import
• autopilot-offer-tools — 16 outils : offres commerce (« Offers-EC »), bundles, moyens de paiement

resources

Les lectures du tracker qui prennent des paramètres (fenêtre de dates, identifiants, limites). Le même module publie aussi des resources trackily://… : des instantanés JSON sans argument (tableau de bord, stats sur 30 jours, campagnes, offres, landings, sources, règles Automizer…). list_automizer_rules est l'équivalent outil de la resource trackily://automizer/rules.

actions

Les écritures de base du tracker : campagnes et flows, offres d'affiliation, landings, règles Automizer. « Offre » veut dire ici l'offre d'un réseau d'affiliation — un payout. Les offres vendues dans la boutique native sont un autre objet, dans offer-tools.

source-actions

Ces outils agissent directement chez la régie (Kadam, Meta, TikTok, Taboola, MGID, ExoClick, PropellerAds) : ils demandent le source_id Trackily et l'identifiant de la campagne côté régie. list_source_campaigns et test_source_connection servent à vérifier la source avant d'agir. Le budget se donne toujours en USD — l'outil convertit dans l'unité de la régie — et respecte le plafond daily_spend_cap_usd du jeton. L'enchère ne se modifie pas au niveau campagne sur Meta, TikTok et MGID.

meta-tools

Synthèse et diagnostic : brief du jour, anomalies, fatigue des landings, optimisations, plan de scale, santé du tracking, parcours d'un visiteur, attribution multi-touch. Tous lisent sans rien écrire, sauf rotate_offer_in_flows, qui réécrit les flows. cross_platform_scale_plan ne fait que proposer : les appels qu'il liste (duplicate_campaign, update_source_campaign_budget) restent à lancer.

content-tools

Les landings : les générer avec l'AI Landing Builder, les créer depuis du HTML, les importer depuis une URL, les retoucher par fragments, les traduire, les brancher sur une campagne, auditer leur conformité. Deux traductions coexistent : translate_landing rejoue le modèle de copy de l'IA et ne vaut que pour une landing générée ; translate_landing_html traduit le HTML de n'importe quelle page locale (type local : écrite à la main, importée ou générée) vers une nouvelle landing ; une page de type url n'a pas de HTML à traduire.

workflow-tools

Les workflows de cloaking du Visual Workflow Builder. L'agent les manipule en DSL (nodes + edges), sans toucher à la mise en page Drawflow. Tous exigent un scope settings:* : le preset operator les lit mais ne les écrit pas.

Cf. Cloaking — Workflows.

ecommerce-tools

Les boutiques e-commerce EXTERNES connectées à Trackily (Shopify, WooCommerce…) et leur catalogue recopié localement. À ne pas confondre avec les boutiques hébergées par Trackily (store-tools) et leurs produits (native-commerce-tools). test_store_connection ne sait vérifier qu'une boutique Shopify.

ecommerce-orders-tools

Les commandes Shopify, les paniers abandonnés et les variantes des produits Shopify. Les commandes de la boutique native sont dans native-orders-tools.

ecommerce-analytics-tools

Les KPI d'une boutique Shopify, ses clients et ses stocks. Les clients de la boutique native se lisent avec list_native_customers.

ecommerce-marketing-tools

Collections, codes promo, script tags et webhooks d'une boutique Shopify.

ecommerce-content-tools

Pages, blogs et articles Shopify, metafields des produits, et deux outils d'IA sur les fiches produit (description, traduction). seo_audit_product n'appelle aucun LLM : ce sont des règles.

ecommerce-orchestration-tools

Les briefings Shopify (jour, semaine), les alertes de stock et de produits sans vente, l'audit du catalogue, et deux opérations en masse.

native-commerce-tools

Les produits hébergés par Trackily — pas Shopify — et les zones de livraison. Physique ou numérique se décide par produit, ce qui permet à un même bundle de mêler un colis et un bonus numérique. Le prix vit sur les variantes : create_native_product le pose sur celle qu'il crée (price), set_variant_pricing (merchandising-tools) le règle variante par variante. Écrire une zone de livraison exige settings:write, absent du preset operator.

Cf. Commerce.

native-orders-tools

Les commandes et les clients de la boutique native. À lire avant de citer un chiffre d'affaires : un funnel écrit une commande par étape vendue, et list_native_orders les replie — une ligne par achat, la vente principale seule. Son total ne vaut donc que la première étape ; ce que l'acheteur a réellement payé est total_parcours, et parcours_etapes dit combien de commandes l'achat couvre. include_upsells: true rend la vue à plat.

Exemple list_native_orders :

// Requête
{
  "name": "list_native_orders",
  "arguments": { "limit": 10, "payment_status": "paid" }
}

// Réponse (extrait : chaque commande porte aussi sous-total, frais de port, taxes,
// remise, moyen de paiement, boutique, landing et campagne)
{
  "status": "ok",
  "tool": "list_native_orders",
  "total": 1,
  "count": 1,
  "orders": [
    {
      "id": 12,
      "order_number": "TR-000012",
      "created_at": "2026-05-18T14:22:11.421Z",
      "customer_email": "client@example.com",
      "currency": "EUR",
      "total": 49,
      "payment_status": "paid",
      "fulfillment_status": "fulfilled",
      "funnel_id": null,
      "parcours_etapes": 1,
      "total_parcours": 49
    }
  ]
}

email-tools

L'e-mail marketing : listes, séquences, relais SMTP, abonnés, suppression globale, déclencheurs postback → e-mail. Ajouter un relais SMTP exige aussi settings:write. Cf. la section Email pour les concepts. Le contenu dynamique (v148) passe par blocs_dynamiques sur create_email_broadcast, update_email_broadcast, add_email_sequence_step et update_email_sequence_step ; list_email_dynamic_content_fields donne les conditions permises, preview_email_for_contact rend l'e-mail tel qu'un contact le recevrait. Le constructeur visuel des parcours : get_email_sequence_graph rend le diagramme d'une séquence (rangs par délai, branches « si / sinon » reconnues, taux en texte, alertes) ; create_email_sequence_branch crée deux étapes brouillons inactives aux conditions contraires — seuls les opérateurs de get_email_branch_opposites le permettent — qu'on écrit puis active ensuite par update_email_sequence_step.

Exemple enroll_email_subscriber :

// Requête
{
  "name": "enroll_email_subscriber",
  "arguments": {
    "list_id": 7,
    "email": "client@example.com",
    "name": "Marie Dupont",
    "custom_fields": { "city": "Paris" },
    "source": "manual:admin"
  }
}

// Réponse (extrait : `subscriber` est la ligne complète de l'abonné)
{
  "ok": true,
  "subscriber": {
    "id": 421,
    "list_id": 7,
    "email": "client@example.com",
    "name": "Marie Dupont",
    "status": "subscribed",
    "custom_fields": { "city": "Paris" },
    "source": "manual:admin"
  },
  "queued_steps": 3
}

Les autres issues : awaiting_confirmation: true quand la liste est en double opt-in et que skip_double_optin n'est pas true (l'e-mail de confirmation part, aucune étape n'est programmée) ; reason: "previously_opted_out" pour une adresse désinscrite, rebondie ou plaignante (rien n'est programmé) ; skipped: true avec reason = suppressed, list_inactive, disposable ou no_mx quand l'adresse n'est pas inscrite du tout. Une erreur revient sous la forme { "error": "…" }.

whatsapp-tools

Le module WhatsApp Marketing vu par l'agent, sous sa propre paire de scopes whatsapp:read / whatsapp:write : un jeton taillé pour l'e-mail n'y a pas accès. Deux outils exigent un scope de plus, parce qu'ils modifient autre chose qu'un objet WhatsApp : bind_landing_to_whatsapp_list (landings:write) et bind_campaign_to_whatsapp_list (campaigns:write), les jumeaux de bind_landing_to_email_list. Sur un compte de l'API officielle, chaque message est facturé par le fournisseur et engage la note de qualité du numéro ; sur la voie « web », rien n'est facturé, mais chaque envoi engage la SIM elle-même, et un numéro banni est perdu. Les descriptions de send_test_whatsapp et de simulate_whatsapp_routing font cette distinction. Un jeton créé avant l'arrivée de ces scopes ne voit aucun de ces outils — cf. Scopes.

Ce que l'agent ne peut pas faire, délibérément :

• Créer ou modifier un compte WhatsApp. Les identifiants se saisissent dans l'admin ; aucun schéma d'entrée ne porte de champ de secret, et les comptes se lisent jetons masqués.
• Démarrer ou couper l'appairage d'une SIM (voie « web », par WhatsApp Web). get_whatsapp_pairing_state constate l'état ; le QR ne sort jamais dans une réponse.
• Rattacher une SIM à un groupe. Le groupe se crée ici, le rattachement se fait à l'écran.
• Poser un blocage à la place du client. add_to_whatsapp_suppression n'accepte que manual et invalid_number. Un STOP (stop_keyword) ou une désinscription remontée par le fournisseur (opt_out) ne se retire pas d'ici.

Chaque outil vérifie la licence à l'appel : si elle n'inclut pas la fonctionnalité whatsapp_marketing, il répond par un refus lisible qui dit comment l'obtenir, sans rien lire ni écrire.

Quatre familles à connaître :

• Modèles locaux (*_whatsapp_local_template) : seulement sur un compte du fournisseur web, qui n'a pas de catalogue chez un fournisseur. Les variables {{1}}, {{2}}… se dérivent du texte, sans trou. La catégorie (MARKETING ou UTILITY) décide qui reçoit le message : elle doit dire la vérité sur le contenu. Un texte UTILITY qui ressemble à une promotion (remise chiffrée, code promo, soldes…) est refusé (contenu_promotionnel), comme les valeurs fixes promotionnelles d'une étape de séquence ; utility_confirme: true l'outrepasse par un jeton de confirmation, et l'agent ne le fait qu'avec l'accord de l'opérateur, qui a vu les passages en cause.
• Séquences et commandes annulées : create_whatsapp_sequence accepte cible_commande (active par défaut, ou annulee pour relancer un client qui a annulé : délais comptés depuis l'annulation, une fois par client, jamais tant qu'une autre de ses commandes tient dans la liste — un doublon annulé ne relance pas). La cible ne se change plus ensuite, et une séquence annulee ne peut pas être la séquence par défaut d'une liste. list_whatsapp_subscribers filtre par statut_commande, avec la même règle : une commande annulée dont une autre commande du même client tient dans la liste (doublon, rachat en cours dans un funnel à upsells) se lit active.
• Rotation des SIM : chaque groupe porte une vocation (transactionnel, marketing, mixte) ; les règles de routage s'évaluent dans l'ordre, et la première qui correspond désigne le groupe — sauf si ce groupe n'a pas la vocation de l'envoi, est en pause ou archivé : la règle est alors ignorée (l'écart est journalisé) et la suivante est essayée. simulate_whatsapp_routing dit quelle SIM partirait et pourquoi les autres sont écartées, sans rien envoyer ni écrire.
• Numéros : les recherches par numéro de list_whatsapp_sends, list_whatsapp_suppression et list_whatsapp_subscribers couvrent toutes les formes équivalentes d'un même numéro. Pour les deux premières, un numéro écrit en national (sans indicatif) exige pays (ISO-2) : sans lui, une liste vide ne prouve rien.

dm-tools

Les messages automatiques Instagram & Messenger (docs/dm/CONCEPTION.md). Phase 1 : l'agent LIT les applications Meta de l'opérateur et leurs Pages (état, verdict par fonction, abonnement, dernière notification reçue, alerte), les réglages du module, les contacts et leur conversation. Aucun outil ne crée ni ne modifie une application ou une Page : la clé secrète de l'app et le jeton de Page transiteraient par la conversation (§6.1). Phase 2 (§8.8) : un outil par route des automatisations — les lire, les créer, les modifier, les supprimer (dm:write), les simuler sans rien écrire (test_dm_automation), lire leurs statistiques et leur attribution, et lister les publications récentes d'un compte pour viser un commentaire. La validation est celle de l'écran : un refus nomme son champ et son etape_id. Phase 3 (§10.3), la boîte de réception : list_dm_inbox lit les conversations (non lus, fenêtre de 24 h, pause des automatisations — lire ne marque rien comme lu) et reply_dm_contact (dm:write) répond à la main à UN contact, tout de suite, par le même chemin que l'écran : seulement dans la fenêtre de 24 h qui suit son dernier message, texte seul jamais coupé, refus nommés avant tout envoi (hors_fenetre, texte_trop_long, texte_vide, contact_injoignable, compte_indisponible), pause des automatisations de ce contact, réponse journalisée au nom de l'agent. C'est le seul outil qui envoie un message, et seulement à quelqu'un qui vient d'écrire : aucun ne diffuse (§3). Phase 3 bis (§11.3), les réponses enregistrées : list_dm_saved_replies, create_dm_saved_reply, update_dm_saved_reply, delete_dm_saved_reply (validation stricte : variables connues seulement, raccourci unique, 200 au plus) et get_dm_saved_replies_for_contact, qui les rend pour un contact (variables remplies, depasse selon la limite de son canal). Aucune ne part seule : l'agent envoie le texte rendu par reply_dm_contact avec reponse_type_id, qui compte l'usage à l'issue envoye. Conditions et branches (§12) : les mêmes outils d'automatisation prennent les étapes attente (la réponse du contact devient {{reponse}}) et condition (règles sur l'e-mail, le téléphone, le canal, la réponse, le clic, une liste ou une étiquette e-mail, l'horaire, la fenêtre), les renvois suivante / alors / sinon / si_silence / « fin » ; une boucle qui n'attend jamais le contact est refusée (boucle_sans_attente), test_dm_automation prend un contexte et get_dm_automation_stats rend les passages par étape. Scopes propres dm:read / dm:write ; chaque outil exige la licence dm_automation et le dit en refus lisible (licence_absente) sinon.

smartlinks-tools

Les smartlinks : des URL publiques /s/:slug qui envoient chaque visiteur vers une paire (offre, landing facultative) de leur pool, choisie selon la stratégie du smartlink (routing_strategy) : epc_ranked par défaut, qui favorise l'EPC observé en gardant une part d'exploration ; sinon waterfall, weighted, round_robin ou predictive. Un smartlink naît avec un pool vide : tant qu'aucune paire n'est ajoutée (add_offer_to_smartlink), et chaque fois qu'aucune ne convient au visiteur, il envoie vers son repli — fallback_offer_id, sinon fallback_url — et répond 404 s'il n'en a aucun. En pause, /s/:slug répond 404.

platform-tools

Trois réglages de la plateforme que l'admin a toujours eus : les domaines de tracking, les types de conversion, les règles de notification. Créer et modifier s'exécutent directement, supprimer passe par l'aperçu. Toutes les écritures exigent settings:write, absent du preset operator.

payment-tools

Ce que l'agent sait des comptes de paiement : leur existence et leur état, jamais leurs clés. Il peut activer, désactiver ou choisir le compte par défaut ; créer un compte ou changer une clé se fait dans l'écran Payment Methods de l'admin (accordéon E-Commerce) ou par l'OAuth Stripe — une clé ne transite pas par une conversation d'agent. Désactiver un compte rend impayables les offres qui en dépendaient, et un funnel live qui l'utilise refusera d'être publié. Pour un compte Ndeight (carte bancaire), l'agent peut aussi tester la connexion, lire l'état Ndeight d'une commande et la resynchroniser — jamais une clé ; un compte Ndeight ne rend pas une offre de funnel payable (Ndeight n'encaisse pas dans les funnels). Cf. CONCEPTION-NDEIGHT.

Cf. Commerce — comptes de paiement.

truth-tools

La Product Truth : la fiche vérifiée d'un produit, que remplit le client ou un LLM qui fait sa recherche à travers ce serveur MCP. Chaque fait porte un statut — verified (exige une source_url), customer_reported, inferred, unknown — et un fait verified sans source est refusé. save_product_truth remplace la fiche entière et incrémente sa version : relis-la avec get_product_truth avant de la renvoyer. generate_landing_for_offer et generate_landing_for_product la reprennent seuls ; generate_ai_landing la prend par product_truth_id.

theme-tools

Les thèmes des boutiques natives. Un thème est une DONNÉE, pas du HTML : l'agent remplit un schéma validé, donc son résultat est correct ou refusé. L'ordre de travail : get_theme_vocabulary (ce qu'un thème peut dire), preview_theme (voir avant d'écrire), create_theme ou update_theme, puis un nouvel aperçu. set_native_store_theme (store-tools) applique un thème à une boutique.

funnel-tools

Les funnels : une suite ordonnée d'étapes typées, reliées par des transitions. L'agent passe par le même chemin que l'admin — un funnel composé par un LLM n'a droit à aucune validation plus laxiste. L'ordre de travail : la resource trackily://funnels/vocabulary (ce qu'on peut écrire), get_funnel_pickers (les boutiques, pages et offres qui existent), create_funnel (l'en-tête, en brouillon), set_funnel_composition (étapes et transitions, remplacement entier), preview_funnel, puis publish_funnel, qui refuse en nommant chaque contrôle manqué. Le plus court chemin reste un modèle : list_funnel_templates, puis create_funnel_from_template.

merchandising-tools

Ce qui fait qu'une boutique ressemble à une boutique : le prix de référence derrière le prix barré et le badge -N %, les pastilles de couleur des options, la marque et les tags. Tout s'écrit par le module qui affiche la vitrine : une valeur qui produirait un badge absurde est refusée à l'écriture — un compare_at_price qui ne dépasse pas le prix de vente, par exemple. set_product_options régénère la matrice des variantes.

store-tools

Les boutiques hébergées par Trackily (« Storefronts » dans l'admin) : les créer, y pointer un ou plusieurs domaines, les dupliquer, les exporter vers une autre installation. Un nom qui dit native_store vise toujours une boutique native (list_native_stores, create_native_store, set_native_store_theme…), mais tous les outils de ce module ne le disent pas : les codes d'export (*_store_export_code*, import_store_from_code) et reset_demo_store portent eux aussi sur les boutiques natives. À l'inverse, list_stores, get_store_detail et test_store_connection visent les boutiques externes connectées (ecommerce-tools).

Trois règles à connaître : une boutique qui a vendu ne se supprime pas, elle s'archive ; la duplication par marché ne convertit jamais une devise — plan_market_duplication liste chaque prix à fixer avant de créer quoi que ce soit ; un code d'export TRKX1 emporte produits, offres, landings et funnels, jamais les comptes de paiement, les commandes, les clients ni les domaines.

offer-tools

Les offres COMMERCE : ce qui se vend dans la boutique native (« Offers-EC » dans l'admin). Rien à voir avec les offres d'affiliation (list_offers, update_offer_payout). Dans ce module, les noms disent native_offer, sauf diagnose_storefront_offers ; hors du module, plan_market_duplication (avec type: "offer") et duplicate_offer_for_market (store-tools) prennent eux aussi une offre commerce sans le dire dans leur nom. Une offre est l'unité vendue — sa composition, son prix, sa livraison. Un produit seul EST une offre : une offre automatique naît avec chaque produit, et list_native_offers la cache sauf include_auto. attach_native_offer_to_landing injecte la zone d'achat dans une page que tu écris toi-même : place <div id="trackily-checkout"></div> là où elle doit apparaître.

Total : 425 outils

Voir aussi

• Index — vue d'ensemble du système MCP
• Concept — le protocole JSON-RPC
• Tokens — créer le jeton
• Scopes — la granularité des permissions
• Tier System — aperçu + confirm_token