Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.tronsave/mcp

REMOTE · MCP.TRONSAVE.IO · 2 COMPONENTS · SCANNED SEP 24

Buy, sell & extend TRON ENERGY/BANDWIDTH on the TronSave market via typed MCP tools.

0 this week 78 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security60
Transport & Reachability100
Schema Quality & AI Usability67
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 6393 tokens (~220/item across 29 items; 29 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
  • No destabilizing schema changes in the last 30 days.Pass
Tool Coverage98
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 92% of tool parameters carry a description.Partial
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
  • An AI judge read all 30 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the io.github.tronsave/mcp server?

io.github.tronsave/mcp is a hosted endpoint at https://mcp.tronsave.io/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · mcp.tronsave.io

# add to Claude Code
claude mcp add --transport http tronsave-mcp 'https://mcp.tronsave.io/mcp'
// .cursor/mcp.json
{
  "mcpServers": {
    "tronsave-mcp": {
      "url": "https://mcp.tronsave.io/mcp"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "tronsave-mcp": {
      "type": "http",
      "url": "https://mcp.tronsave.io/mcp"
    }
  }
}
# ~/.codex/config.toml
[mcp_servers.tronsave-mcp]
url = "https://mcp.tronsave.io/mcp"
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "tronsave-mcp": {
      "type": "remote",
      "url": "https://mcp.tronsave.io/mcp",
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add tronsave-mcp --url 'https://mcp.tronsave.io/mcp' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  tronsave-mcp:
    url: "https://mcp.tronsave.io/mcp"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "tronsave-mcp": {
      "Transport": "http",
      "Url": "https://mcp.tronsave.io/mcp"
    }
  }
}
# add to Vellum
assistant mcp add tronsave-mcp -t streamable-http -u 'https://mcp.tronsave.io/mcp'
// mcp.json
{
  "mcpServers": {
    "tronsave-mcp": {
      "type": "http",
      "url": "https://mcp.tronsave.io/mcp"
    }
  }
}

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 26 Aug 26 78
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 25 Aug 26 0
    • Stability: 0.97 → pass security
  • 11 Aug 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 31 Jul 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 30 Jul 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 27 Jul 26 0
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 26 Jul 26 0

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 24 Sept 2026 · Probed https://mcp.tronsave.io/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=tronsave.io CN=WE1,O=Google Trust Services,C=US 24 Aug 2026 22 Nov 2026 ECDSA 256 ECDSA-SHA256 8f832213bc40310313fba0529b5a8200
SANs: tronsave.io, *.tronsave.io
CN=WE1,O=Google Trust Services,C=US (CA) CN=GTS Root R4,O=Google Trust Services LLC,C=US 13 Dec 2023 20 Feb 2029 ECDSA 256 ECDSA-SHA384 7ff31977972c224a76155d13b6d685e3
CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE 15 Nov 2023 28 Jan 2028 ECDSA 384 SHA256-RSA 7fe530bf331343bedd821610493d8a1b

Background: What to check on a remote MCP endpoint →

DNSSEC secure

Validation of mcp.tronsave.io. — Secure

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
io. present 57355 8 Verified
tronsave.io. present 2371 13 Verified
mcp.tronsave.io. Verified address RRset verified with the apex keys
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200
Header Value
content-security-policy default-src 'self' http: https: ws: wss: data: blob: 'unsafe-inline'; frame-ancestors 'self';
x-content-type-options nosniff
referrer-policy no-referrer-when-downgrade
permissions-policy interest-cohort=()

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://mcp.tronsave.io/mcp Verified 200
http (plaintext) http://mcp.tronsave.io/mcp HTTPS enforced 301 https://mcp.tronsave.io/mcp
MCP tools · 29 exposed · ~6,076 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
tronsave_cancel_order ~164

Cancel an open order by `orderId`. Returns the cancelled order payload after the status flip. Side effect: marks the order non-matchable and refunds locked balance per backend rules; effectively destructive on the live order. Idempotent — cancelling an already-cancelled order is a no-op success. Fails for fulfilled orders or unauthorized callers. Requires a signature session and `mcp-session-id`. Verify state with `tronsave_get_order` first; prefer `tronsave_update_order` when only price/receiver should change.

NameTypeReqDescription
orderIdstringyesTarget order id (`MObjectId`) to cancel. Must be an active order owned/authorized by the current session; already-fulfilled or already-cancelled orders are expected to fail.
NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

tronsave_create_order ~522

Create a new buy order on the TronSave market. Key inputs: `orderResourceType` (ENERGY|BANDWIDTH), `orderReceiver` (TRON base58), `orderUnitPrice` in SUN (NOT TRX), `orderDurationSec`, `orderResourceAmount`, and `paymentMethod`: (1) `onchain` — requires a signed payment tx in `paymentSignedTx`; (2) `internal` — deducts from internal balance. Side effect: creates a live order matchable by the market. Requires a signature session and `mcp-session-id`. Always derive `orderUnitPrice` and `paymentPaymentAmount` from the latest `tronsave_estimate_buy_resource` for the same receiver, amount, and duration to avoid reverts. FRESHNESS: re-quote immediately before submitting — estimates older than a few seconds (one TRON block ≈ 3s) may be stale and cause the order to revert or fill at the wrong price.

NameTypeReqDescription
orderDurationSecnumberyesDelegation duration in seconds. Must match the `durationSec` used in `tronsave_estimate_buy_resource`.
orderReceiverstringyesTRON base58 address (starts with T) that receives delegated resource. Same as `receiver` passed to `tronsave_estimate_buy_resource`.
orderResourceAmountnumberyesAmount of ENERGY or BANDWIDTH units to purchase. Same as `buyResourceAmount` in estimate when applicable.
orderResourceTypestringyesResource to buy: ENERGY (smart contracts) or BANDWIDTH (transactions). Must match `tronsave_estimate_buy_resource`.
orderUnitPricenumberyesUnit price in SUN. Prefer aligning with `minResourcePrice` or `buyResourcePrice` from the latest `tronsave_estimate_buy_resource` for the same receiver, amount, and duration.
paymentMethodstringyesPayment method for this order: `onchain` (wallet signed tx) or `internal` (internal balance).
paymentPaymentAmountnumberyesPayment amount in SUN. Prefer deriving from `tronsave_estimate_buy_resource`; if converting to TRX, divide SUN by `1e6`.
paymentSignedTxobject–Required when `paymentMethod=onchain`. TronWeb-shaped signed TRON transaction (`{ txID, raw_data, raw_data_hex, signature[] }`). Must be produced client-side by the user's wallet; never fabricate or…
NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
data–––
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

tronsave_delete_auto_buy_setting ~118

Permanently delete one auto-buy rule by `id` (`MObjectId`). Side effect: stops all future executions matching that rule; the rule cannot be restored. Idempotent — deleting a non-existent or already-removed id returns success. Requires a signature session and `mcp-session-id`. Use `tronsave_get_user_auto_setting` to list current rules first; prefer disabling/updating instead when reversibility is desired.

NameTypeReqDescription
idstringyesAuto-buy setting id (`MObjectId`) to delete.
NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

tronsave_estimate_buy_resource ~288

Quote price and availability for buying ENERGY or BANDWIDTH for a receiver address before placing an order. Returns estimated `unitPrice` (SUN per resource unit), `paymentAmount`, and availability fields used to populate `tronsave_create_order` inputs (`orderUnitPrice`, `paymentPaymentAmount`). Read-only and safe to call repeatedly; no session is required, but backend rate limits apply. FRESHNESS: this is live market data — `unitPrice`/availability can change roughly every 3 seconds (one TRON block). Re-run this estimate immediately before `tronsave_create_order` and never reuse a quote more than a few seconds old. For order-book depth use `tronsave_list_order_books`; for the minimum unit price only use `tronsave_get_min_price`.

NameTypeReqDescription
allowPartialFillboolean–Allow partial fill of the order.
buyResourceAmountnumber–Amount of resource to buy. Default 100000 for ENERGY and 1000 for BANDWIDTH
durationSecnumber–Duration of the order in seconds. Default 15 minutes
minResourceDelegateRequiredAmountnumber–Minimum amount of resource to delegate.
receiverstring–receiver address.
resourceTypestring–Resource type to buy. Default ENERGY
unitPricenumber–Unit price in SUN.
NameTypeReqDescription
availableResourcenumberyesAvailable resource amount
durationSecnumberyesDelegated duration in seconds
estimateTrxnumberyesEstimated TRX cost in SUN
systemDepositAddressstringyesSystem deposit address for onchain payment
unitPricenumberyesUnit price in SUN

No examples provided.

tronsave_generate_api_key ~129

Generate a new internal API key credential for the current user. Returns `data` containing the issued key — store it securely and pass it to `tronsave_login` (`apiKey` mode) for internal-tool access. Side effect: issues secret material; not idempotent — each call mints a fresh key. If a previous key existed, treat it as rotated and stop using the old key once the new one is wired up. Requires a signature session and `mcp-session-id`. Sensitive output — never log raw keys; unauthorized sessions or policy checks may reject issuance.

Input schema present but exposes no named parameters.

NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
datastringyesFor `generateApiKey`: the freshly issued internal API key — treat as SECRET, store securely. For `revokeApiKey`: server-defined confirmation string (no key material).
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

tronsave_get_deposit_address ~165

Fetches the specific deposit address for the TronSave internal account. Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Trigger this tool if the user asks for a deposit address or needs to top up their TronSave TRX balance. Constraints: 1) TRX only; 2) Minimum deposit amount is 10 TRX; 3) Read-only operation.

NameTypeReqDescription
amountTrxnumberyesAmount of TRX to deposit
NameTypeReqDescription
amountTrxnumberyesAmount of TRX to deposit
depositAddressstringyesTRON base58 deposit address, used for deposit TRX to TronSave internal account

No examples provided.

tronsave_get_internal_account ~167

Retrieve the TronSave internal account profile for the current session: represent address, deposit address, and balance (SUN). Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Use when the user needs their linked address, deposit address, or internal balance. This is the api-key internal account, not the on-chain wallet. Read-only; does not submit orders or change chain state. FRESHNESS: balance reflects live state and can change within seconds after deposits/orders.

Input schema present but exposes no named parameters.

NameTypeReqDescription
balancestring–Account balance in SUN (string).
depositAddressstring–TRON base58 deposit address for funding the internal balance.
idstring––
representAddressstring–TRON base58 represent address (used as order requester).

No examples provided.

tronsave_get_min_price ~283

Quote the minimum unit price for a buy. Returns `{ minPrice }` (SUN per resource unit) from GraphQL `market.estimateMinPrice` for the given `resourceType`, `buyAmount`, and `durationSec`. Optional `address` scopes context when the API supports it. No login required; an optional session forwards auth like `tronsave_list_order_books`. Read-only and idempotent. FRESHNESS: live market data — `minPrice` can change roughly every 3 seconds; re-fetch right before placing an order and do not reuse a stale value. Pair with `tronsave_estimate_buy_resource` for full buy quotes and `tronsave_list_order_books` for depth buckets.

NameTypeReqDescription
addressstring–Optional TRON base58 address (`TronAddress`). When omitted, the server uses anonymous/global market context.
buyAmountnumber–Resource amount to price (same units as order book / delegate amounts for that resource type). Default 100000 for ENERGY and 1000 for BANDWIDTH
durationSecnumber–Delegation window in seconds; must match the duration you plan to use on a real order for comparable quotes. Default 15 minutes
resourceTypestring–Market leg: `ENERGY` or `BANDWIDTH`. Default ENERGY
NameTypeReqDescription
minPricenumberyesEstimated minimum unit price in SUN for the given `resourceType`, `buyAmount`, and `durationSec`; align with `tronsave_estimate_buy_resource` and order `unitPrice` conventions (same as GraphQL `marke…

No examples provided.

tronsave_get_order ~153

Read one order by `id` and return its full snapshot for NORMAL, FAST, or EXTEND order types. Use this as the source of truth before `tronsave_update_order`, `tronsave_sell_order_manual`, or `tronsave_cancel_order` to avoid acting on stale state. FRESHNESS: order state can change within seconds as the market matches — re-read immediately before each mutation instead of reusing an earlier snapshot. Requires a signature session and `mcp-session-id`. Read-only and idempotent.

NameTypeReqDescription
idstringyesTarget order id (`MObjectId`) to inspect. Use this to confirm current status/price before update, sell, or cancel actions.
NameTypeReqDescription
order–yes–

No examples provided.

tronsave_get_sign_message ~90

Issue a wallet-signable timestamp message helper for signature login. Returns `{ message, timestamp }`: sign `message` exactly client-side, then submit `<signature>_<timestamp>` to `tronsave_login` (signature mode). Optional helper only — clients may also sign their own timestamp payload directly as long as it matches the `signature_timestamp` format expected by `tronsave_login`.

Input schema present but exposes no named parameters.

NameTypeReqDescription
messagestringyesHex-encoded nonce message to sign client-side with the user's TRON wallet. The signature must be produced over THIS exact message (case-sensitive).
timestampintegeryesUnix epoch seconds corresponding to `message`. Pair it with the wallet signature in `<signature>_<timestamp>` form when calling `tronsave_login` (signature mode). This endpoint is a convenience helpe…

No examples provided.

tronsave_get_user_auto_setting ~85

Read the current user's auto-sell configuration (`autoSettings`). Returns the full `autoSettings` object — call this before `tronsave_register_auto_sell` or `tronsave_update_auto_sell_setting` to avoid overwriting fields you do not intend to change. Requires a signature session and `mcp-session-id`. Read-only and idempotent.

Input schema present but exposes no named parameters.

NameTypeReqDescription
bandwidth––Bandwidth auto-sell pool snapshot; null when bandwidth automation is disabled.
energy––Energy auto-sell pool snapshot; null when energy automation is disabled.
permitOperations––Permission rows enabled for this user; null/empty when no automation has been configured.
reclaimOnlyTronSave––Reclaim flag — when `true`, only TronSave-managed delegations are reclaimed automatically.
suggestSell––Whether suggest-sell UX hints are enabled.
vote––Whether vote-related automation is enabled for the wallet.
withdrawVote––Withdraw-vote configuration as a backend-defined string; semantics from TronSave docs.

No examples provided.

tronsave_get_user_info ~135

Read the current authenticated user's profile and linked TronSave internal account. Returns `{ caller, address, balance (SUN string), info, internalAccount }` — `info` carries referral/contact metadata and may be null; `internalAccount` is null when the wallet has not provisioned a TronSave internal balance yet. Requires a signature session from `tronsave_login` and `mcp-session-id`. Read-only and idempotent. Use `tronsave_get_user_auto_setting` for the auto-sell config or `tronsave_get_user_permissions` for permission flags when the full profile is unnecessary.

Input schema present but exposes no named parameters.

NameTypeReqDescription
addressstringyesTRON base58 address
balancestringyesAmount in SUN, onchain balance of the address
callerstringyesTRON base58 address of the caller
info–yes–
internalAccount–yes–

No examples provided.

tronsave_get_user_permissions ~79

Read the enabled permission operations (`autoSettings.permitOperations`) for the authenticated user. Returns `{ permitOperations: string[] }` — use it before mutating auto-sell or auto-buy rules to confirm the action is allowed for the wallet. Requires a signature session and `mcp-session-id`. Read-only and idempotent.

Input schema present but exposes no named parameters.

NameTypeReqDescription
permitOperationsarrayyesPermission rows enabled for this user; defaults to `[]` when nothing is configured.

No examples provided.

tronsave_internal_create_extend_request ~222

Submit an extension request for existing delegated resources on TronSave, paid from the internal account. Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Side effect: SPENDS internal TRX and creates an extension order; not idempotent. Use as STEP 2 after `tronsave_internal_extend_delegates` — pass its `extendData` rows unchanged. Returns `{ orderId }` for the new extension order.

NameTypeReqDescription
extendDataarrayyesRows copied from `extendData` returned by `tronsave_internal_extend_delegates`.
receiverstringyesTRON base58 address of the account that receives the delegated resource.
resourceTypestring–Resource type. Default ENERGY when omitted.
NameTypeReqDescription
orderIdstring–TronSave order ID (hex string) of the created/extension order.

No examples provided.

tronsave_internal_extend_delegates ~265

Return extendable delegations for a receiver plus an `extendData` payload for the extension flow. Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Use as STEP 1 before `tronsave_internal_create_extend_request` when the user wants to extend existing delegation time. Read-only; does not submit anything. FRESHNESS: pricing/availability change within seconds — run immediately before extending and pass the returned `extendData` unchanged.

NameTypeReqDescription
extendTointegeryesTarget end time as Unix epoch milliseconds (UTC) for the extended delegation.
maxPriceAcceptednumber–Maximum unit price in SUN you are willing to pay for the extension.
receiverstringyesTRON base58 address of the account that receives the delegated resource.
requesterstring–TRON base58 requester; defaults to the API key account when omitted.
resourceTypestring–Resource type. Default ENERGY when omitted.
NameTypeReqDescription
extendData––Delegations to extend; pass unchanged into internal_create_extend_request `extendData`.
extendOrderBookarray–Order book for extend.
isAbleToExtendboolean–Whether balance is sufficient to extend.
totalAvailableExtendAmountnumber–Total available amount to extend.
totalDelegateAmountnumber–Total delegated resource amount.
totalEstimateTrxnumber–Total estimated TRX cost in SUN.
yourBalancenumber–Current account balance in SUN.

No examples provided.

tronsave_internal_order_book ~240

Return the current TronSave market depth/price tiers for ENERGY or BANDWIDTH via the api-key REST endpoint. Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Use before `tronsave_internal_order_create` or `tronsave_internal_order_estimate` when the user needs live prices or liquidity. Read-only. FRESHNESS: live market depth can change roughly every 3 seconds (one TRON block) — re-read immediately before placing an order.

NameTypeReqDescription
addressstring–Optional TRON base58 address filter for the receiver.
durationSecinteger–Delegation duration window in seconds for the quote.
minDelegateAmountnumber–Minimum resource amount per offer level to include (resource units, not SUN).
resourceTypestring–Resource type. Default ENERGY when omitted.
NameTypeReqDescription
availableResourcenumber–Available resource at the quoted tiers.
dataarray–Order book entries sorted by price.
fastnumber–FAST price tier (SUN).
mediumnumber–MEDIUM price tier (SUN).
slownumber–SLOW price tier (SUN).

No examples provided.

tronsave_internal_order_create ~328

Place a new buy order for ENERGY or BANDWIDTH on TronSave, paid from the internal account balance. Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Side effect: SPENDS internal TRX balance and creates a live order; not idempotent — each call places a new order. This is the api-key/internal path; for the signature-session market path use `tronsave_create_order`. Always derive `unitPrice` from the latest `tronsave_internal_order_estimate` (re-estimate immediately before submitting — quotes older than a few seconds may be stale and revert). Returns `{ orderId }`.

NameTypeReqDescription
durationSecinteger–Delegation duration in seconds. Default 259200 (3 days) when omitted.
optionsobject–Optional execution guards and fill behavior.
receiverstringyesTRON base58 address that will receive the resource.
resourceAmountnumberyesAmount of resource to purchase (resource units).
resourceTypestring–Resource type. Default ENERGY when omitted.
sponsorstring–Optional sponsor or referral code.
unitPrice––Pricing: FAST | MEDIUM | SLOW strategy, or exact unit price in SUN per resource unit. Default MEDIUM when omitted.
NameTypeReqDescription
orderIdstring–TronSave order ID (hex string) of the created/extension order.

No examples provided.

tronsave_internal_order_details ~175

Fetch full details for one internal-account order by order ID. Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Use when monitoring fulfillment after `tronsave_internal_order_create`, or when the user asks for status on a specific order id. Read-only. FRESHNESS: order state changes within seconds as the market matches — re-read immediately before acting.

NameTypeReqDescription
orderIdstringyesTronSave order ID (hex string), e.g. value returned in internal.order.create response data.orderId.
NameTypeReqDescription
allowPartialFillboolean–Whether partial fill is allowed.
createdAt––Order created time (Unix epoch ms or ISO-8601, endpoint-dependent).
delegatesarray–Delegations fulfilling this order.
durationSecnumber–Delegated duration in seconds.
fulfilledPercentnumber–0 = pending, 1-99 = partial, 100 = fully matched.
idstring–TronSave order ID (hex string).
orderTypestring–Order type (NORMAL | FAST | EXTEND).
payoutAmountnumber–Payout amount in SUN.
pricenumber–Unit price in SUN.
receiverstring–TRON base58 receiver address.
remainAmountnumber–Remaining unfulfilled amount.
requesterstring–TRON base58 requester address.
resourceAmountnumber–Resource amount of order.
resourceTypestring–Resource type.
statusstring–Order status.

No examples provided.

tronsave_internal_order_estimate ~307

Estimate the TRX cost and availability for a buy order before submitting it (api-key internal account). Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Use when the user wants a quote or price check; feed the result into `tronsave_internal_order_create`. Read-only. FRESHNESS: `unitPrice`/`estimateTrx` are live and can change roughly every 3 seconds — re-estimate immediately before creating the order.

NameTypeReqDescription
durationSecinteger–Delegation duration in seconds. Default 259200 (3 days) when omitted.
optionsobject–Optional flags that affect matching behavior for the estimate.
receiverstring–TRON base58 address that will receive the resource.
requesterstring–TRON base58 requester; defaults to the API key account when omitted.
resourceAmountnumberyesAmount of resource to purchase (resource units).
resourceTypestring–Resource type. Default ENERGY when omitted.
unitPrice––Pricing: FAST | MEDIUM | SLOW strategy, or exact unit price in SUN per resource unit. Default MEDIUM when omitted.
NameTypeReqDescription
availableResourcenumber–Available resource amount.
durationSecnumber–Delegated duration in seconds.
estimateTrxnumber–Estimated TRX cost in SUN.
unitPricenumber–Unit price in SUN.

No examples provided.

tronsave_internal_order_history ~191

List paginated order history for the internal account linked to the API key, newest first. Requires a logged-in MCP session created by the `tronsave_login` tool: include `mcp-session-id: <sessionId>` returned by `tronsave_login` on subsequent MCP requests. Internal tools never accept API keys via tool arguments; signature sessions resolve the latest internal API key on demand, while api-key sessions reuse the validated key from login. Use when the user asks about past purchases, fulfillment, payouts, or delegates on their internal account. Read-only. Pair with `tronsave_internal_order_details` for a single order's full snapshot.

NameTypeReqDescription
pageinteger–Page index, 0-based. Omit for first page (default 0).
pageSizeinteger–Orders per page. Default 10 when omitted. Typical range 1–100.
NameTypeReqDescription
dataarray–Orders on this page, newest first.
totalnumber–Total orders matching the query (for pagination).

No examples provided.

tronsave_list_extendable_delegates ~333

List extendable delegate candidates for a `receiver` and `resourceType` (ENERGY|BANDWIDTH). Optional `suggestData` scores an extend-and-buy scenario for planning purposes. Read-only; does NOT create orders or change on-chain state. Works without `mcp-session-id`; when a session is present, auth is forwarded so results can reflect the logged-in account where supported. NOTE: this is GraphQL market data for discovery only. To actually submit an extension, call the authenticated REST `POST /v2/get-extendable-delegates` with `extendData` (payload shape differs from this GraphQL response).

NameTypeReqDescription
receiverstringyesTRON base58 address (typically starts with `T`) that currently receives or will receive the delegated resource. This is the primary filter: the response describes delegates relevant to extending that…
requesterstring–Optional TRON base58 address of the viewing/requesting party. When an MCP session is active, the server may still derive identity from auth headers; use this when the API expects an explicit requeste…
resourceTypestringyesWhich resource market leg to query: `ENERGY` for contract execution headroom, `BANDWIDTH` for transaction bandwidth. Must match how you plan to extend or buy.
suggestDataobject–Optional nested scenario for extend-and-buy suggestion scoring. If omitted, the query returns delegate rows without that hypothetical. If provided, supply all four fields together; partial objects ar…
NameTypeReqDescription
extendableDelegates–yesNull when the market has no payload or GraphQL returned no branch; check tool-level errors for hard failures.

No examples provided.

tronsave_list_order_books ~195

Read market depth buckets for `ENERGY` or `BANDWIDTH`. Returns price buckets `{ min, max, value }` optionally scoped by viewer address, minimum delegate amount, and duration. No login required; read-only and idempotent. FRESHNESS: live market depth — buckets can shift roughly every 3 seconds; re-read immediately before acting on a price. Use this to estimate market ranges before create/update decisions; pair with `tronsave_estimate_buy_resource` for quote-style buy estimation and `tronsave_get_order` for one concrete order.

NameTypeReqDescription
addressstring–Optional viewer/requester wallet context.
durationSecnumber–Optional delegation duration filter in seconds.
minDelegateAmountnumber–Optional minimum delegate amount floor for bucket filtering.
resourceTypestringyesOrder-book side to query (`ENERGY` or `BANDWIDTH`).
NameTypeReqDescription
orderBookarrayyes–

No examples provided.

tronsave_list_orders ~362

Query the order list with paging. Returns `{ orders: [{ id, requester?.address, receiver.address, resourceType, resourceAmount, remainAmount, durationSec, unitPrice (SUN), isOwner, isMatching, apy, createdAt, typeOrder (NORMAL|FAST|EXTEND) }] }`. Filter `status` maps to GraphQL `isFulfilled`: `ACTIVE` → `UNFULFILLED`, `COMPLETED` → `FULFILLED`. Set `onlyMyOrder=true` (requires signature login + `mcp-session-id`) to scope to the caller's wallet as requester. Paging uses `offset`/`limit`. Use `tronsave_get_order` with an `id` for one full snapshot before mutating an order.

NameTypeReqDescription
isOnlyMyOrderboolean–When `true`, only orders whose `requester` is the wallet from the signature session; include `mcp-session-id`. Api-key-only sessions have no wallet address and cannot use this filter. When `false` or…
limitinteger–Maximum rows to return in one call. Prefer modest limits to avoid huge payloads; page with `offset`.
offsetinteger–Zero-based row offset for page N (skip first `offset` matches). Omit when starting from the first page.
resourceTypestring–Restrict to `ENERGY` or `BANDWIDTH` orders; omit for both.
statusstring–Lifecycle filter mapped to GraphQL `isFulfilled`: `ACTIVE` → `UNFULFILLED` (not yet fulfilled), `COMPLETED` → `FULFILLED`.
NameTypeReqDescription
ordersarrayyesMatching orders for this page; may be large—use pagination inputs to chunk.

No examples provided.

tronsave_login ~244

Authenticate with TronSave and create a server session. Returns `{ sessionId, walletAddress?, expiresAt }` — pass `sessionId` as the `mcp-session-id` header on every subsequent MCP request. `walletAddress` is set only for signature-mode logins. Two modes: (1) wallet signature (preferred for platform tools) — call this tool with `signature_timestamp` formatted as `<signature>_<timestamp>`, where `<signature>` must be produced client-side by signing the timestamp message; you may optionally call `tronsave_get_sign_message` to obtain a helper message/timestamp pair; (2) API key (internal tools) — pass `apiKey` (raw key, no prefix). Side effect: creates a new session on the server. Wallet signing must happen client-side; never send private keys to the server.

NameTypeReqDescription
apiKeystring–Raw API key for internal-tools login. Provide EXACTLY ONE of `apiKey` or `signature`.
signaturestring–Signature token in `signature_timestamp` format (timestamp is the signed message). Provide EXACTLY ONE of `apiKey` or `signature`.
NameTypeReqDescription
expiresAtstringyes–
sessionIdstringyesSession id to pass as mcp-session-id in subsequent calls.
walletAddressstring––

No examples provided.

tronsave_register_auto_sell ~154

Create the initial auto-sell configuration for the authenticated user. Returns the persisted `autoSettings` payload. Side effect: persists automation settings that affect future delegation/sell behavior; not idempotent — calling twice may reset fields. Requires a signature session and `mcp-session-id`. Use for FIRST-TIME setup only; for subsequent edits use `tronsave_update_auto_sell_setting`, and always read the current state with `tronsave_get_user_auto_setting` first to avoid overwriting unknown fields. Fails for invalid config combinations, unauthorized sessions, or backend policy restrictions.

NameTypeReqDescription
addOnFeatureobject––
paymentConfigobject––
poolSettingobject––
NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
datastringyesOpaque server-defined payload (tx id, setting id, or status text). Treat as identifier-or-message; rely on `message` for human routing.
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

tronsave_revoke_api_key ~115

Revoke the caller's current internal API key. Side effect: any future request using the previous key is rejected. Existing in-flight sessions cached by the server may continue serving until their TTL expires — treat the effect as 'best-effort immediate' rather than guaranteed instantaneous cutoff. Idempotent — revoking an already-revoked key returns success. Requires a signature session and `mcp-session-id`. Call `tronsave_generate_api_key` afterwards to mint a replacement when continued internal access is needed.

Input schema present but exposes no named parameters.

NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
datastringyesFor `generateApiKey`: the freshly issued internal API key — treat as SECRET, store securely. For `revokeApiKey`: server-defined confirmation string (no key material).
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

tronsave_sell_order_manual ~220

Manually execute seller-side fulfillment of an existing order with a wallet `signedTx`. Returns the updated order payload after sell. Side effect: broadcasts a market/delegation transaction and may consume balances/resources; not idempotent — each call re-executes. Backend requires a signature session and `mcp-session-id`; the MCP gate is `public` to allow anonymous read-fallthrough, but the GraphQL helper rejects api-key-only sessions. Use only when explicit manual sell is intended; call `tronsave_get_order` first to verify order state before signing.

NameTypeReqDescription
orderIdstringyesTarget order id (`MObjectId`) to manually fulfill. Should be an order eligible for seller-side manual execution.
paymentAddressstring–Optional payout/payment address override when settlement flow requires it.
signedTxobjectyesRequired wallet-signed transaction payload (TronWeb shape: `{ txID, raw_data, raw_data_hex, signature[] }`). Must come from client-side signing; never fabricate.
NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
delegatedId––On-chain delegate id created by the manual sell when the underlying transaction is confirmed; null until confirmation lands.
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

tronsave_update_auto_sell_setting ~148

Update the existing auto-sell configuration with partial fields. Returns the updated `autoSettings` payload. Side effect: overwrites stored automation settings for the current user; not idempotent across different field sets. Requires a signature session and `mcp-session-id`. Use for INCREMENTAL changes after registration; read the baseline via `tronsave_get_user_auto_setting` to avoid accidental resets, and use `tronsave_register_auto_sell` only for first-time setup. Fails for invalid field combinations, unauthorized sessions, or policy constraints.

NameTypeReqDescription
addOnFeatureobject––
paymentConfigobject––
poolSettingobject––
NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
datastringyesOpaque server-defined payload (tx id, setting id, or status text). Treat as identifier-or-message; rely on `message` for human routing.
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

tronsave_update_order ~199

Update an open order by `orderId` with partial fields (`receiver`, `newPrice`). Returns the updated order payload. Side effect: overwrites live order parameters; not idempotent — each call with a different `newPrice` produces a new state. Backend requires a signature session and `mcp-session-id`; the MCP gate is `public` to allow anonymous read-fallthrough, but the GraphQL helper rejects api-key-only sessions. Prefer this over cancel+recreate when only price/receiver should change. Verify state with `tronsave_get_order` first; fails for already-fulfilled, already-cancelled, or non-editable orders.

NameTypeReqDescription
newPricenumber–Optional replacement unit price in SUN.
orderIdstringyesTarget order id (`MObjectId`) to update. Order must still be open and editable.
receiverstring–Optional replacement receiver TRON address.
NameTypeReqDescription
codeintegeryesGraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
messagestringyesHuman-readable status text. Populated even on success; localized error messages may appear here on failure.
successbooleanyesWhether the mutation succeeded at the backend level. Always check this before reading `data`.

No examples provided.

Common questions

What is the io.github.tronsave/mcp server?

io.github.tronsave/mcp is listed in the public MCP registry as io.github.tronsave/mcp. Buy, sell & extend TRON ENERGY/BANDWIDTH on the TronSave market via typed MCP tools. This page covers its hosted endpoint (https://mcp.tronsave.io/mcp).

Is the io.github.tronsave/mcp server safe to use?

io.github.tronsave/mcp scores 78 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.github.tronsave/mcp server expose?

io.github.tronsave/mcp exposes 29 tools: tronsave_get_internal_account, tronsave_get_deposit_address, tronsave_internal_order_history, tronsave_internal_order_details, tronsave_internal_order_book, and 24 more. Their descriptions and schemas cost roughly 6,076 tokens of context every time the server is loaded.

Does the io.github.tronsave/mcp server require authentication?

No. We connected to io.github.tronsave/mcp without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the io.github.tronsave/mcp server still maintained?

io.github.tronsave/mcp is still listed as active in the MCP registry. We last reached this channel on 24 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.