TON MCP : TONNode vs @ton/mcp officiel, le comparatif honnête

@ton/mcp face à TONNode : comparatif honnête — et la première question, qui détient les clés ?

Ce comparatif de deux MCP pour TON ne commence pas par une liste de fonctionnalités, mais par une seule question de sécurité. Imaginez : vous avez donné à Claude ou à Cursor un accès à TON. L'agent lit les soldes, assemble des swaps, appelle des méthodes get. Tout fonctionne — jusqu'au moment où il faut signer une transaction. Et voilà qu'à 3 heures du matin, sur un prompt bancal (ou sur une instruction glissée depuis une page web), l'agent décide d'« optimiser le portefeuille » et signe la transaction lui-même. Les fonds sont partis. Vous l'apprenez au réveil.

Ce n'est pas une histoire pour faire peur, mais la conséquence directe d'un seul choix d'architecture : l'agent signe-t-il lui-même avec sa propre clé, ou la signature reste-t-elle toujours l'affaire du wallet de l'utilisateur ? C'est exactement sur ce point que divergent les deux MCP matures pour TON — le @ton/mcp officiel de la TON Foundation et TONNode. Tous deux donnent à l'agent les moyens d'agir sur la blockchain. Examinons cela honnêtement, sans dénigrer ni l'un ni l'autre : selon les cas d'usage, les deux approches ont leur raison d'être.

Pourquoi comparer : deux approches distinctes du MCP pour TON

MCP (Model Context Protocol) est le standard par lequel les agents IA (Claude, Cursor, ChatGPT/Codex, n'importe quel client MCP) appellent des outils. Pour TON, cela signifie : l'agent dispose d'un jeu de fonctions du type get_balance ou build_swap_tx et les appelle de lui-même au fil de la conversation, quand il le juge utile.

La différence entre @ton/mcp et TONNode ne tient pas à la liste des commandes, mais à la philosophie. Une analogie : @ton/mcp, c'est comme confier à un assistant une carte bancaire d'entreprise plafonnée — il paie lui-même, vite, en autonomie, mais la carte est entre ses mains. TONNode, c'est l'assistant qui prépare l'ordre de virement et vous le pose sur le bureau pour signature : sans votre wallet, rien ne part. Les deux modèles fonctionnent. La question est : pour quel usage.

Si l'aspect théorique vous intéresse davantage, une analyse dédiée existe : MCP custodial contre non-custodial. Ici, nous comparons le concret.

Le @ton/mcp officiel : agent-wallet custodial avec NFT et DNS

@ton/mcp est le paquet officiel de la TON Foundation, et c'est là sa force : le support de l'équipe du réseau, une évolution prévisible, un statut de référence.

Sur le plan architectural, c'est un agent-wallet custodial fondé sur un modèle split-key :

• clé operator — détenue par l'agent. C'est avec elle qu'il signe les transactions lui-même, sans votre intervention.
• clé owner — détenue par l'utilisateur, comme second niveau de contrôle sur le wallet.

Ce qu'il sait faire d'origine :

• lire l'état du réseau, des comptes et des soldes ;
• envoyer des GRAM, des jettons et des NFT (l'agent signe lui-même) ;
• swapper via un agrégateur de DEX ;
• créer et importer des agent-wallets ;
• lire les NFT et le DNS — ce que TONNode ne propose pas encore, et c'est un avantage réel du paquet officiel.

Il se lance en local, via HTTP ou en serverless. Limite par conception : TON uniquement, pas de cross-chain.

L'essentiel ici, c'est l'autonomie. L'agent dépense seul, sans humain dans la boucle de signature. Pour des scénarios du type « que l'agent paie lui-même l'abonnement, le gas ou des micro-tâches », c'est exactement ce qu'il faut. Mais cette même autonomie implique une chose : la clé opérationnelle qui donne la main sur les fonds se trouve du côté de l'agent — donc une injection de prompt ou une hallucination du modèle peut se traduire par une dépense bien réelle.

TONNode : MCP non-custodial, cross-chain et option hébergée

TONNode est un serveur MCP hébergé pour TON (site tonnode.io) doté d'exactement 16 outils. L'invariant clé tient en une phrase :

Le serveur ne signe jamais et ne détient ni fonds ni clés privées. Les outils de swap, de cross-chain et de wallet renvoient des messages TonConnect non signés. C'est le wallet de l'utilisateur qui les signe.

Il n'existe aucun instant où le serveur pourrait détourner des fonds, parce qu'il n'a physiquement pas la clé. Passons les groupes en revue.

Lecture (7+1)

Couvre le quotidien :

get_masterchain_info — tête du masterchain
get_balance          — solde en GRAM
get_account_state    — statut, flags, dernière transaction
get_transactions     — historique des transactions
run_get_method       — n'importe quelle méthode get read-only d'un contrat
get_jetton_balance   — solde d'un jetton/USDT (le wallet de jetton est calculé on-chain)
get_jetton_info      — métadonnées du jetton : nom, symbole, decimals, supply
parse_address        — conversion EQ/UQ/raw, hors ligne

get_jetton_info renvoie decimals — ils sont indispensables pour convertir les unités raw : USDT en a 6, la plupart des jettons en ont 9.

Swap (2)

Passe par le protocole Omniston — la liquidité agrégée de STON.fi et DeDust :

• get_swap_quote — une cotation ferme GRAM⇄jetton ;
• build_swap_tx — la transaction non signée, prête pour TonConnect.

Cross-chain (5)

Ce que le paquet officiel n'a tout simplement pas. Un escrow HTLC atomique, où TON est toujours la source :

• get_crosschain_quote — la cotation ;
• build_crosschain_swap_tx — la transaction d'escrow HTLC non signée + le secret ;
• track_crosschain_swap — les phases de l'opération sur les deux réseaux ;
• disclose_crosschain_secret — révéler le secret pour le règlement, après vérification on-chain que tout est prêt ;
• build_crosschain_refund — récupérer les fonds de l'escrow si l'opération reste bloquée.

Réseaux pris en charge : Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche. TRON n'est pas encore pris en charge. Le déroulé d'une telle opération est détaillé dans l'article sur le premier cross-chain pour un agent sur TON.

Wallet (1) : generate_wallet crée un wallet en version v3r2/v4/v5r1/highload_v3 et remet la phrase mnémonique, les clés et l'adresse à l'utilisateur — le serveur ne les stocke pas.

Ce que TONNode n'a pas encore : les outils NFT et DNS — ils sont dans la roadmap. Si votre besoin aujourd'hui est de lire des collections NFT ou de résoudre des domaines .ton, c'est le terrain du paquet officiel. Notez également ceci : TONNode n'a pas non plus d'outil direct « envoyer / transférer » des GRAM ou un jetton. Les seuls constructeurs de transactions non signées sont build_swap_tx, build_crosschain_swap_tx et build_crosschain_refund — autrement dit, un mouvement de fonds n'est possible que dans le cadre d'un swap, d'un cross-chain ou d'un remboursement d'escrow. Il n'y a pas ici de « send » arbitraire, et c'est un choix de conception.

Tableau comparatif : @ton/mcp face à TONNode

Critère	@ton/mcp officiel	TONNode
Qui signe	L'agent lui-même (clé operator, split-key)	Le wallet de l'utilisateur (le serveur ne signe pas)
Modèle	Custodial	Strictement non-custodial
Dépense autonome	Oui	Non (par conception)
Envoi direct de GRAM/jettons	Oui, en autonomie	Pas d'outil dédié ; le transfert n'existe qu'au sein d'un swap/cross-chain, sous forme de tx non signée
Swap	Agrégateur de DEX	Omniston (STON.fi + DeDust)
Cross-chain	Non (TON uniquement)	Oui, escrow HTLC sur 6 réseaux
NFT / DNS	Oui (lecture)	Dans la roadmap
Génération de wallet	Création/import d'agent-wallets	v3r2/v4/v5r1/highload_v3, les clés chez l'utilisateur
Lancement	En local / HTTP / serverless	En local (npx) + endpoint hébergé
Statut	Officiel, TON Foundation	Indépendant, open source (MIT)

Le vrai point de bascule : qui détient les clés de l'agent

Tout le reste n'est que détail. Le vrai choix tient à une seule question : êtes-vous prêt à ce que l'agent signe les transactions lui-même ?

Chez @ton/mcp, la clé operator est détenue par l'agent — donc l'agent peut dépenser des fonds sur simple prompt, sans second facteur sous forme de signature humaine. C'est puissant pour l'autonomie et risqué en cas d'injection de prompt ou d'hallucination : un contexte compromis = des fonds potentiellement dépensés.

Chez TONNode, la signature ne peut physiquement pas avoir lieu sur le serveur. Même si l'agent « perd la tête » et appelle build_swap_tx avec des paramètres absurdes, le maximum qu'il obtiendra est un objet transaction non signé. Tant que le wallet de l'utilisateur ne l'a pas confirmé, rien ne bouge. C'est une garantie architecturale, pas une politique interne.

Aucune des deux approches n'est « meilleure » dans l'absolu — elles correspondent à des niveaux de confiance différents envers l'autonomie de l'agent.

Quand choisir le @ton/mcp officiel, et quand choisir TONNode

Prenez @ton/mcp si :

• vous avez besoin que l'agent dépense en autonomie — il paie et signe seul, sans humain dans la boucle ;
• vous travaillez strictement à l'intérieur de TON et n'avez pas besoin de cross-chain ;
• il vous faut les NFT et le DNS dès aujourd'hui ;
• le statut officiel d'un paquet de la Foundation compte pour vous.

Prenez TONNode si :

• seul le wallet de l'utilisateur doit avoir la main sur les fonds, pas l'agent — le pattern est détaillé dans l'article sur le swap non-custodial pour agents sur TON ;
• il vous faut du cross-chain TON⇄EVM (Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche) ;
• il vous faut un swap via la liquidité agrégée d'Omniston ;
• il vous faut un endpoint hébergé avec un débit garanti, et pas seulement un lancement en local.

Ce n'est pas une question de « mieux » ou de « moins bien », mais d'outils différents. Les deux approches ne s'excluent pas : beaucoup d'équipes gardent les deux serveurs dans leur config — l'officiel pour les NFT/DNS et les tâches autonomes, TONNode pour le swap non-custodial et le cross-chain.

Comment connecter l'un et l'autre

Pour une introduction générale au MCP pour TON, si vous découvrez le sujet : le guide MCP pour TON.

TONNode en local — gratuit, tous les outils de lecture

Le paquet @tonnode/mcp est open source (MIT, sur npm et sur GitHub tonnode/mcp) et fonctionne via le protocole ADNL natif de TON, sans couche HTTP intermédiaire :

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

TONNode hébergé — votre clé, un débit garanti

{
  "mcpServers": {
    "ton": {
      "type": "http",
      "url": "https://mcp.tonnode.io/mcp",
      "headers": { "Authorization": "Bearer tn_live_…" }
    }
  }
}

Une fois connecté, vous pouvez confier à l'agent des tâches formulées en langage naturel — il choisira l'outil tout seul :

Vérifie mon solde USDT sur le wallet EQ… via get_jetton_balance.
Prends ensuite get_swap_quote pour échanger 50 USDT contre des GRAM
et assemble la transaction avec build_swap_tx.
N'envoie pas la transaction — rends-la-moi pour signature dans mon wallet.

L'agent appellera get_jetton_balance → get_swap_quote → build_swap_tx et vous rendra un message TonConnect non signé. L'argent ne bougera qu'après confirmation dans le wallet.

Une tâche cross-chain se formule tout aussi naturellement :

Assemble un échange de 100 GRAM depuis TON vers de l'USDC sur Base.
Donne get_crosschain_quote, puis build_crosschain_swap_tx.
Conserve le secret et suis le statut via track_crosschain_swap.

Tous les forfaits donnent accès aux 16 outils au complet — vous ne payez que pour le débit : Hobby — gratuit à vie, 60 requêtes/min ; Pro — 29 $/mois, 300 requêtes/min ; Scale — 199 $/mois, 1200 requêtes/min. La clé Hobby est délivrée dès la connexion, sans carte bancaire.

Le @ton/mcp officiel

@ton/mcp s'installe en suivant les instructions de la TON Foundation et se lance en local, via HTTP ou en serverless. Lors de la configuration initiale, vous créez ou importez pour l'agent un agent-wallet muni de la clé operator. Gardez le modèle custodial en tête : réfléchissez à l'avance aux plafonds et aux fonds auxquels l'agent aura accès.

En résumé

@ton/mcp est l'agent-wallet custodial officiel : split-key, dépense autonome, NFT et DNS, TON uniquement. TONNode est un serveur non-custodial de 16 outils : le serveur ne signe jamais, il ajoute le cross-chain sur 6 réseaux et une option hébergée. La différence est honnête et architecturale — elle porte sur la personne à qui vous confiez le droit de signature. Celui qui signe est aussi celui qui fixe le profil de risque.

Le comparatif détaillé outil par outil se trouve sur la page TONNode face au MCP officiel. Pour essayer l'approche non-custodiale dès maintenant, avec une clé Hobby gratuite et sans carte bancaire, c'est ici : tonnode.io/dashboard?plan=hobby.