# io.github.tronsave/mcp (remote · mcp.tronsave.io)

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

- Trust score: 64/100 (medium)
- Change this week: +5
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.tronsave.io`: 65/100, [markdown](https://verifymcp.io/servers/tronsave-mcp/mcp.md), [page](https://verifymcp.io/servers/tronsave-mcp/mcp)
- remote · `mcp.tronsave.io`: 64/100 (this document), [markdown](https://verifymcp.io/servers/tronsave-mcp/testnet-mcp.md), [page](https://verifymcp.io/servers/tronsave-mcp/testnet-mcp)

## Channel facts

- Endpoint: `https://mcp.tronsave.io/testnet/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 60/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (tronsave_sell_order_manual).
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 56/100
  - AI-judged instruction clarity (good).
  - 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.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 92% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http tronsave-mcp https://mcp.tronsave.io/testnet/mcp
```

### Codex

```toml
[mcp_servers.tronsave-mcp]
url = "https://mcp.tronsave.io/testnet/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "tronsave-mcp": {
      "type": "remote",
      "url": "https://mcp.tronsave.io/testnet/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add tronsave-mcp --url https://mcp.tronsave.io/testnet/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  tronsave-mcp:
    url: "https://mcp.tronsave.io/testnet/mcp"
```

### Other

```json
{
  "mcpServers": {
    "tronsave-mcp": {
      "type": "http",
      "url": "https://mcp.tronsave.io/testnet/mcp"
    }
  }
}
```

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

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 63, +2)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 61, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 61, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 60, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 59, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 59)

First indexed and scored.

## MCP tools (29)

### `tronsave_get_internal_account` (~167 tokens)

Internal Account Information

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.

Output parameters:

- `balance` (string): Account balance in SUN (string).
- `depositAddress` (string): TRON base58 deposit address for funding the internal balance.
- `id` (string)
- `representAddress` (string): TRON base58 represent address (used as order requester).

### `tronsave_get_deposit_address` (~165 tokens)

Get Deposit Address

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.

Input parameters:

- `amountTrx` (number, required): Amount of TRX to deposit

Output parameters:

- `amountTrx` (number): Amount of TRX to deposit
- `depositAddress` (string): TRON base58 deposit address, used for deposit TRX to TronSave internal account

### `tronsave_internal_order_history` (~191 tokens)

Internal Account Order History

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.

Input parameters:

- `page` (integer): Page index, 0-based. Omit for first page (default 0).
- `pageSize` (integer): Orders per page. Default 10 when omitted. Typical range 1–100.

Output parameters:

- `data` (array): Orders on this page, newest first.
- `total` (number): Total orders matching the query (for pagination).

### `tronsave_internal_order_details` (~175 tokens)

Internal Order Details

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.

Input parameters:

- `orderId` (string, required): TronSave order ID (hex string), e.g. value returned in internal.order.create response data.orderId.

Output parameters:

- `allowPartialFill` (boolean): Whether partial fill is allowed.
- `createdAt`: Order created time (Unix epoch ms or ISO-8601, endpoint-dependent).
- `delegates` (array): Delegations fulfilling this order.
- `durationSec` (number): Delegated duration in seconds.
- `fulfilledPercent` (number): 0 = pending, 1-99 = partial, 100 = fully matched.
- `id` (string): TronSave order ID (hex string).
- `orderType` (string): Order type (NORMAL | FAST | EXTEND).
- `payoutAmount` (number): Payout amount in SUN.
- `price` (number): Unit price in SUN.
- `receiver` (string): TRON base58 receiver address.
- `remainAmount` (number): Remaining unfulfilled amount.
- `requester` (string): TRON base58 requester address.
- `resourceAmount` (number): Resource amount of order.
- `resourceType` (string): Resource type.
- `status` (string): Order status.

### `tronsave_internal_order_book` (~240 tokens)

Internal Market Order Book

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.

Input parameters:

- `address` (string): Optional TRON base58 address filter for the receiver.
- `durationSec` (integer): Delegation duration window in seconds for the quote.
- `minDelegateAmount` (number): Minimum resource amount per offer level to include (resource units, not SUN).
- `resourceType` (string): Resource type. Default ENERGY when omitted.

Output parameters:

- `availableResource` (number): Available resource at the quoted tiers.
- `data` (array): Order book entries sorted by price.
- `fast` (number): FAST price tier (SUN).
- `medium` (number): MEDIUM price tier (SUN).
- `slow` (number): SLOW price tier (SUN).

### `tronsave_internal_order_estimate` (~307 tokens)

Estimate TRX Cost Before Order

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.

Input parameters:

- `durationSec` (integer): Delegation duration in seconds. Default 259200 (3 days) when omitted.
- `options` (object): Optional flags that affect matching behavior for the estimate.
- `receiver` (string): TRON base58 address that will receive the resource.
- `requester` (string): TRON base58 requester; defaults to the API key account when omitted.
- `resourceAmount` (number, required): Amount of resource to purchase (resource units).
- `resourceType` (string): 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.

Output parameters:

- `availableResource` (number): Available resource amount.
- `durationSec` (number): Delegated duration in seconds.
- `estimateTrx` (number): Estimated TRX cost in SUN.
- `unitPrice` (number): Unit price in SUN.

### `tronsave_internal_order_create` (~328 tokens)

Create Energy or Bandwidth Order (Internal)

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 }`.

Input parameters:

- `durationSec` (integer): Delegation duration in seconds. Default 259200 (3 days) when omitted.
- `options` (object): Optional execution guards and fill behavior.
- `receiver` (string, required): TRON base58 address that will receive the resource.
- `resourceAmount` (number, required): Amount of resource to purchase (resource units).
- `resourceType` (string): Resource type. Default ENERGY when omitted.
- `sponsor` (string): Optional sponsor or referral code.
- `unitPrice`: Pricing: FAST | MEDIUM | SLOW strategy, or exact unit price in SUN per resource unit. Default MEDIUM when omitted.

Output parameters:

- `orderId` (string): TronSave order ID (hex string) of the created/extension order.

### `tronsave_internal_extend_delegates` (~265 tokens)

List Extendable Delegations

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.

Input parameters:

- `extendTo` (integer, required): Target end time as Unix epoch milliseconds (UTC) for the extended delegation.
- `maxPriceAccepted` (number): Maximum unit price in SUN you are willing to pay for the extension.
- `receiver` (string, required): TRON base58 address of the account that receives the delegated resource.
- `requester` (string): TRON base58 requester; defaults to the API key account when omitted.
- `resourceType` (string): Resource type. Default ENERGY when omitted.

Output parameters:

- `extendData`: Delegations to extend; pass unchanged into internal_create_extend_request `extendData`.
- `extendOrderBook` (array): Order book for extend.
- `isAbleToExtend` (boolean): Whether balance is sufficient to extend.
- `totalAvailableExtendAmount` (number): Total available amount to extend.
- `totalDelegateAmount` (number): Total delegated resource amount.
- `totalEstimateTrx` (number): Total estimated TRX cost in SUN.
- `yourBalance` (number): Current account balance in SUN.

### `tronsave_internal_create_extend_request` (~222 tokens)

Submit Delegation Extension

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.

Input parameters:

- `extendData` (array, required): Rows copied from `extendData` returned by `tronsave_internal_extend_delegates`.
- `receiver` (string, required): TRON base58 address of the account that receives the delegated resource.
- `resourceType` (string): Resource type. Default ENERGY when omitted.

Output parameters:

- `orderId` (string): TronSave order ID (hex string) of the created/extension order.

### `tronsave_get_sign_message` (~90 tokens)

Get Signature Message

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`.

Output parameters:

- `message` (string): Hex-encoded nonce message to sign client-side with the user's TRON wallet. The signature must be produced over THIS exact message (case-sensitive).
- `timestamp` (integer): Unix 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…

### `tronsave_login` (~244 tokens)

Login Session

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.

Input parameters:

- `apiKey` (string): Raw API key for internal-tools login. Provide EXACTLY ONE of `apiKey` or `signature`.
- `signature` (string): Signature token in `signature_timestamp` format (timestamp is the signed message). Provide EXACTLY ONE of `apiKey` or `signature`.

Output parameters:

- `expiresAt` (string)
- `sessionId` (string): Session id to pass as mcp-session-id in subsequent calls.
- `walletAddress` (string)

### `tronsave_get_user_info` (~135 tokens)

User Information

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.

Output parameters:

- `address` (string): TRON base58 address
- `balance` (string): Amount in SUN, onchain balance of the address
- `caller` (string): TRON base58 address of the caller
- `info`
- `internalAccount`

### `tronsave_get_user_auto_setting` (~85 tokens)

User Auto Setting

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.

Output parameters:

- `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.

### `tronsave_get_user_permissions` (~79 tokens)

User Permissions

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.

Output parameters:

- `permitOperations` (array): Permission rows enabled for this user; defaults to `[]` when nothing is configured.

### `tronsave_estimate_buy_resource` (~288 tokens)

Estimate Buy Resource

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`.

Input parameters:

- `allowPartialFill` (boolean): Allow partial fill of the order.
- `buyResourceAmount` (number): Amount of resource to buy. Default 100000 for ENERGY and 1000 for BANDWIDTH
- `durationSec` (number): Duration of the order in seconds. Default 15 minutes
- `minResourceDelegateRequiredAmount` (number): Minimum amount of resource to delegate.
- `receiver` (string): receiver address.
- `resourceType` (string): Resource type to buy. Default ENERGY
- `unitPrice` (number): Unit price in SUN.

Output parameters:

- `availableResource` (number): Available resource amount
- `durationSec` (number): Delegated duration in seconds
- `estimateTrx` (number): Estimated TRX cost in SUN
- `systemDepositAddress` (string): System deposit address for onchain payment
- `unitPrice` (number): Unit price in SUN

### `tronsave_get_order` (~153 tokens)

Order Detail

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.

Input parameters:

- `id` (string, required): Target order id (`MObjectId`) to inspect. Use this to confirm current status/price before update, sell, or cancel actions.

Output parameters:

- `order`

### `tronsave_list_orders` (~362 tokens)

List Orders

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.

Input parameters:

- `isOnlyMyOrder` (boolean): 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…
- `limit` (integer): Maximum rows to return in one call. Prefer modest limits to avoid huge payloads; page with `offset`.
- `offset` (integer): Zero-based row offset for page N (skip first `offset` matches). Omit when starting from the first page.
- `resourceType` (string): Restrict to `ENERGY` or `BANDWIDTH` orders; omit for both.
- `status` (string): Lifecycle filter mapped to GraphQL `isFulfilled`: `ACTIVE` → `UNFULFILLED` (not yet fulfilled), `COMPLETED` → `FULFILLED`.

Output parameters:

- `orders` (array): Matching orders for this page; may be large—use pagination inputs to chunk.

### `tronsave_list_order_books` (~195 tokens)

Order Book

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.

Input parameters:

- `address` (string): Optional viewer/requester wallet context.
- `durationSec` (number): Optional delegation duration filter in seconds.
- `minDelegateAmount` (number): Optional minimum delegate amount floor for bucket filtering.
- `resourceType` (string, required): Order-book side to query (`ENERGY` or `BANDWIDTH`).

Output parameters:

- `orderBook` (array)

### `tronsave_get_min_price` (~283 tokens)

Get Minimum Unit Price

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.

Input parameters:

- `address` (string): Optional TRON base58 address (`TronAddress`). When omitted, the server uses anonymous/global market context.
- `buyAmount` (number): Resource amount to price (same units as order book / delegate amounts for that resource type). Default 100000 for ENERGY and 1000 for BANDWIDTH
- `durationSec` (number): Delegation window in seconds; must match the duration you plan to use on a real order for comparable quotes. Default 15 minutes
- `resourceType` (string): Market leg: `ENERGY` or `BANDWIDTH`. Default ENERGY

Output parameters:

- `minPrice` (number): Estimated 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…

### `tronsave_list_extendable_delegates` (~333 tokens)

Extendable Delegates

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).

Input parameters:

- `receiver` (string, required): TRON 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…
- `requester` (string): 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…
- `resourceType` (string, required): Which resource market leg to query: `ENERGY` for contract execution headroom, `BANDWIDTH` for transaction bandwidth. Must match how you plan to extend or buy.
- `suggestData` (object): 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…

Output parameters:

- `extendableDelegates`: Null when the market has no payload or GraphQL returned no branch; check tool-level errors for hard failures.

### `tronsave_create_order` (~522 tokens)

Create Order

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.

Input parameters:

- `orderDurationSec` (number, required): Delegation duration in seconds. Must match the `durationSec` used in `tronsave_estimate_buy_resource`.
- `orderReceiver` (string, required): TRON base58 address (starts with T) that receives delegated resource. Same as `receiver` passed to `tronsave_estimate_buy_resource`.
- `orderResourceAmount` (number, required): Amount of ENERGY or BANDWIDTH units to purchase. Same as `buyResourceAmount` in estimate when applicable.
- `orderResourceType` (string, required): Resource to buy: ENERGY (smart contracts) or BANDWIDTH (transactions). Must match `tronsave_estimate_buy_resource`.
- `orderUnitPrice` (number, required): Unit price in SUN. Prefer aligning with `minResourcePrice` or `buyResourcePrice` from the latest `tronsave_estimate_buy_resource` for the same receiver, amount, and duration.
- `paymentMethod` (string, required): Payment method for this order: `onchain` (wallet signed tx) or `internal` (internal balance).
- `paymentPaymentAmount` (number, required): Payment amount in SUN. Prefer deriving from `tronsave_estimate_buy_resource`; if converting to TRX, divide SUN by `1e6`.
- `paymentSignedTx` (object): 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…

Output parameters:

- `code` (integer): GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
- `data`
- `message` (string): Human-readable status text. Populated even on success; localized error messages may appear here on failure.
- `success` (boolean): Whether the mutation succeeded at the backend level. Always check this before reading `data`.

### `tronsave_sell_order_manual` (~220 tokens)

Sell Order Manual

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.

Input parameters:

- `orderId` (string, required): Target order id (`MObjectId`) to manually fulfill. Should be an order eligible for seller-side manual execution.
- `paymentAddress` (string): Optional payout/payment address override when settlement flow requires it.
- `signedTx` (object, required): Required wallet-signed transaction payload (TronWeb shape: `{ txID, raw_data, raw_data_hex, signature[] }`). Must come from client-side signing; never fabricate.

Output parameters:

- `code` (integer): GraphQL 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.
- `message` (string): Human-readable status text. Populated even on success; localized error messages may appear here on failure.
- `success` (boolean): Whether the mutation succeeded at the backend level. Always check this before reading `data`.

### `tronsave_cancel_order` (~164 tokens)

Cancel Order

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.

Input parameters:

- `orderId` (string, required): Target 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.

Output parameters:

- `code` (integer): GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
- `message` (string): Human-readable status text. Populated even on success; localized error messages may appear here on failure.
- `success` (boolean): Whether the mutation succeeded at the backend level. Always check this before reading `data`.

### `tronsave_update_order` (~199 tokens)

Update Order

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.

Input parameters:

- `newPrice` (number): Optional replacement unit price in SUN.
- `orderId` (string, required): Target order id (`MObjectId`) to update. Order must still be open and editable.
- `receiver` (string): Optional replacement receiver TRON address.

Output parameters:

- `code` (integer): GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
- `message` (string): Human-readable status text. Populated even on success; localized error messages may appear here on failure.
- `success` (boolean): Whether the mutation succeeded at the backend level. Always check this before reading `data`.

### `tronsave_register_auto_sell` (~154 tokens)

Register Auto Sell

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.

Input parameters:

- `addOnFeature` (object)
- `paymentConfig` (object)
- `poolSetting` (object)

Output parameters:

- `code` (integer): GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
- `data` (string): Opaque server-defined payload (tx id, setting id, or status text). Treat as identifier-or-message; rely on `message` for human routing.
- `message` (string): Human-readable status text. Populated even on success; localized error messages may appear here on failure.
- `success` (boolean): Whether the mutation succeeded at the backend level. Always check this before reading `data`.

### `tronsave_update_auto_sell_setting` (~148 tokens)

Update Auto Sell Setting

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.

Input parameters:

- `addOnFeature` (object)
- `paymentConfig` (object)
- `poolSetting` (object)

Output parameters:

- `code` (integer): GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
- `data` (string): Opaque server-defined payload (tx id, setting id, or status text). Treat as identifier-or-message; rely on `message` for human routing.
- `message` (string): Human-readable status text. Populated even on success; localized error messages may appear here on failure.
- `success` (boolean): Whether the mutation succeeded at the backend level. Always check this before reading `data`.

### `tronsave_generate_api_key` (~129 tokens)

Generate API Key

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.

Output parameters:

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

### `tronsave_revoke_api_key` (~115 tokens)

Revoke API Key

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.

Output parameters:

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

### `tronsave_delete_auto_buy_setting` (~118 tokens)

Delete Auto Buy Setting

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.

Input parameters:

- `id` (string, required): Auto-buy setting id (`MObjectId`) to delete.

Output parameters:

- `code` (integer): GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing.
- `message` (string): Human-readable status text. Populated even on success; localized error messages may appear here on failure.
- `success` (boolean): Whether the mutation succeeded at the backend level. Always check this before reading `data`.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/tronsave-mcp/testnet-mcp#diagnostics

## Score history

- 2026-08-03: 64
- 2026-08-02: 63
- 2026-08-01: 63
- 2026-07-31: 63
- 2026-07-30: 61
- 2026-07-29: 61
- 2026-07-28: 60
- 2026-07-27: 59
- 2026-07-26: 59

## Links

- Remote endpoint: https://mcp.tronsave.io/testnet/mcp
- Repository: https://github.com/tronsave/mcp
- Website: https://docs.tronsave.io/
- Changelog RSS feed: https://verifymcp.io/servers/tronsave-mcp/testnet-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/tronsave-mcp/testnet-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/tronsave-mcp/testnet-mcp