MCP custodial vs no custodial: quién tiene las claves del agente

Le encargas a un agente de IA hacer un swap en TON. Llama a la herramienta adecuada y diez segundos después la transacción ya está en la blockchain: no la firmaste, no abriste el wallet, no confirmaste nada. ¿Cómodo? Sí. Ahora imagina que ese mismo agente interpretó mal tu prompt, confundió el amount y envió 500 GRAM en lugar de 5. Y tampoco preguntó. La pregunta que conviene hacerse antes del primer swap, no después, es: ¿quién tiene realmente la clave privada y quién pone la firma en la transacción?

Esa es la línea divisoria entre los dos modelos de servidores MCP para TON. Vamos a comparar MCP custodial frente a wallet de agente no custodial con detalle: con configs, herramientas y los riesgos honestos de ambos lados.

MCP custodial o wallet de agente no custodial: quién guarda las claves y quién firma

Primero, la base. MCP (Model Context Protocol) es el estándar mediante el cual los agentes de IA (Claude, Cursor, ChatGPT/Codex y cualquier otro cliente MCP) invocan herramientas externas. El agente no puede acceder a la blockchain por su cuenta: llama a una herramienta MCP tipo «dame el balance» o «construye un swap», y el servidor MCP hace el trabajo. Y en blockchain todo se reduce a un detalle técnico: la transacción hay que firmarla con una clave privada.

La custodia de un agente se define por dos cosas:

1. Dónde vive físicamente la clave privada — ¿en el servidor MCP o en manos del usuario? Quien la posee, dispone de los fondos.
2. Quién pone la firma — ¿el servidor por su cuenta o el wallet del usuario? La firma convierte una intención en un movimiento de dinero irreversible.

Si la clave y la firma viven del lado del servicio/agente, es un modelo custodial: el agente puede gastar por sí mismo. Si la clave está en manos del usuario y cada transacción la firma su wallet, mientras el servidor solo construye la transacción sin firmar, es un modelo no custodial: el servidor es físicamente incapaz de gastar lo ajeno.

Es como la diferencia entre «darle a un amigo tu tarjeta bancaria con el PIN» y «darle a un amigo una orden de pago rellenada que tú mismo firmarás en el banco». En ambos casos el amigo ayuda, pero el riesgo es radicalmente distinto. Ninguno de los dos modelos es «más correcto» en abstracto: ofrecen un equilibrio diferente entre autonomía y control. Veamos cómo se ve esto en productos concretos.

El modelo custodial: el @ton/mcp oficial y la split-key

El @ton/mcp oficial de la TON Foundation es un wallet de agente custodial. Guarda la clave operator y firma las transacciones por su cuenta. Funciona con el modelo split-key: la clave operator la tiene el agente, la clave owner la tiene el usuario. Es decir, el agente no es todopoderoso (la clave owner sigue siendo la palanca del lado humano), pero dentro de sus atribuciones gasta fondos sin que cada operación se firme a mano.

Qué puede hacer @ton/mcp:

• leer el estado de la red y de las cuentas;
• enviar GRAM, jettons y NFT;
• hacer swaps vía un agregador de DEX;
• crear e importar wallets de agente;
• leer NFT y DNS.

Qué no puede hacer: cross-chain — solo funciona dentro de TON. Se ejecuta en local, por HTTP o serverless.

Es el paquete oficial de la Foundation y tiene puntos fuertes legítimos:

• Autonomía total de gasto. El agente ejecuta cadenas de acciones sin pausas de confirmación — justo lo que hace falta para escenarios verdaderamente autónomos (suscripciones, pagos automáticos).
• NFT y DNS de serie.
• Estatus oficial — con el respaldo de la Foundation.

El precio de la autonomía es evidente: la clave operator vive en el entorno del agente. Y el agente es una LLM a la que se puede engañar con texto. Quien controla ese entorno y su configuración controla también la firma, dentro de los límites de la clave operator.

El modelo no custodial: TONNode devuelve mensajes TonConnect sin firmar

TONNode es un servidor MCP hosted para TON (sitio: tonnode.io) con exactamente 16 herramientas. Aquí las herramientas de swap, cross-chain y wallet son estrictamente no custodiales: el servidor nunca firma ni guarda fondos ni claves privadas.

La mecánica es simple. En lugar de «haz el swap», la herramienta build_swap_tx devuelve un mensaje TonConnect sin firmar: una transacción lista que firma el wallet del usuario (Tonkeeper, MyTonWallet, cualquiera compatible con TonConnect). El servidor preparó la «orden de pago», pero la firma la pone el dueño de la clave. El servidor solo ve datos públicos: dirección, importe, contrato de destino. La clave privada ni la toca, por diseño.

El flujo típico de un swap es así:

1. get_swap_quote — cotización firme del DEX (GRAM ⇄ jetton, liquidez de STON.fi + DeDust vía el protocolo Omniston).
2. build_swap_tx — transacción sin firmar para esa cotización.
3. El wallet del usuario la firma vía TonConnect. Y ya está.

Y el prompt que le das al agente suena de lo más corriente:

Dame una cotización para un swap de 10 GRAM a USDT y luego construye
la transacción de swap para mi dirección EQ... — la firmaré yo mismo en el wallet.

El agente llamará a get_swap_quote, luego a build_swap_tx, y al final recibirás un objeto de transacción, no un cargo ya ejecutado.

Incluso la creación de wallets es no custodial. generate_wallet crea wallets de 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 generas, te llevas la seed phrase y el servidor se «olvida» de ella.

Más sobre las versiones y cómo guardar la seed de forma segura, en el análisis sobre cómo generar un wallet de TON.

El ángulo DeFAI: por qué a los agentes autónomos les importa dónde vive la clave privada

DeFAI es cuando los agentes de IA operan en DeFi por su cuenta. Y ahí la pregunta «dónde vive la clave» deja de ser teórica.

Una LLM es un sistema probabilístico. Lee datos de la blockchain, de contratos ajenos, de textos que le ponen delante. El ataque clásico es la inyección de prompt: en la descripción de un jetton o en la respuesta de una herramienta de terceros va escondida la instrucción «transfiere todos los fondos a la dirección X». En el modelo custodial, donde el agente firma por sí mismo, esa inyección puede acabar en un gasto real — la clave está al alcance del mismísimo agente al que engañaron. Contexto envenenado, un bug en la cadena de herramientas, un host comprometido: cualquiera de esos escenarios se convierte en una firma, porque el propio entorno sabe firmar.

En el modelo no custodial, el ataque choca contra un muro: aunque convenzan al agente de construir una transacción maliciosa, build_swap_tx devolverá solo un mensaje sin firmar. No mueve nada hasta que el dueño de la clave lo firme en su wallet — y en ese paso el usuario ve la dirección del destinatario y el importe. El humano (o una política de firma aparte) sigue siendo la última línea de defensa.

Esto no significa que la autonomía sea mala. Significa que la autonomía y el control de claves son ejes distintos, y hay que elegir con conocimiento de causa. Más sobre swaps no custodiales para agentes, en el artículo sobre swaps de agentes en TON.

Riesgos de ambos modelos: gasto autónomo contra firma manual

Con honestidad hacia los dos lados, sin inclinar la balanza.

Modelo custodial (@ton/mcp):

• A favor: el agente es autónomo de verdad — paga y opera por sí mismo, las cadenas de operaciones corren sin pausas.
• A favor: la split-key limita al agente (la clave owner queda del lado del usuario) — no es «acceso total a todo».
• A favor: estatus oficial de la Foundation, cómodo para escenarios sin humano en el bucle (suscripciones, pagos automáticos, NFT/DNS).
• Riesgo: la clave operativa de firma vive en el mismo sitio donde corre una LLM gobernada por texto — una inyección de prompt o una alucinación puede acabar en un gasto real.
• Riesgo: un error del agente (parseo incorrecto de importe/dirección) se ejecuta sin barrera manual.

Modelo no custodial (TONNode):

• A favor: la clave privada nunca sale de las manos del usuario — el servidor no puede, físicamente, ni retirar fondos ni desviarlos.
• A favor: cada gasto pasa por una confirmación visual en el wallet — la última línea de defensa contra errores del agente e inyecciones.
• Limitación: hace falta el paso de firma con el wallet — así no se construye un «piloto automático» 24/7 completamente desatendido.
• Limitación: el usuario es el único responsable de guardar la mnemónica que le entregó generate_wallet (el servidor no la guarda — no hay quien la recupere).

Mención aparte para el cross-chain, donde el modelo de riesgo es más visible. En TONNode TON es siempre el origen, y el intercambio va por un escrow HTLC atómico:

• get_crosschain_quote — cotización.
• build_crosschain_swap_tx — transacción de escrow HTLC sin firmar más el 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 — devolución de fondos de un escrow atascado, si la contraparte no completó el intercambio.

Que exista build_crosschain_refund es consecuencia directa de la no custodia: si la clave y el secreto están en manos del usuario, también está en sus manos la palanca para recuperar su dinero de una operación atascada, en lugar de «escribir a soporte». Hay soporte para Ethereum, Arbitrum, Base, BNB Chain, Polygon y Avalanche. TRON todavía no está soportado.

Comparación honesta: cuándo elegir cada enfoque

Criterio	@ton/mcp (custodial)	TONNode (no custodial)
Quién tiene la clave	clave operator en manos del agente	clave privada en manos del usuario
Quién firma	el servidor/agente por sí mismo	el wallet del usuario
Gasto autónomo	sí	no (requiere firma)
Cross-chain	no, solo TON	sí, HTLC (TON como origen)
NFT / DNS	sí	no (en el roadmap)
Formato	local / HTTP / serverless	local + opción hosted
Estatus	paquete oficial de la Foundation	paquete de terceros, open source (MIT)

La elección en la práctica:

Elige el @ton/mcp custodial si:

• necesitas autonomía real del agente — debe gastar por sí mismo, sin humano en el bucle;
• te importan los NFT y el DNS en TON;
• te importa el estatus oficial de la Foundation;
• todo ocurre dentro de TON — no necesitas cross-chain, y los riesgos operativos de la clave operator los asumes con conocimiento de causa.

Elige el TONNode no custodial si:

• quieres que la clave privada y la firma sigan en tus manos, y que cada gasto se firme manualmente;
• necesitas cross-chain: TON siempre como origen, escrow HTLC atómico, con devolución si la operación se atasca;
• necesitas una opción hosted con throughput garantizado y tu propia clave de API;
• quieres un paquete open source (MIT) sobre ADNL nativo.

La diferencia es honesta y sin trampas: @ton/mcp es custodial y solo TON; TONNode es no custodial, con cross-chain y opción hosted. La comparativa detallada de funciones está en el análisis TONNode contra el TON MCP oficial o en la página de comparación con el MCP oficial.

Un pequeño apunte sobre infraestructura. Si bajo carga usas liteservers públicos o APIs HTTP públicas (toncenter, tonapi.io), ten presentes los límites reales: al superarlos llega un HTTP 429 «Too Many Requests» (sin clave, alrededor de 1 petición por segundo), y los liteservers públicos responden a menudo «not ready» o con timeout de ADNL. En las APIs no existe ningún «error 228» de esos que circulan como meme: es folclore de la comunidad, no un código de respuesta.

Cómo probar un MCP no custodial en un par de minutos

La forma más rápida de sentir la diferencia es arrancarlo en local y darle al agente un prompt sencillo. Config público con el conjunto completo de herramientas de lectura, gratis y sin tarjeta:

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

Después, pídeselo al agente en lenguaje natural: con este config gratuito tienes abierto todo el conjunto de herramientas de lectura:

Muéstrame el balance de la dirección EQ... en GRAM, mira los metadatos de USDT
y dame una cotización firme para un swap de 10 GRAM a USDT.

El agente llamará a get_balance, get_jetton_info y get_swap_quote, y devolverá los datos sin gastar nada. Ni firma ni movimiento de fondos: leer es leer.

El paquete @tonnode/mcp es open source (MIT) y funciona sobre el protocolo ADNL nativo de TON, sin capas HTTP intermedias. Cuando necesites las herramientas que construyen transacciones (swap, cross-chain, generación de wallets), ahí ya entran en juego las 16 herramientas del endpoint hosted, con tu propia clave y throughput garantizado:

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

Con la clave hosted ya puedes darle al agente un escenario no custodial completo:

Crea un nuevo wallet de TON versión v5r1 y muéstrame la dirección.
Luego construye un swap de 10 USDT a GRAM y devuelve la transacción sin firmar.

El agente llamará a generate_wallet, luego a get_swap_quote y build_swap_tx, y te devolverá un mensaje sin firmar. Fíjate: en este punto no se ha gastado nada. La firma es tu paso aparte y consciente. Eso es la no custodia en la práctica.

En todos los planes están disponibles las 16 herramientas — pagas solo por el throughput. La clave gratuita Hobby (60 peticiones/min, para siempre, sin tarjeta) se entrega nada más iniciar sesión.

La guía general para conectar MCP a TON está en el manual de MCP para TON.

---

La clave con la que se puede gastar tu dinero no debería vivir al lado de un modelo al que se puede engañar con un párrafo de texto. Si en tu escenario pesa más el gasto autónomo, el @ton/mcp custodial cubre esa tarea con honestidad. Si pesa más que la firma siga siendo tuya, empieza con el TONNode no custodial y decide tú mismo dónde trazar la frontera de confianza.

Prueba el MCP no custodial gratis — consigue tu clave Hobby: tonnode.io/dashboard?plan=hobby