TON MCP: el primero donde el agente mueve valor entre redes

Agente DeFAI en TON: por qué a un agente no le basta con leer la blockchain

Tu agente de IA sabe responder preguntas sobre TON: el saldo de una wallet, el estado de un contrato, el historial de transacciones. El usuario escribe: «Tengo 500 USDT en TON y quiero entrar en una posición en Base». Y el agente se queda parado. Lo ve todo, pero no puede hacer nada. Entre «leer la blockchain» y «mover valor» hay un abismo que un MCP read-only normal no salva. Un agente que solo lee es un dashboard con chat. DeFAI (DeFi + AI) empieza donde el agente mueve valor, no donde se limita a mirarlo.

El segundo muro es la confianza. La mayoría de las «wallets inteligentes para agentes» son custodiales: para que el agente pueda enviar algo, alguien tiene que guardar la clave y firmar. Para un bot autónomo eso significa que la clave privada o de operador vive en un sitio que tú no controlas. Para producción con dinero ajeno, eso es inaceptable.

TONNode es un servidor MCP hosted para TON (web: tonnode.io) con exactamente 16 herramientas: lectura, swap, cross-chain y generación de wallets. Lo clave: las herramientas de swap, cross-chain y wallet son estrictamente no custodiales. El servidor nunca firma ni guarda fondos ni claves privadas: devuelve mensajes TonConnect sin firmar que firma la wallet del usuario. Eso es un MCP cross-chain para TON sin renunciar al control de las claves.

Para que una acción sea segura hacen falta dos cosas:

• El agente prepara la transacción, pero no la firma. La firma la pone la wallet del usuario vía TonConnect. El servidor no toca las claves.
• El agente sabe operar más allá de una sola red. El valor en cripto vive en varias redes a la vez, y «solo TON» cubre apenas la mitad del problema.

TONNode hace las dos. Abajo, cómo montar un agente DeFAI real con estas herramientas.

Swap no custodial: get_swap_quote y build_swap_tx vía Omniston

El swap en TONNode son dos herramientas con responsabilidades separadas: primero la cotización, después la construcción.

• get_swap_quote — cotización firme del intercambio GRAM⇄jetton a través del protocolo Omniston, que agrega la liquidez de STON.fi y DeDust. Es decir, el agente obtiene el mejor precio de los dos DEX más grandes a la vez, en lugar de adivinar dónde conviene.
• build_swap_tx — construye la transacción de swap sin firmar, lista para TonConnect. Este paso es justamente la esencia de lo no custodial: el servidor entrega el mensaje y lo firma la wallet del usuario.

La analogía es simple. get_swap_quote es el cartel de precios de una casa de cambio. build_swap_tx es el recibo relleno que tú lees y firmas por tu cuenta. El cajero (el servidor) no mete la mano en tu cartera.

En un diálogo con el agente se ve así:

Usuario: cambia 100 GRAM a USDT, muéstrame el tipo de cambio antes de confirmar

Agente → get_swap_quote (GRAM → USDT, 100)
Agente: recibirás ≈ X USDT al tipo Y (ruta Omniston). ¿Construyo la transacción?

Usuario: sí

Agente → build_swap_tx
Agente: listo, fírmala en tu wallet ↓ (TonConnect)

Un detalle importante para que las cantidades sean correctas: los jettons se almacenan en unidades raw y la conversión depende de los decimals. USDT tiene decimals = 6; la mayoría de los jettons, 9. Antes de mostrar un saldo o una cantidad, el agente debe llamar a get_jetton_info (metadatos del jetton: nombre, símbolo, decimals, emisión) y a get_jetton_balance (saldo del jetton; la jetton-wallet se calcula on-chain). Si no, el agente le mostrará al usuario «50000000» en vez de «50».

Las claves no salen del dispositivo del usuario en ningún paso. Más sobre este esquema en el análisis del swap no custodial para agentes.

MCP cross-chain para TON: escrow HTLC atómico y camino hacia 6 redes EVM

Ahora, lo que no tiene ningún otro MCP para TON: swap cross-chain de TON a redes EVM sin un puente custodio. TONNode lo hace mediante un escrow HTLC atómico (Hashed TimeLock Contract).

La mecánica se parece a una operación con una caja de seguridad de dos cerraduras:

1. Los fondos se bloquean en un contrato de escrow en ambas redes bajo un mismo hash del secreto.
2. Mientras el secreto no se revela, el dinero no se mueve a ninguna parte.
3. Revelar el secreto desbloquea las dos partes a la vez: o la operación se completa entera, o no se completa en absoluto. No existe el estado intermedio de «el dinero salió pero no volvió».
4. Si la contraparte se cuelga, al vencer el timeout los fondos vuelven a su dueño.

Se soportan exactamente estas redes, y TON es siempre el origen:

• Ethereum
• Arbitrum
• Base
• BNB Chain
• Polygon
• Avalanche

TRON de momento no está soportado — es importante decírselo al usuario con honestidad, para que el agente no prometa lo imposible.

El punto clave de lo no custodial aquí: build_crosschain_swap_tx devuelve tanto la transacción HTLC de escrow sin firmar como el secreto — el secreto queda en manos del usuario/agente, no en el servidor. Revelar el secreto es un paso explícito aparte, tras verificar on-chain que todo está listo. El desglose completo de la mecánica está en el artículo sobre el swap cross-chain TON → Ethereum.

Cinco herramientas cross-chain: cotización, construcción, tracking, revelación, refund

Una operación cross-chain no es un botón, es una máquina de estados. A cada estado le corresponde su herramienta:

1. get_crosschain_quote — cotización del intercambio cross-chain: cuánto recibirá el usuario en la red de destino, comisiones, ruta.
2. build_crosschain_swap_tx — transacción HTLC de escrow sin firmar + el secreto. La transacción la firma la wallet del usuario; el secreto se queda con él.
3. track_crosschain_swap — fases de la operación en ambas redes: si el escrow está bloqueado en TON, si apareció el bloqueo espejo en el lado EVM, si el secreto ya se reveló, si la liquidación terminó.
4. disclose_crosschain_secret — revelar el secreto para liquidar, pero solo tras verificar on-chain que todo está listo. Es la protección contra revelar el secreto antes de tiempo y perder el control de la operación.
5. build_crosschain_refund — construye la transacción de devolución de fondos desde el escrow si la operación se atascó y saltó el timeout.

El ciclo de vida completo de la operación

Así es el flujo que recorre el agente desde la cotización hasta la liquidación o la devolución:

get_crosschain_quote        → cotización TON → Base
build_crosschain_swap_tx    → tx HTLC de escrow sin firmar + secreto
   (el usuario firma el escrow con su wallet)
track_crosschain_swap       → esperamos a que la contraparte esté lista
disclose_crosschain_secret  → revelamos el secreto, se liquida
   ── si se atasca ──
build_crosschain_refund     → devolución desde el escrow

Fíjate: el refund está integrado en el diseño, no cosido por fuera. Es precisamente build_crosschain_refund lo que hace la construcción segura para un agente autónomo: aunque algo salga mal, los fondos no se quedan atrapados — hay un camino determinista de vuelta. Este quinteto convierte el «puente que da miedo» en un proceso predecible paso a paso.

Dónde está el foso de TONNode: no custodial + cross-chain + hosted

Hagamos una comparación honesta con el paquete oficial. @ton/mcp de la TON Foundation es una wallet-agente custodial con esquema split-key: la clave de operador la tiene el agente, la de owner el usuario, y el agente firma por sí mismo. Sabe hacer mucho — lectura, envío de GRAM/jettons/NFT, swap vía agregador de DEX, trabajo con NFT y DNS, creación e importación de wallets de agente — y es el oficial. Son puntos fuertes y no hay por qué menospreciarlos.

Pero dos limitaciones pesan:

• Es custodial: la clave de operador la tiene el agente, es decir, el agente puede gastar de forma autónoma. Para algunos escenarios es cómodo; para otros, un riesgo inaceptable.
• Es solo TON: no hay cross-chain.

TONNode se diferencia en tres ejes:

	@ton/mcp oficial	TONNode
Modelo de claves	Custodial (split-key, firma por sí mismo)	No custodial (devuelve mensajes TonConnect sin firmar)
Cross-chain	No, solo TON	TON → 6 redes EVM, HTLC atómico
Despliegue	Local / HTTP / serverless	Local (npx) y endpoint hosted

Lo no custodial no es una casilla de marketing, es un foso arquitectónico. El servidor nunca firma ni guarda fondos ni claves privadas. Incluso generate_wallet (crea una wallet TON nueva en las versiones v3r2 / v4 / v5r1 / highload_v3) entrega la mnemónica y las claves al usuario — el servidor no las guarda. La comparación extendida de ambos enfoques está en MCP custodial contra no custodial.

Un pequeño apunte terminológico para evitar confusiones: GRAM es el Toncoin renombrado (el cambio de nombre fue en junio de 2026); la red en sí sigue llamándose TON.

Cómo conectarlo y montar tu propio agente DeFAI

Puedes empezar gratis y en local, sin tarjeta y sin registro. El paquete @tonnode/mcp es open source (MIT) y funciona sobre el protocolo nativo ADNL de TON, sin capas HTTP intermedias.

Config local y hosted

Config local (conjunto público, lectura completa) — basta con añadirlo al config de tu cliente MCP:

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

Endpoint hosted (capacidad garantizada, tu propia clave):

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

El config sirve para cualquier cliente MCP: Claude, Cursor, ChatGPT/Codex.

Esqueleto del agente DeFAI

Esqueleto de un agente DeFAI sobre las herramientas de TONNode — el flujo típico de «entrar en una posición en otra red»:

Comprobar qué tiene el usuario:
  get_balance          → saldo de GRAM
  get_jetton_info      → decimals del jetton (USDT = 6, normalmente 9)
  get_jetton_balance   → saldo de USDT/jetton (la wallet se calcula on-chain)

Si el usuario quiere un intercambio dentro de TON:
  get_swap_quote → build_swap_tx → firma en la wallet

Si el usuario quiere sacar valor a Base/Ethereum/…:
  get_crosschain_quote
  → build_crosschain_swap_tx (firma, el secreto queda con el usuario)
  → track_crosschain_swap (esperamos a que esté listo)
  → disclose_crosschain_secret (liquidación)
  → build_crosschain_refund (si se atasca)

A partir de ahí todo descansa en el system prompt — el cliente enruta las llamadas por su cuenta:

Eres un asistente DeFAI para TON. Reglas:
1. Antes de mostrar cualquier cantidad de un jetton, llama a
   get_jetton_info (decimals) y get_jetton_balance.
2. Para un swap: primero get_swap_quote, muestra el tipo de cambio
   y después build_swap_tx. Nunca pidas claves privadas — la transacción
   la firma la wallet del usuario vía TonConnect.
3. Para cross-chain: get_crosschain_quote → build_crosschain_swap_tx →
   track_crosschain_swap → disclose_crosschain_secret.
   El origen es siempre TON; el destino, una de las 6 redes EVM
   (Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche);
   TRON no está soportado.
4. Si la operación se atasca, propón build_crosschain_refund.

El montaje paso a paso de un agente de trading lo tratamos aparte — cómo construir un agente de trading en TON.

Planes

En todos los planes están disponibles las 16 herramientas; solo pagas por el ancho de banda:

• Hobby — gratis para siempre, 60 peticiones/min
• Pro — $29/mes, 300 peticiones/min
• Scale — $199/mes, 1200 peticiones/min

La clave gratuita de Hobby se entrega nada más iniciar sesión, sin tarjeta. Pro/Scale se pueden pagar en GRAM o USDT en la red TON vía TonConnect, o en BTC/ETH/SOL y otras monedas mediante una factura de xRocket en Telegram; la clave se emite automáticamente al liquidarse el pago.

---

Un MCP read-only convierte al agente en observador. El swap no custodial y el cross-chain lo convierten en ejecutor — sin quitarle las claves al usuario. Leer TON lo saben hacer muchos; mover valor de TON a seis redes EVM sin entregar las claves, por ahora solo TONNode. Eso es DeFAI en TON: el agente mueve el valor y el control se queda con su dueño.

Consigue tu clave Hobby gratis y conecta tu primer agente ahora mismo → tonnode.io/dashboard?plan=hobby

Más sobre el tema: la lista completa de herramientas en tonnode.io/mcp, límites y planes en tonnode.io/pricing.