GoTRON MCP

GoTRON MCP Server

MCP server for TRON blockchain — let AI agents query balances, tokens, blocks, and build transactions.

Built on the GoTRON SDK and the Model Context Protocol.

Two Modes

Install

Go Install

go install github.com/fbsobreira/gotron-mcp/cmd/gotron-mcp@latest

Homebrew

brew install fbsobreira/tap/gotron-mcp

curl

curl -fsSL gotron.sh/install-mcp | sh

Docker

docker run -p 8080:8080 ghcr.io/fbsobreira/gotron-mcp

The image starts the HTTP transport. For stdio, append --transport stdio:

docker run -i --rm ghcr.io/fbsobreira/gotron-mcp --transport stdio

MCP Registry

Published to the MCP Registry as io.github.fbsobreira/gotron-mcp on each stable release tag (vX.Y.Z), from v0.4.1, with the Docker image (stdio) and the hosted endpoint.

Hosted (zero install)

Connect directly to https://mcp.gotron.sh/mcp — no installation needed.

Claude Code plugin

The gotron plugin bundles the hosted server with skills for USDT transfers and energy estimates. The gotron-local plugin runs the gotron-mcp binary locally and supports keystore signing.

Public marketplace installation is not available yet. To connect today, use the Claude Code MCP setup below. Plugin source and configuration details are in the directories linked above.

Claude Desktop Configuration

Local mode

{

"mcpServers": { "gotron": { "command": "gotron-mcp", "args": ["--network", "mainnet"], "env": { "GOTRON_NODE_API_KEY": "your-trongrid-api-key" } } } }

Local mode with keystore signing

{

"mcpServers": { "gotron": { "command": "gotron-mcp", "args": ["--network", "mainnet"], "env": { "GOTRON_NODE_API_KEY": "your-trongrid-api-key", "GOTRON_MCP_KEYSTORE_PASSPHRASE": "your-keystore-passphrase" } } } }

Hosted mode (zero install)

{

"mcpServers": { "gotron": { "url": "https://mcp.gotron.sh/mcp" } } }

Claude Code

Choose one of the following setup options.

Project-wide local server:

claude mcp add gotron --scope project -- gotron-mcp --network mainnet

User-wide local server with keystore signing:

If a project-scoped gotron entry already exists, remove it first with claude mcp remove gotron --scope project. For a local-scoped entry, use claude mcp remove gotron --scope local. Check the selected entry with claude mcp get gotron: local and project entries take precedence over user entries, and their settings are not combined. See Claude Code's scope precedence.

Save an environment-variable reference rather than the passphrase itself. Keep the single quotes so your shell does not expand the reference while registering the server:

claude mcp add gotron --scope user -e 'GOTRON_MCP_KEYSTORE_PASSPHRASE=${GOTRON_MCP_KEYSTORE_PASSPHRASE:-}' -- gotron-mcp --network mainnet

Then launch Claude from Bash or Zsh with a hidden passphrase prompt:

(

set +x printf 'Keystore passphrase: ' IFS= read -r -s GOTRON_MCP_KEYSTORE_PASSPHRASE || exit 1 printf '\n' export GOTRON_MCP_KEYSTORE_PASSPHRASE claude )

The subshell limits the exported value to that Claude session. The prompt keeps the passphrase out of shell history and command-line arguments; it is still available in the environment of Claude and its MCP server. Repeat the prompt when starting a new signing session. Without a supplied passphrase, the reference expands to an empty value and wallet/signing tools stay disabled.

If you previously registered a literal passphrase with -e, it was stored in plain text in ~/.claude.json and may also remain in shell history. Remove the old user-scoped entry with claude mcp remove gotron --scope user, register it again using the reference above, and remove the old history entry. See Claude Code's environment-variable expansion documentation.

User-wide local server without keystore configuration:

claude mcp add gotron --scope user -- gotron-mcp --network mainnet

Hosted server (zero install):

claude mcp add gotron --scope user --transport http https://mcp.gotron.sh/mcp

Available Tools

Read-Only (both modes)

Transaction Builders (both modes)

Sign & Broadcast (local mode + keystore)

Post-quantum signing (TIP-899, Nile)

create_wallet(name, key_type?) accepts ecdsa (default), ml_dsa_44 or fn_dsa_512; list_wallets and signing results report key_type. sign_transaction, sign_and_broadcast, sign_and_confirm and request_limit_override accept PQ wallets with the same policy limits, Telegram approval and elicitation as ECDSA wallets.

• TIP-899 is a draft, live only on Nile (grpc.nile.trongrid.io:50051); governance switches each scheme on or off and mainnet reports none. Use get_pq_capabilities to check the node and this build.
• Before any policy check or approval, a PQ signature requires that the node has the scheme enabled and that the wallet's address is a key of the transaction's permission (permission_id) on the owner account. A fresh PQ address must receive TRX first.
• PQ keys are stored encrypted with GOTRON_MCP_KEYSTORE_PASSPHRASE under /pq-keys/ / (wallet-cli compatible, same layout as tronctl). Point --keystore-dir at a tronctl config root (e.g. ~/.tronctl) to reuse its keys; the passphrase must match their password. Wallet names are unique across ECDSA and PQ wallets; list_wallets flags duplicate_name: true and such a wallet cannot sign until one copy is renamed.
• The signature goes into pq_auth_sig (txid unchanged); a transaction carries at most 5 signatures, ECDSA and PQ combined. PQ transactions are about 10-22x larger than ECDSA ones (roughly 10x for FN-DSA-512, 22x for ML-DSA-44), so they use more bandwidth.
• ML-DSA-44 is pure Go and works in every build. FN-DSA-512 (Falcon-512, currently enabled on Nile) needs a build with -tags falcon, CGO and liboqs installed via pkg-config: CGO_ENABLED=1 go build -tags falcon ./cmd/gotron-mcp. Without it, FN-DSA create/sign returns an error pointing to the gotron-mcp-pq build; release binaries for it are planned (GOT-97).
• Not supported yet: adding a PQ key to an existing account's permissions from MCP (GOT-98; use tronctl or the SDK guide) and co-signing one transaction with several MCP wallets (GOT-99).

Configuration

Network Presets

Explicit --node overrides network presets.

Contract reads require a node with vm.supportConstant = true. If a node reports that constant execution is unsupported, reads try --fallback-node when configured. TRC20 reads also use the fallback for empty results, since token reads require return data. General contract simulations can succeed without return data. The fallback must serve the same network. This fallback applies per call, independently of block health checks; contract reverts are returned as errors.

For TRX transfers to unactivated recipients, analyze_transfer_cost reads the account creation fees and bandwidth multiplier from chain parameters. Only staked or delegated bandwidth can cover account creation; free bandwidth cannot. If recipient activation or the required fee parameters cannot be determined, the tool returns an error instead of quoting zero.

Security

• The server never stores or manages private keys directly
• All write tools return unsigned transaction hex — the user decides how to sign
• Keystore signing is opt-in: wallet and sign tools are reg