io.github.tronsave/mcp
REMOTE · MCP.TRONSAVE.IO · 2 COMPONENTS · SCANNED AUG 3
Buy, sell & extend TRON ENERGY/BANDWIDTH on the TronSave market via typed MCP tools.
Available components
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 →
Endpoint Security60
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (tronsave_sell_order_manual). See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC is configured correctly; the domain's records validate against the full chain to the root. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability62
- 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 Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
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
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · mcp.tronsave.io
claude mcp add --transport http tronsave-mcp https://mcp.tronsave.io/mcp
[mcp_servers.tronsave-mcp] url = "https://mcp.tronsave.io/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"tronsave-mcp": {
"type": "remote",
"url": "https://mcp.tronsave.io/mcp",
"enabled": true
}
}
} openclaw mcp add tronsave-mcp --url https://mcp.tronsave.io/mcp --transport streamable-http
mcp_servers:
tronsave-mcp:
url: "https://mcp.tronsave.io/mcp" {
"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.
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.
- 2 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.
- 31 Jul 26 +1
- 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 +1
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 28 Jul 26 +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.
- 27 Jul 26 +1
- 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 60
First indexed and scored.
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 3 Aug 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 | 26 Jun 2026 | 24 Sept 2026 | ECDSA 256 | ECDSA-SHA256 | ba828847584d9e91375d5ac6f967b6a |
| 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 |
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=() |
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 |
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.
tronsave_cancel_order 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.
| Name | Type | Req | Description |
|---|---|---|---|
| orderId | string | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| message | string | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.
tronsave_create_order 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.
| Name | Type | Req | Description |
|---|---|---|---|
| orderDurationSec | number | yes | Delegation duration in seconds. Must match the `durationSec` used in `tronsave_estimate_buy_resource`. |
| orderReceiver | string | yes | TRON base58 address (starts with T) that receives delegated resource. Same as `receiver` passed to `tronsave_estimate_buy_resource`. |
| orderResourceAmount | number | yes | Amount of ENERGY or BANDWIDTH units to purchase. Same as `buyResourceAmount` in estimate when applicable. |
| orderResourceType | string | yes | Resource to buy: ENERGY (smart contracts) or BANDWIDTH (transactions). Must match `tronsave_estimate_buy_resource`. |
| orderUnitPrice | number | yes | 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 | yes | Payment method for this order: `onchain` (wallet signed tx) or `internal` (internal balance). |
| paymentPaymentAmount | number | yes | 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | — | — | — |
| message | string | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.
tronsave_delete_auto_buy_setting 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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Auto-buy setting id (`MObjectId`) to delete. |
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| message | string | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.
tronsave_estimate_buy_resource 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`.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| availableResource | number | yes | Available resource amount |
| durationSec | number | yes | Delegated duration in seconds |
| estimateTrx | number | yes | Estimated TRX cost in SUN |
| systemDepositAddress | string | yes | System deposit address for onchain payment |
| unitPrice | number | yes | Unit price in SUN |
No examples provided.
tronsave_generate_api_key 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.
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | string | yes | For `generateApiKey`: the freshly issued internal API key — treat as SECRET, store securely. For `revokeApiKey`: server-defined confirmation string (no key material). |
| message | string | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.
tronsave_get_deposit_address 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.
| Name | Type | Req | Description |
|---|---|---|---|
| amountTrx | number | yes | Amount of TRX to deposit |
| Name | Type | Req | Description |
|---|---|---|---|
| amountTrx | number | yes | Amount of TRX to deposit |
| depositAddress | string | yes | TRON base58 deposit address, used for deposit TRX to TronSave internal account |
No examples provided.
tronsave_get_internal_account Internal Account Information ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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). |
No examples provided.
tronsave_get_min_price Get Minimum Unit 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 |
| Name | Type | Req | Description |
|---|---|---|---|
| minPrice | number | yes | 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… |
No examples provided.
tronsave_get_order Order Detail ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Target order id (`MObjectId`) to inspect. Use this to confirm current status/price before update, sell, or cancel actions. |
| Name | Type | Req | Description |
|---|---|---|---|
| order | — | yes | — |
No examples provided.
tronsave_get_sign_message Get Signature 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.
| Name | Type | Req | Description |
|---|---|---|---|
| message | string | yes | 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 | yes | 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… |
No examples provided.
tronsave_get_user_auto_setting 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 User Information ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | TRON base58 address |
| balance | string | yes | Amount in SUN, onchain balance of the address |
| caller | string | yes | TRON base58 address of the caller |
| info | — | yes | — |
| internalAccount | — | yes | — |
No examples provided.
tronsave_get_user_permissions 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.
| Name | Type | Req | Description |
|---|---|---|---|
| permitOperations | array | yes | Permission rows enabled for this user; defaults to `[]` when nothing is configured. |
No examples provided.
tronsave_internal_create_extend_request Submit Delegation Extension ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| extendData | array | yes | Rows copied from `extendData` returned by `tronsave_internal_extend_delegates`. |
| receiver | string | yes | TRON base58 address of the account that receives the delegated resource. |
| resourceType | string | — | Resource type. Default ENERGY when omitted. |
| Name | Type | Req | Description |
|---|---|---|---|
| orderId | string | — | TronSave order ID (hex string) of the created/extension order. |
No examples provided.
tronsave_internal_extend_delegates List Extendable Delegations ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| extendTo | integer | yes | 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No examples provided.
tronsave_internal_order_book Internal Market 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| 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). |
No examples provided.
tronsave_internal_order_create Create Energy or Bandwidth Order (Internal) ~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 }`.
| Name | Type | Req | Description |
|---|---|---|---|
| durationSec | integer | — | Delegation duration in seconds. Default 259200 (3 days) when omitted. |
| options | object | — | Optional execution guards and fill behavior. |
| receiver | string | yes | TRON base58 address that will receive the resource. |
| resourceAmount | number | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| orderId | string | — | TronSave order ID (hex string) of the created/extension order. |
No examples provided.
tronsave_internal_order_details 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.
| Name | Type | Req | Description |
|---|---|---|---|
| orderId | string | yes | TronSave order ID (hex string), e.g. value returned in internal.order.create response data.orderId. |
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No examples provided.
tronsave_internal_order_estimate Estimate TRX Cost Before Order ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| availableResource | number | — | Available resource amount. |
| durationSec | number | — | Delegated duration in seconds. |
| estimateTrx | number | — | Estimated TRX cost in SUN. |
| unitPrice | number | — | Unit price in SUN. |
No examples provided.
tronsave_internal_order_history Internal Account 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| data | array | — | Orders on this page, newest first. |
| total | number | — | Total orders matching the query (for pagination). |
No examples provided.
tronsave_list_extendable_delegates 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).
| Name | Type | Req | Description |
|---|---|---|---|
| receiver | string | yes | 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 | yes | 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| extendableDelegates | — | yes | Null 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 Order Book ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Order-book side to query (`ENERGY` or `BANDWIDTH`). |
| Name | Type | Req | Description |
|---|---|---|---|
| orderBook | array | yes | — |
No examples provided.
tronsave_list_orders 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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`. |
| Name | Type | Req | Description |
|---|---|---|---|
| orders | array | yes | Matching orders for this page; may be large—use pagination inputs to chunk. |
No examples provided.
tronsave_login Login Session ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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`. |
| Name | Type | Req | Description |
|---|---|---|---|
| expiresAt | string | yes | — |
| sessionId | string | yes | Session id to pass as mcp-session-id in subsequent calls. |
| walletAddress | string | — | — |
No examples provided.
tronsave_register_auto_sell 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.
| Name | Type | Req | Description |
|---|---|---|---|
| addOnFeature | object | — | — |
| paymentConfig | object | — | — |
| poolSetting | object | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | string | yes | Opaque server-defined payload (tx id, setting id, or status text). Treat as identifier-or-message; rely on `message` for human routing. |
| message | string | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.
tronsave_revoke_api_key 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.
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | string | yes | For `generateApiKey`: the freshly issued internal API key — treat as SECRET, store securely. For `revokeApiKey`: server-defined confirmation string (no key material). |
| message | string | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.
tronsave_sell_order_manual 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.
| Name | Type | Req | Description |
|---|---|---|---|
| orderId | string | yes | 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 | yes | Required wallet-signed transaction payload (TronWeb shape: `{ txID, raw_data, raw_data_hex, signature[] }`). Must come from client-side signing; never fabricate. |
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | 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 | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.
tronsave_update_auto_sell_setting 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.
| Name | Type | Req | Description |
|---|---|---|---|
| addOnFeature | object | — | — |
| paymentConfig | object | — | — |
| poolSetting | object | — | — |
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | string | yes | Opaque server-defined payload (tx id, setting id, or status text). Treat as identifier-or-message; rely on `message` for human routing. |
| message | string | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.
tronsave_update_order 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.
| Name | Type | Req | Description |
|---|---|---|---|
| newPrice | number | — | Optional replacement unit price in SUN. |
| orderId | string | yes | Target order id (`MObjectId`) to update. Order must still be open and editable. |
| receiver | string | — | Optional replacement receiver TRON address. |
| Name | Type | Req | Description |
|---|---|---|---|
| code | integer | yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| message | string | yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | boolean | yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
No examples provided.