TON MCP gratuit : connecter un agent IA à TON sans clé

Vous demandez à Claude ou Cursor de « vérifier le solde de ce wallet TON et afficher les dernières transactions » — et l'agent s'exécute de bonne foi. Il interroge un lightserver public tiré de la config globale, reçoit not ready, réessaie, se prend un timeout ADNL. Ou bien il passe par toncenter sans clé, se heurte à la limite d'environ une requête par seconde et récolte un HTTP 429 Too Many Requests. Un agent ne sait pas lire TON tout seul — il lui faut des outils. Et c'est à ce stade que la plupart des développeurs se disent qu'il va falloir monter un nœud, bricoler des configs, payer l'accès. En réalité, non : on peut connecter un agent à TON gratuitement et sans ces galères — de deux façons différentes, et aucune des deux ne demande de carte bancaire.

Le moyen le plus rapide d'outiller un agent pour TON, c'est MCP. Model Context Protocol est le standard par lequel les agents IA (Claude, Cursor, ChatGPT/Codex et n'importe quel client MCP) appellent des outils externes. Plutôt que d'apprendre à l'agent à manipuler du JSON-RPC brut et à décoder des cells, vous lui donnez un jeu d'outils prêts à l'emploi comme get_balance ou get_jetton_balance — et il décide lui-même quand les appeler. TONNode est un serveur MCP hébergé pour TON (site tonnode.io), et il permet de mettre en place un TON MCP gratuit de deux manières, dont aucune n'exige de carte. Passons les deux en revue.

TON MCP gratuit : deux voies — npx en local et clé Hobby

Pour connecter votre agent à TON gratuitement, vous avez le choix :

1. Lancement local via npx sur la config publique — sans aucune clé ni inscription. Le paquet se télécharge et tourne sur votre machine.
2. Clé Hobby gratuite — connexion sur le site, clé délivrée immédiatement, sans carte, 60 requêtes par minute via l'endpoint hébergé.

La différence entre les deux ne tient pas au jeu d'outils, mais à l'endroit où tourne le processus et à ce qui fournit le débit. Commençons par le plus simple.

Méthode 1 : lancement local via npx sur la config publique (sans clé)

C'est littéralement un seul bloc dans la config de votre client MCP. Aucune installation préalable — npx récupère le paquet tout seul.

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

C'est tout. Au démarrage du client, un processus local @tonnode/mcp se lance, se connecte à TON via le protocole natif et expose à l'agent le jeu complet d'outils de lecture. Pas besoin de clé, pas besoin de carte, pas besoin de compte.

Détail important sous le capot : le paquet @tonnode/mcp est open source (MIT), publié sur npm et GitHub (tonnode/mcp), et fonctionne via le protocole natif ADNL de TON, sans couche HTTP intermédiaire entre votre agent et le réseau. Autrement dit, ce n'est pas un wrapper autour de l'API REST d'un tiers, condamné à buter sur le rate limit de ce tiers — c'est un client direct vers le réseau.

Où placer cette config

• Claude Desktop / Claude Code — dans la section mcpServers du fichier de configuration MCP.
• Cursor — dans les réglages des serveurs MCP du projet, ou en global.
• ChatGPT/Codex et les autres clients MCP — dans leur section de connexion MCP.

Le détail client par client, captures à l'appui, se trouve dans un guide dédié : comment connecter Claude et Cursor à TON.

Ce qui est disponible gratuitement : le jeu complet de lecture TON

Le mode local gratuit n'est pas une démo au rabais. Vous disposez du jeu complet de lecture, huit outils qui couvrent l'immense majorité des tâches agentiques :

• get_masterchain_info — la « tête » de la masterchain : l'état courant du réseau, grâce auquel l'agent sait « où en est » la chaîne.
• get_balance — le solde d'un wallet en GRAM (c'est le Toncoin renommé en juin 2026 ; le réseau, lui, s'appelle toujours TON).
• get_account_state — statut du compte, flags, dernière transaction. Utile pour savoir si un contrat est déployé et si un wallet est actif.
• get_transactions — l'historique des transactions d'une adresse.
• run_get_method — l'appel de n'importe quel get-method read-only sur un contrat arbitraire. Votre « lecteur universel » pour les smart contracts.
• get_jetton_balance — le solde d'un jetton, USDT compris ; l'adresse du jetton-wallet est calculée on-chain, inutile de la connaître à l'avance.
• get_jetton_info — les métadonnées d'un jetton : nom, symbole, émission et, crucial pour les calculs, decimals. USDT a decimals = 6, la plupart des jettons en ont 9 — sans ce nombre, impossible de convertir les unités brutes en montants lisibles.
• parse_address — conversion et validation d'adresses (EQ/UQ/raw), fonctionne hors ligne, sans toucher au réseau.

Exemple concret. La tâche classique « affiche le solde USDT en un seul appel » se résout par la combinaison get_jetton_info (pour connaître les decimals) + get_jetton_balance. Un prompt en langage naturel suffit à l'agent :

Vérifie le solde USDT à l'adresse UQAbc...xyz
et affiche-le avec le bon nombre de décimales.

L'agent appellera lui-même get_jetton_info, verra decimals: 6, puis get_jetton_balance, et renverra le montant correct — sans une seule ligne de code de votre part. L'analyse détaillée est dans le guide MCP pour TON, avec un exemple dédié : comment obtenir un solde USDT sur TON en un appel.

Méthode 2 : la clé Hobby gratuite — 60 requêtes/min sans carte

Le npx local est parfait pour le développement et les tâches ponctuelles, mais il a une limite : il passe par les lightservers publics de la config globale de TON. Ils sont partagés et limités, renvoient souvent not ready ou un timeout ADNL sous charge, et ne conservent pas d'historique profond. Pour un agent en production qui répond à de vrais utilisateurs, c'est une loterie.

C'est là qu'intervient la seconde voie gratuite — le plan Hobby. Il est gratuit à vie, offre 60 requêtes par minute, et la clé est délivrée immédiatement après connexion, sans carte. La différence avec le mode local, c'est que les requêtes ne partent plus de votre machine via l'infrastructure publique partagée, mais passent par l'endpoint hébergé de TONNode avec votre clé personnelle — vous avez donc une limite prévisible de 60 requêtes/min, attachée à vous et à personne d'autre.

La config pour la connexion hébergée ressemble à ceci :

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

Deux différences avec la config locale : type: "http" au lieu du lancement d'un processus, et l'en-tête Authorization avec votre clé tn_live_…. L'agent, lui, ne verra aucune différence à l'usage — mêmes outils, mêmes noms, mêmes paramètres.

Point important : sur Hobby, comme sur tous les autres plans, les 16 outils de TONNode sont disponibles — pas seulement la lecture, mais aussi le swap, le cross-chain, la génération de wallet. C'est justement la clé hébergée qui ajoute aux huit outils de lecture, entre autres, generate_wallet : la création d'un nouveau wallet TON en version v3r2, v4, v5r1 ou highload_v3. L'outil vous renvoie directement la mnémonique, les clés et l'adresse, et le serveur ne conserve aucun des wallets générés. Le plan ne limite donc pas les fonctionnalités, mais le débit : vous ne payez que le throughput, le jour où vous en aurez besoin.

Obtenir une clé Hobby (sans carte) : tonnode.io/dashboard?plan=hobby.

Local ou hébergé : quand le gratuit suffit, et quand il faut du débit

En bref : le gratuit suffit presque toujours tant qu'on parle de développement, de prototypes et d'une fréquence d'appels modérée. La différence entre les modes ne porte pas sur le jeu d'outils, mais sur le débit.

Mode	Clé / carte	Débit	Pour quoi
npx local	Aucune des deux	Lightservers publics (partagés, limités)	Développement, tâches ponctuelles
Hobby (hébergé)	Clé, sans carte	60 requêtes/min sur votre clé	Projets perso, prod légère
Pro / Scale (hébergé)	Clé + paiement	300 / 1200 requêtes/min	Prod à forte charge

Le point clé : tous les plans donnent accès aux 16 outils — swap et cross-chain compris. Vous ne payez que le débit, jamais le « déblocage » de fonctions. Pro coûte 29 $/mois et donne 300 requêtes/min ; Scale, 199 $/mois et 1200 requêtes/min. Le throughput payant devient nécessaire exactement au moment où 60 requêtes par minute ne vous suffisent plus, ou quand il vous faut une limite personnelle prévisible sur l'endpoint hébergé mcp.tonnode.io sous charge réelle. Le détail complet est sur la page des tarifs et la page des outils.

Pas à pas : connecter l'agent et faire le premier appel

Assemblons le tout en prenant l'exemple du lancement local (pour Hobby, seul le bloc de config change).

Étape 1. Ajoutez le serveur à la config de votre client MCP. Prenez le bloc avec npx -y @tonnode/mcp montré plus haut et collez-le dans la config de votre client (Claude, Cursor, Codex — le chemin dépend du client).

Étape 2. Redémarrez le client. Il lancera le processus @tonnode/mcp et découvrira les outils. La plupart des clients affichent la liste des outils connectés dans l'interface — vérifiez que ton y figure bien.

Étape 3. Donnez une tâche à l'agent en texte libre. Par exemple :

Récupère la tête actuelle de la masterchain TON et, au passage,
le solde de l'adresse UQAbc...xyz en GRAM.

L'agent appellera de lui-même get_masterchain_info, puis get_balance, et vous restituera le résultat en langage naturel.

Étape 4. Les tâches plus complexes — toujours en un seul prompt. Par exemple :

Combien d'USDT sur le wallet UQAbc...xyz ? Renvoie le montant en tenant compte des decimals.

Ici, l'agent appellera get_jetton_info pour connaître les decimals d'USDT (=6), puis get_jetton_balance pour obtenir le solde brut, et le convertira en montant lisible. Le jetton-wallet sera calculé on-chain — inutile de lui passer son adresse.

Étape 5. Quand vous buterez sur la limite des lightservers publics (vous verrez not ready ou des timeouts) — remplacez le bloc par la config hébergée avec une clé Hobby. Seule la config change ; les prompts et la logique de l'agent restent identiques.

Non-custodial : pourquoi l'accès gratuit ne présente pas de risque

Question légitime : si le serveur est gratuit et que c'est lui qui génère les wallets et construit les transactions — est-ce que je risque mes clés ? Non, et c'est un choix d'architecture assumé. TONNode est strictement non-custodial.

Le serveur ne signe jamais rien et ne détient ni fonds ni clés privées. Les outils de lecture se contentent de lire l'état on-chain public. Quant aux outils qui modifient l'état — swap et cross-chain — ils n'envoient rien en votre nom : ils renvoient des messages TonConnect non signés. C'est le wallet de l'utilisateur qui les signe, en local, avec sa propre clé. Même chose pour generate_wallet (disponible avec une clé hébergée) : le wallet généré et sa mnémonique vous sont remis, le serveur n'en garde pas de copie.

Autrement dit, l'accès gratuit n'est pas plus risqué que l'accès payant : seul le détenteur du wallet peut physiquement signer une transaction — le serveur n'a aucune clé qui lui permettrait de signer quoi que ce soit. C'est la différence fondamentale avec le modèle custodial, où le serveur détient une clé d'opérateur et signe lui-même. La comparaison des deux approches et de leurs risques fait l'objet d'un article dédié : MCP custodial ou non-custodial.

En résumé

Pour outiller un agent IA sur TON, pas besoin de monter un nœud ni de carte bancaire. Le npx -y @tonnode/mcp local offre le jeu complet de lecture sans clé, tout de suite — idéal pour essayer. Le plan gratuit Hobby ajoute 60 requêtes/min prévisibles sur votre clé via l'endpoint hébergé, toujours sans carte, quand les lightservers publics commencent à ne plus suivre. Les deux modes sont non-custodiaux, les deux utilisent exactement les mêmes outils, et vous pouvez à tout moment passer au throughput payant sans rien réécrire dans la logique de votre agent.

Obtenir une clé Hobby gratuite (sans carte) : tonnode.io/dashboard?plan=hobby