mcp-tronlink-signer

GitHub: https://github.com/TronLink/mcp-tronlink-signer

MCP Server that exposes tronlink-signer as MCP tools for Claude and other AI clients. Sign TRON transactions via TronLink browser wallet with user approval — private keys never leave the wallet.

Setup

Claude Code

claude mcp add -s user tronlink-signer -- npx mcp-tronlink-signer

Claude Desktop / Cursor

{
  "mcpServers": {
    "tronlink-signer": {
      "command": "npx",
      "args": ["mcp-tronlink-signer"]
    }
  }
}

From Source

git clone https://github.com/TronLink/mcp-tronlink-signer.git
cd mcp-tronlink-signer
pnpm install && pnpm build

Then point to the built CLI:

claude mcp add -s user tronlink-signer -- node /path/to/packages/mcp-tronlink-signer/dist/cli.js

MCP Tools

All tools support an optional network parameter (mainnet / nile / shasta), defaulting to mainnet.

Human-in-the-loop. Every tool that signs (send_trx, send_trc20, sign_message, sign_typed_data, sign_transaction) opens the TronLink approval page in the browser. The AI agent cannot sign without the user clicking Approve. Treat Remote Write tools as requiring confirmation in production.

MCP Resources

MCP Prompts

How It Works

1. AI agent calls an MCP tool (e.g., send_trx) — a signing notice is shown in the CLI
2. The server delegates to tronlink-signer, which opens a single browser tab for approval (reuses existing tab if open)
3. The approval page discovers TronLink via TIP-6963 protocol
4. Auto-unlocks wallet and switches network if needed
5. connect_wallet auto-completes if the wallet is already connected
6. Transaction details are parsed into human-readable format (TRX transfer, TRC20, TRC721 NFT, stake, delegate, vote, etc.)
7. User reviews and approves in the browser
8. TronLink signs the transaction — private keys never leave the wallet
9. Result is returned to the AI agent — the page stays open for the next operation

End-to-End Example

A typical send_trx flow, from the user's prompt to the on-chain result:

1. User → agent

"Send 5 TRX to TJRabc…xyz on nile."

2. Agent → MCP tool call

{
  "name": "send_trx",
  "arguments": { "to": "TJRabc...xyz", "amount": 5, "network": "nile" }
}

3. Approval (human-in-the-loop) — the server opens the TronLink approval page; the user reviews "Send 5 TRX → TJRabc…xyz (Nile)" and clicks Approve. Clicking Reject returns USER_REJECTED (not retryable).

4. MCP tool → agent (result)

{
  "txId": "0a1b2c...",
  "status": "success"
}

5. Agent → user

"Sent 5 TRX — confirmed on-chain (tx 0a1b2c…)."

Branch on status / error.code, never on prose. status: "pending" means the broadcast succeeded but confirmation timed out — reconcile with get_balance or an explorer lookup rather than resending (see Errors).

Cancellation

All signing tools support MCP cancellation. If the AI client cancels a pending tool call (e.g., user presses Ctrl+C in Claude Code), the in-flight request is automatically aborted and the browser approval page is not opened for already-cancelled requests.

Transaction Confirmation

When sign_transaction is called with broadcast: true, the server automatically polls for on-chain confirmation after broadcast and returns the execution status (success or pending). If the transaction fails on-chain (e.g., OUT_OF_ENERGY, Solidity revert), the error is returned to the AI agent with a decoded reason.

Errors

The server returns errors in the standard MCP shape. Each error carries a stable code and a retryable hint so an agent can branch without parsing prose. Framework-level codes follow the SSOT table in TronLink MCP Core — Error Codes. Server-specific conditions are:

Retry policy. Read calls (get_balance) and pre-sign failures (USER_REJECTED, INVALID_INPUT, CANCELLED) are agent-safe to re-issue with corrected input. For any sign + broadcast path, treat the outcome as unknown the moment the request leaves the server — confirm with get_balance or an explorer lookup before re-issuing.

Security Boundaries

Environment Variables

Version & License

• Package: mcp-tronlink-signer v0.1.4
• License: MIT — SPDX-License-Identifier: MIT
• Changelog / releases: https://github.com/TronLink/mcp-tronlink-signer/releases

Inline changelog

This page mirrors a downstream README; for the source of truth see the GitHub releases above and the CHANGELOG.md in each package. Entries below cover the MCP-visible surface (tools, schema, security boundaries) — internal refactors are omitted.

v0.1.4 (npm-only, not GitHub-tagged at time of writing)

Patch-only. No new tools, no breaking input/output shapes. Verify against list_tools after upgrade.

v0.1.3 (npm-only, not GitHub-tagged at time of writing)

Patch-only. No new tools, no breaking input/output shapes.

v0.1.2 — 2026-04-15

Co-released with tronlink-signer@0.1.2. Major UX overhaul on the approval flow; no breaking MCP tool schemas.

• New — sign_transaction accepts broadcast: true to sign and broadcast in one step (was sign-only previously).
• New — connect_wallet auto-completes when the wallet is already connected; no extra approval round-trip.
• New — Transaction parsing: TRX transfer, TRC10, TRC20, TRC721 NFT, stake/unstake, delegate, vote, etc. are rendered in human-readable form on the approval page.
• Improved — Single-page approval flow: one persistent browser tab with heartbeat-based liveness; stale tabs across server restarts are invalidated automatically.
• Improved — TRC20 amount validation now uses BigInt-based decimal conversion (handles 0-decimal and >18-decimal edge cases).
• Improved — send_trx and sign_transaction return real broadcast errors instead of empty messages on submission failure.
• Migration — None required if you were already branching on error.code / status; if you parsed message prose, switch now (see Errors).

v0.1.1 — 2026-04-15

• Initial npm release of tronlink-signer@0.1.1 + mcp-tronlink-signer@0.1.1.
• Per-package README with usage instructions and API documentation.
• npm package metadata (keywords, repository, license, files).
• Copyright notice added to LICENSE.

Compatibility & migration policy

• Semver. Pre-1.0: a minor bump (0.x → 0.y) may introduce breaking changes; a patch bump (0.1.x → 0.1.y) will not change MCP tool names, input schemas, or error.code values. Post-1.0: standard semver — major-only breaking changes.
• Deprecation window. When a tool or input field is deprecated, the next minor release retains the old form alongside the new one for at least one minor cycle, with a meta.deprecated flag in the schema; removal lands no earlier than the cycle after that.
• Stable contracts. Tool names, the error.code enum, and status values (success / pending) are part of the public surface — they don't change in a patch.
• Volatile contracts. Prose message text, log line formats, and the layout of the browser approval page are not part of the public surface and may change at any time.
• Verifying after upgrade. Re-call list_tools and confirm the names + schemas you depend on are still present before resuming a workflow.