MCP Autopilot

Trackily expose 181 tools MCP (Model Context Protocol) qui te permettent de piloter tout l'instance depuis Claude Desktop, Cursor, Zed, ChatGPT Desktop ou n'importe quel agent custom. Ce n'est pas une "intégration AI" superficielle — c'est l'API réelle du produit, exposée via un protocole standardisé que tous les clients LLM modernes savent parler.

Qu'est-ce que MCP ?

Model Context Protocol est un standard ouvert, publié par Anthropic, qui décrit comment un client LLM (Claude Desktop, Cursor…) découvre et appelle des "tools", "resources", et "prompts" exposés par un serveur tiers. C'est en quelque sorte le "USB-C des IAs" : un seul protocole, beaucoup d'apps des deux côtés.

Côté serveur, MCP est un wrapper JSON-RPC 2.0 sur HTTP (transport "streamable HTTP") ou stdio. Trackily implémente le transport HTTP, monté sur /mcp.

Côté client, le LLM se connecte au serveur, fait un handshake initialize, liste les tools/resources/prompts disponibles, et peut ensuite les appeler pendant une conversation. Le LLM n'a pas besoin de connaître l'API REST de Trackily — il lit les description + inputSchema de chaque tool et appelle ce qui semble pertinent.

Spec : https://modelcontextprotocol.io/specification.

Pourquoi 181 tools

Trackily, c'est une application dense : campaigns, offers, landings, flows, sources, automizer, native commerce, e-commerce externe (Shopify), email marketing, cloaking, AI landings, analytics, settings… Chaque domaine a typiquement 5-15 tools (list / get / create / update / delete + opérations spécialisées).

Le découpage est volontairement fin plutôt que générique : au lieu d'un seul tool trackily_call(method, params), on a list_campaigns, pause_campaign, duplicate_campaign, update_campaign_cost. Cela permet au LLM de proposer des actions précises sans avoir à composer manuellement des payloads compliqués, et permet le scoping fin (cf. Scopes).

Distribution des 181 tools par module :

Total : 181 tools. Tous référencés dans la tools reference.

Qui utilise ça ?

La règle : le jeton dans env, jamais dans args

Tout ce qu'un client MCP met dans args devient un argument de processus : ps, le moniteur d'activité, un outil de supervision, les journaux du client (Claude Desktop garde dans ~/Library/Logs/Claude/ ce que le pont écrit au démarrage — les en-têtes en clair avec d'anciens mcp-remote) et parfois l'historique du shell le lisent en clair. Le jeton Trackily va donc dans le bloc env ; args ne porte que la référence Authorization:${AUTH_HEADER}, que le pont mcp-remote remplace lui-même par la variable au démarrage.

Tu n'as rien à écrire à la main : Autopilot → Tokens → New token (ou Rotate) affiche la configuration complète, jeton déjà placé dans env, avec un bouton Copy. L'onglet Docs montre la même chose avec <YOUR_TOKEN> à remplacer.

Avant (jusqu'au 2026-09-25) : l'écran faisait copier une commande npx … setup --token <jeton> d'un paquet qui n'a jamais été publié (la commande échouait), et cette doc montrait le jeton dans args ou dans l'URL. Si ta configuration actuelle a le jeton dans args ou dans l'URL (?token=, encore accepté mais déconseillé), refais-la depuis l'écran, puis fais tourner le jeton (Rotate) : l'ancien a pu être lu par tout ce qui voit la liste des processus ou les journaux.

Claude Desktop, Cursor, Windsurf

Fichier de configuration du client (Claude Desktop : ~/Library/Application Support/Claude/claude_desktop_config.json ; Cursor : ~/.cursor/mcp.json ; Windsurf : ~/.codeium/windsurf/mcp_config.json). Le bloc ci-dessous est un fichier complet : fichier vide, colle-le tel quel ; sinon, ajoute seulement l'entrée "trackily" dans ton mcpServers existant (jamais le bloc entier sous mcpServers, qui donnerait mcpServers.mcpServers) :

{
  "mcpServers": {
    "trackily": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://trackily.online/mcp", "--header", "Authorization:${AUTH_HEADER}"],
      "env": {
        "AUTH_HEADER": "Bearer tly_ap_<your_token>"
      }
    }
  }
}

Trois détails qui comptent :

• Authorization:${AUTH_HEADER} s'écrit sans espace après les deux-points (Cursor et Claude Desktop sous Windows coupent les arguments aux espaces) ; l'espace est dans la valeur, entre Bearer et le jeton.
• AUTH_HEADER vaut Bearer suivi du jeton : le mot Bearer fait partie de la valeur.
• La version de mcp-remote n'est pas figée (npx -y mcp-remote prend la dernière) : elle garde ainsi ses correctifs de sécurité.

Garde ce fichier pour toi (chmod 600 sur macOS/Linux) : le jeton y est en clair, c'est le seul endroit où il doit l'être.

Tu relances le client. Tu peux désormais demander : "Mes 5 meilleures campagnes ce mois ? Pause celles dont le ROI est négatif." Claude découvre get_stats, list_source_campaigns, suggest_optimizations, pause_campaign — il les enchaîne, te montre l'output, te demande validation avant les Tier-2 (les pauses). Dans Cursor, tu peux taper @trackily list my landings dans l'éditeur.

Zed

Même pont, même env, dans ~/.config/zed/settings.json. Ce fichier n'est jamais vide : ajoute seulement l'entrée "trackily" dans son context_servers (crée la clé si elle manque) :

{
  "context_servers": {
    "trackily": {
      "source": "custom",
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://trackily.online/mcp", "--header", "Authorization:${AUTH_HEADER}"],
      "env": {
        "AUTH_HEADER": "Bearer tly_ap_<your_token>"
      }
    }
  }
}

Si le client répond 401

Le message du serveur dit ce qui manque :

• « Authorization header carries an unexpanded placeholder » — mcp-remote a envoyé le texte ${AUTH_HEADER} tel quel : la variable nommée dans args n'existe pas dans env (faute de frappe, bloc env oublié), ou un vieux mcp-remote resté en cache ne sait pas la remplacer. Corrige env, relance le client.
• « Authorization header is not of the form "Bearer " » — AUTH_HEADER contient le jeton seul : ajoute Bearer devant.
• « Missing bearer token » — aucun en-tête n'est arrivé : vérifie que --header et Authorization:${AUTH_HEADER} sont bien deux éléments de args.

ChatGPT Desktop

ChatGPT Desktop supporte MCP via le mode "Connectors". Branche l'URL /mcp et mets le jeton dans le champ d'en-tête d'authentification prévu par l'application — jamais dans l'URL.

Agents custom (Python, TypeScript, etc.)

N'importe quel agent qui parle JSON-RPC peut consommer Trackily. SDKs officiels :

• Python : pip install mcp (https://github.com/modelcontextprotocol/python-sdk)
• TypeScript : npm install @modelcontextprotocol/sdk (https://github.com/modelcontextprotocol/typescript-sdk)

Exemple Python minimal — le jeton vient de l'environnement (TRACKILY_TOKEN), ni du code ni de la ligne de commande :

import os
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

async with streamablehttp_client(
    "https://trackily.online/mcp",
    headers={"Authorization": "Bearer " + os.environ["TRACKILY_TOKEN"]}
) as (read, write, _):
    async with ClientSession(read, write) as session:
        await session.initialize()
        tools = await session.list_tools()
        result = await session.call_tool(
            "list_campaigns",
            {"limit": 10, "is_active": True}
        )
        print(result)

Architecture interne

                ┌────────────────────────────────────────────────┐
                │                  CLAUDE / CURSOR                │
                │                (MCP client, JSON-RPC)           │
                └────────────────┬───────────────────────────────┘
                                 │
                                 ▼  HTTP POST /mcp
                ┌────────────────────────────────────────────────┐
                │              autopilot.js (core)                │
                │  ┌────────────────────┐  ┌─────────────────┐   │
                │  │   Auth middleware  │  │  Rate limiter   │   │
                │  │  (bearer → token)  │  │ (per-tok, /min) │   │
                │  └────────────────────┘  └─────────────────┘   │
                │  ┌────────────────────┐  ┌─────────────────┐   │
                │  │  Scope enforcement │  │   Audit logger  │   │
                │  └────────────────────┘  └─────────────────┘   │
                │  ┌────────────────────┐  ┌─────────────────┐   │
                │  │ JSON-RPC dispatch  │  │  Tier-2 helper  │   │
                │  └────────────────────┘  └─────────────────┘   │
                └────────────────┬───────────────────────────────┘
                                 │
            ┌────────────────────┼────────────────────────┐
            ▼                    ▼                        ▼
    ┌──────────────┐    ┌──────────────┐         ┌──────────────┐
    │ resources    │    │  tools/call  │         │ prompts/get  │
    │   /list /read│    │              │         │              │
    └──────┬───────┘    └──────┬───────┘         └──────┬───────┘
           │                   │                        │
           ▼                   ▼                        ▼
    autopilot-       autopilot-* 16 modules        autopilot-
    resources.js     (one per domain)              prompts.js
                                                   (slash commands)

Le core (autopilot.js) gère :

• Auth (resolution du bearer token, vérification d'expiration / révocation)
• Rate limiting (sliding window 60s par token, bucket default + bucket ai)
• Scope enforcement (chaque tool déclare ses scopes requis)
• Audit (chaque appel loggé dans autopilot_audit_log avec params + result status)
• Dispatch JSON-RPC (initialize, tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get)

Les 16 modules enregistrent leurs tools via autopilot.registerTool({ name, description, inputSchema, scopes, handler }). Chaque tool définit ses propres scopes et délègue au DB/business layer.

L'helper Tier-2 (autopilot-tier2.js) centralise la machinerie de confirmation à deux étapes pour les opérations destructives (cf. Tier System).

Voir aussi

• MCP — Concept — JSON-RPC, handshake, capabilities
• Tokens — création, révocation, rate limit, spend cap
• Scopes — les 42 scopes + 4 presets
• Tier System — Tier-1 vs Tier-2, confirm_token, idempotent replay
• Tools Reference — les 181 tools listés
• API — endpoints HTTP REST (alternative au MCP)