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 an error result Error: USER_REJECTED (do not re-issue without asking the user).

4. MCP tool → agent (result)

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

5. Agent → user

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

Branch on isError and the status field of the JSON result. Errors carry only message text (see Errors). 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, pending, or failed). If the transaction fails on-chain (e.g., OUT_OF_ENERGY, Solidity revert), the result has status: "failed" with the decoded reason in error, and is flagged isError: true.

Errors

In v0.1.4, errors are returned as an MCP tool result with isError: true and a single text item Error: <message>. There is no structured code or retryable field. Known messages:

Retry policy. Read calls (get_balance) are safe to re-issue. A rejection means the user declined — do not re-issue without asking. For send_trx, send_trc20, and sign_transaction with broadcast: true, treat any error (including CANCELLED_BY_CALLER and TIMEOUT) as an unknown outcome — 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; MCP tool schemas are unchanged.

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 or input schemas. 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 and status values (success / pending / failed) are part of the public surface — they don't change in a patch.
• Volatile contracts. Error message text (match the known values under Errors and treat others as unknown), 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.