TON MCP: TONNode vs @ton/mcp oficial, comparativa honesta

@ton/mcp vs TONNode: comparativa honesta — y la primera pregunta es quién tiene las claves

Esta comparativa de dos MCP para TON no empieza con una lista de features, sino con una sola pregunta de seguridad. Imagina la escena: le has dado a Claude o a Cursor acceso a TON. El agente lee saldos, arma swaps, llama get-methods. Todo funciona — hasta el momento en que hay que firmar una transacción. Y a las 3 de la madrugada, por un prompt mal formulado (o por una instrucción colada desde la web), el agente decide «optimizar el portafolio» y firma la transacción él solo. Los fondos ya no están. Te enteras a la mañana siguiente.

No es una historia de miedo, sino la consecuencia directa de una decisión de arquitectura: ¿el agente firma él mismo con su propia clave, o la firma queda siempre en manos de la wallet del usuario? Exactamente en ese punto divergen los dos MCP maduros para TON — el @ton/mcp oficial de la TON Foundation y TONNode. Ambos le dan al agente capacidad real de operar en la blockchain. Vamos a analizarlos con honestidad, sin menospreciar a ninguno de los dos — para tareas distintas, ambos enfoques tienen todo el derecho a existir.

Por qué compararlos: dos enfoques distintos de MCP para TON

MCP (Model Context Protocol) es el estándar mediante el cual los agentes de IA (Claude, Cursor, ChatGPT/Codex, cualquier cliente MCP) invocan herramientas. Para TON eso significa: el agente recibe un conjunto de funciones tipo get_balance o build_swap_tx y las llama por su cuenta durante la conversación, cuando lo considera necesario.

La diferencia entre @ton/mcp y TONNode no está en la lista de comandos, sino en la filosofía. Una analogía: @ton/mcp es como darle a tu asistente una tarjeta corporativa con límite: paga él mismo, rápido, de forma autónoma, pero la tarjeta está en sus manos. TONNode es el asistente que prepara la orden de pago y te la deja sobre la mesa para firmar: sin tu wallet no sale nada. Ambos modelos funcionan. La pregunta es para qué tarea.

Si te interesa más la teoría de fondo, hay un análisis aparte sobre MCP custodial frente a no custodial. Aquí vamos a lo concreto.

El @ton/mcp oficial: agente-wallet custodial con NFT y DNS

@ton/mcp es el paquete oficial de la TON Foundation, y esa es su gran baza: soporte del equipo de la red, evolución predecible, estatus de referencia.

En cuanto a arquitectura, es un agente-wallet custodial con modelo split-key:

• la clave operator la tiene el agente. Con ella el agente firma las transacciones por sí mismo, sin tu participación.
• la clave owner la tiene el usuario, como segundo nivel de control sobre la wallet.

Qué trae de serie:

• lectura del estado de la red, cuentas y saldos;
• envío de GRAM, jettons y NFT (el agente firma él mismo);
• swap vía agregador de DEX;
• creación e importación de agente-wallets;
• lectura de NFT y DNS — algo que TONNode todavía no tiene, y esa es una ventaja legítima del paquete oficial.

Se ejecuta en local, por HTTP o serverless. Limitación por diseño: solo TON, sin cross-chain.

Lo esencial aquí es la autonomía. El agente gasta por su cuenta, sin un humano en el ciclo de firma. Para escenarios tipo «que el agente pague él solo suscripciones/gas/microtareas», es exactamente lo que necesitas. Pero esa misma autonomía implica: la clave operativa con la que se dispone de los fondos está del lado del agente — y por tanto una inyección de prompt o una alucinación del modelo pueden traducirse en un gasto real.

TONNode: MCP no custodial, cross-chain y opción hosted

TONNode es un servidor MCP hosted para TON (sitio tonnode.io) con exactamente 16 herramientas. El invariante clave, en una sola frase:

El servidor nunca firma ni custodia fondos ni claves privadas. Las herramientas de swap, cross-chain y wallet devuelven mensajes TonConnect sin firmar. Los firma la wallet del usuario.

No existe ningún momento en el que el servidor pudiera llevarse los fondos, porque físicamente no tiene la clave. Veámoslo por grupos.

Lectura (7+1)

Cubre el día a día:

get_masterchain_info — cabeza de la masterchain
get_balance          — saldo de GRAM
get_account_state    — estado, flags, última transacción
get_transactions     — historial de transacciones
run_get_method       — cualquier get-method read-only de un contrato
get_jetton_balance   — saldo de jetton/USDT (la jetton wallet se calcula on-chain)
get_jetton_info      — metadatos del jetton: nombre, símbolo, decimals, emisión
parse_address        — conversión EQ/UQ/raw, offline

get_jetton_info devuelve los decimals, imprescindibles para convertir unidades raw: USDT tiene 6, la mayoría de los jettons tienen 9.

Swap (2)

Funciona a través del protocolo Omniston — liquidez agregada de STON.fi y DeDust:

• get_swap_quote — cotización firme GRAM⇄jetton;
• build_swap_tx — transacción sin firmar, lista para TonConnect.

Cross-chain (5)

Lo que el paquete oficial no tiene en absoluto. Escrow atómico HTLC donde TON es siempre el origen:

• get_crosschain_quote — cotización;
• build_crosschain_swap_tx — transacción de escrow HTLC sin firmar + secreto;
• track_crosschain_swap — fases de la operación en ambas redes;
• disclose_crosschain_secret — revelar el secreto para liquidar, tras verificar on-chain que todo está listo;
• build_crosschain_refund — recuperar los fondos del escrow si la operación se queda colgada.

Redes soportadas: Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche. TRON aún no está soportado. En el artículo sobre el primer cross-chain para un agente en TON mostramos cómo funciona por dentro una operación de este tipo.

Wallet (1): generate_wallet crea wallets de las versiones v3r2/v4/v5r1/highload_v3 y entrega la mnemónica, las claves y la dirección al usuario — el servidor no las guarda.

Lo que TONNode todavía no tiene: herramientas de NFT y DNS — están en el roadmap. Si tu tarea de hoy es leer colecciones NFT o resolver dominios .ton, ese es terreno del paquete oficial. Y ojo con esto: TONNode tampoco tiene una herramienta directa de «enviar/transferir» GRAM o jettons. Todos los builders de transacciones sin firmar son build_swap_tx, build_crosschain_swap_tx y build_crosschain_refund, es decir, mover fondos solo es posible dentro de un swap, un cross-chain o un refund del escrow. Un «send» arbitrario no existe aquí, por diseño.

Tabla comparativa: @ton/mcp vs TONNode

Criterio	@ton/mcp oficial	TONNode
Quién firma	El propio agente (clave operator, split-key)	La wallet del usuario (el servidor no firma)
Modelo	Custodial	Estrictamente no custodial
Gasto autónomo	Sí	No (por diseño)
Envío directo de GRAM/jettons	Sí, de forma autónoma	No hay herramienta dedicada; transferir solo es posible dentro de un swap/cross-chain, como tx sin firmar
Swap	Agregador de DEX	Omniston (STON.fi + DeDust)
Cross-chain	No (solo TON)	Sí, escrow HTLC hacia 6 redes
NFT / DNS	Sí (lectura)	En el roadmap
Generación de wallet	Creación/importación de agente-wallets	v3r2/v4/v5r1/highload_v3, las claves quedan en manos del usuario
Ejecución	Local / HTTP / serverless	Local (npx) + endpoint hosted
Estatus	Oficial, TON Foundation	Independiente, open source (MIT)

La bifurcación clave: quién tiene las claves del agente

Todo lo demás son detalles. La decisión real está en una sola pregunta: ¿estás dispuesto a que el agente firme transacciones por sí mismo?

En @ton/mcp la clave operator está en manos del agente — es decir, el agente puede gastar fondos a partir de un prompt, sin un segundo factor en forma de firma humana. Eso es potente para la autonomía y arriesgado ante una inyección de prompt o una alucinación: contexto comprometido = fondos potencialmente gastados.

En TONNode la firma físicamente no puede ocurrir en el servidor. Aunque el agente «se vuelva loco» y llame a build_swap_tx con parámetros absurdos, lo máximo que obtendrá es un objeto de transacción sin firmar. Hasta que la wallet del usuario no la confirme, nada se mueve. Es una garantía de arquitectura, no una política.

Ningún enfoque es «mejor» en abstracto — responden a niveles distintos de confianza en la autonomía del agente.

Cuándo elegir el @ton/mcp oficial y cuándo TONNode

Elige @ton/mcp si:

• necesitas gasto autónomo — el agente paga y firma él mismo, sin humano en el ciclo;
• trabajas estrictamente dentro de TON y no necesitas cross-chain;
• necesitas NFT y DNS hoy mismo;
• te importa el estatus oficial del paquete de la Foundation.

Elige TONNode si:

• solo la wallet del usuario debe poder disponer de los fondos, y no el agente — el patrón está desglosado en el artículo sobre swap no custodial para agentes en TON;
• necesitas cross-chain TON⇄EVM (Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche);
• necesitas swap vía la liquidez agregada de Omniston;
• necesitas un endpoint hosted con capacidad garantizada, no solo ejecución local.

No es «mejor/peor», son herramientas distintas. Y los enfoques no se excluyen: muchos equipos mantienen ambos servidores en su config — el oficial para NFT/DNS y tareas autónomas, TONNode para swap no custodial y cross-chain.

Cómo conectar cada uno

Si es tu primera vez por aquí, la introducción general está en la guía de MCP para TON.

TONNode en local — gratis, con el set completo de lectura

El paquete @tonnode/mcp es open source (MIT, en npm y en GitHub tonnode/mcp) y habla el protocolo nativo ADNL de TON sin capas HTTP intermedias:

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

TONNode hosted — tu propia clave, capacidad garantizada

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

Una vez conectado, al agente se le pueden dar tareas en texto normal — él mismo elegirá la herramienta:

Comprueba mi saldo de USDT en la wallet EQ… con get_jetton_balance.
Después pide un get_swap_quote para cambiar 50 USDT a GRAM
y arma la transacción con build_swap_tx.
No envíes la transacción — devuélvemela para firmarla en mi wallet.

El agente llamará a get_jetton_balance → get_swap_quote → build_swap_tx y devolverá un mensaje TonConnect sin firmar. El dinero solo se moverá tras la confirmación en la wallet.

Una tarea cross-chain suena igual de natural:

Arma un intercambio de 100 GRAM de TON a USDC en Base.
Dame get_crosschain_quote y luego build_crosschain_swap_tx.
Guarda el secreto y sigue el estado con track_crosschain_swap.

Todos los planes incluyen las 16 herramientas — solo pagas por la capacidad: Hobby — gratis para siempre, 60 peticiones/min; Pro — $29/mes, 300 peticiones/min; Scale — $199/mes, 1200 peticiones/min. La clave Hobby se entrega nada más iniciar sesión, sin tarjeta.

El @ton/mcp oficial

@ton/mcp se instala siguiendo las instrucciones de la TON Foundation y se ejecuta en local, por HTTP o serverless. En la configuración inicial se le crea o importa al agente una agente-wallet con clave operator. Ten presente el modelo custodial: piensa de antemano los límites y a qué fondos tendrá acceso el agente.

Conclusión

@ton/mcp es el agente-wallet custodial oficial: split-key, gasto autónomo, NFT y DNS, solo TON. TONNode es un servidor no custodial de 16 herramientas: el servidor nunca firma, añade cross-chain hacia 6 redes y una opción hosted. La diferencia es honesta y de arquitectura — va de a quién le confías el derecho de firma. Quien firma, define el perfil de riesgo.

La comparación detallada herramienta por herramienta está en la página TONNode frente al MCP oficial. Y puedes probar el enfoque no custodial ahora mismo, con la clave gratuita Hobby y sin tarjeta, desde aquí: tonnode.io/dashboard?plan=hobby.