@tonnode/mcp

Русская версия

MCP server that gives AI agents direct liteserver access to The Open Network (TON) — no HTTP gateways in the middle. Balances, account state, transaction history and contract get-methods over TON's native ADNL protocol.

Built by TONNode — private TON liteservers, archive nodes, mempool stream and indexed API.

Quick start

Add to Claude Desktop, Claude Code, ChatGPT, Cursor, Codex or any MCP client:

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

That's the whole integration. The server connects to TON mainnet via the public global config by default. Ready-made configs for every client — plus programmatic Node.js usage — live in examples/.

Related MCP server: Telegram MCP Server

Tools

Naming note: the native coin was renamed from Toncoin to GRAM in June 2026; the network itself is still called TON. Tool outputs use *_gram fields.

Wallet generation

generate_wallet mints a brand-new wallet — a 24-word mnemonic, its ed25519 keypair and the address for the chosen contract version (v4 default, plus v3r2, v5r1 and highload_v3 for mass payouts). The v3r2/v4/v5r1 addresses come from @ton/ton's canonical contracts; highload_v3 is derived from the official contract code and cross-checked against a maintained reference implementation.

⚠️ This returns secret key material. In hosted mode the keys are generated on the server and returned over TLS — treat every generated wallet as hot: fine for programmatic/ephemeral use, but move any meaningful balance to cold storage, and keep the response out of logs and shared transcripts. The server never stores or logs the mnemonic or private key (only the public address). Operators can set TONNODE_DISABLE_WALLET_GEN=1 to remove the tool entirely.

Swaps — agents that can actually trade

get_swap_quote and build_swap_tx are powered by Omniston, STON.fi's RFQ protocol aggregating STON.fi and DeDust liquidity. No API key needed.

The flow is strictly non-custodial — the server never sees a private key, never signs and never broadcasts:

1. get_swap_quote locks a firm quote (amounts in raw indivisible units; the answer includes the slippage floor, price impact, gas budget and DEX route).

2. build_swap_tx turns the quote into unsigned messages in exactly the shape tonConnectUi.sendTransaction() expects — signing and sending stay with the wallet owner.

Quotes expire in about a minute, so build promptly. Omniston emulates the transfer while building: if the wallet doesn't hold the input amount, the build fails up front instead of burning gas on-chain.

Cross-chain

The *_crosschain_* tools take the same idea across blockchains: pay in GRAM or any TON jetton, receive USDT/USDC/native coins on Ethereum, Arbitrum, Base, BNB, Polygon or Avalanche — settled through Omniston's atomic HTLC escrow, typically in well under a minute. TON is always the source chain (the signer is a TON wallet).

The agent drives the full atomic-swap lifecycle: quote → build (the tool generates the HTLC secret and hands it to the caller — the server keeps nothing) → sign & send → track both chains → disclose the secret to settle, or build a refund if the trade stalls. At no point can the server, the resolver or anyone else redirect the funds: the secret only completes the trade as quoted, and an unfilled escrow is always reclaimable by the owner wallet.

Hosted / self-hosted HTTP mode

The package also ships a Streamable-HTTP entry for remote deployments (this is what powers mcp.tonnode.io):

TONNODE_KEYS=tn_live_abc,tn_live_def PORT=8808 npx -y @tonnode/mcp --http

Want a ready-made hosted endpoint instead of running your own? Keys for mcp.tonnode.io are issued at tonnode.io/mcp. Clients connect without installing anything:

{
  "mcpServers": {
    "ton": {
      "url": "https://your-host/mcp",
      "headers": { "Authorization": "Bearer tn_live_abc" }
    }
  }
}

Requests are authenticated with Bearer keys and rate-limited per key (RATE_LIMIT_RPM, default 300). Besides Authorization: Bearer <key>, the server accepts a bare Authorization: <key> and X-API-Key: <key> — for gateways (e.g. Smithery) that reserve the Authorization header for themselves. Keys come from either TONNODE_KEYS (comma-separated, fixed) or TONNODE_KEYS_FILE — a JSON array of {"key", "label"?, "rpm"?, "expires"?} that is hot-reloaded on change and on SIGHUP: add or revoke customer keys with no restart, per-key rate limits, and self-expiring keys for subscription plans. A revoked key's live sessions are closed immediately. GLOBAL_RATE_LIMIT_RPM adds a total ceiling across all keys to protect the backend liteserver. Sessions are private to the key that opened them, idle sessions are swept after SESSION_TTL_MIN (default 30 minutes), and concurrent sessions are capped per key and globally. Without keys the server refuses to start; set TONNODE_ALLOW_OPEN=1 to explicitly run keyless behind your own firewall. GET /healthz for monitoring, deploy/tonnode-keys.sh for key management.

The server binds 127.0.0.1 by default — put a TLS reverse proxy (Caddy, nginx) in front and set HOST=0.0.0.0 only if the proxy runs on another machine. Ready-made systemd + Caddy configs live in deploy/.

Configuration

A note on public liteservers

The default public-config liteservers are shared, rate-limited and keep no deep history — get_transactions beyond recent blocks will answer lt not in db. Agents also tend to query in bursts, which public gateways throttle.

For guaranteed throughput, archive depth and a node-level mempool stream, point TON_LITESERVERS at a private liteserver — provisioned in under a minute, payable in TON. How the config file, ADNL keys and archive routing work is covered in the TON Liteserver guide.

License

MIT © TONNode