mcpbeat

Tronsave MCP Server

io.github.tronsave/mcp
answering

Tronsave is answering right now. Last checked 10 min ago. It exposes 29 tools.

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

The linked repository no longer exists on GitHub — it was deleted or made private.

Uptime history 40 hours of history
40 hours agonow
100.0%
Uptime 24h
182 of 182 checks
29
Tools
read from the server
466 ms
Response time
average over 24h
open, no key
Access
streamable-http

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 10 min ago.

run in your terminal
claude mcp add mcp --transport http https://mcp.tronsave.io/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "mcp": {
      "url": "https://mcp.tronsave.io/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.mcp]
url = "https://mcp.tronsave.io/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "mcp": {
      "url": "https://mcp.tronsave.io/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "mcp": {
      "url": "https://mcp.tronsave.io/mcp"
    }
  }
}

Available tools 29

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

tronsave
tronsave_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.
tronsave_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.
tronsave_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.
tronsave_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`.
tronsave_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.
tronsave_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.
tronsave_get_internal_account
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.
tronsave_get_min_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.
tronsave_get_order
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.
tronsave_get_sign_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`.
tronsave_get_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.
tronsave_get_user_info
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.
tronsave_get_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.
tronsave_internal_create_extend_request
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.
tronsave_internal_extend_delegates
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.
tronsave_internal_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.
tronsave_internal_order_create
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 }`.
tronsave_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.
tronsave_internal_order_estimate
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.
tronsave_internal_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.
tronsave_list_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).
tronsave_list_order_books
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.
tronsave_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.
tronsave_login
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.
tronsave_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.
tronsave_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.
tronsave_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.
tronsave_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.
tronsave_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.

Endpoints

URLTransportStateLatencyChecked
https://mcp.tronsave.io/mcp streamable-http answering 452 ms 10 min ago
https://mcp.tronsave.io/testnet/mcp streamable-http answering 250 ms 10 min ago

Tronsave — questions

Answers built from our own checks of this server.

What can Tronsave do?
It exposes 29 tools, read directly from the server on our last check. Among them: tronsave_cancel_order, tronsave_create_order, tronsave_delete_auto_buy_setting, tronsave_estimate_buy_resource, tronsave_generate_api_key, tronsave_get_deposit_address and 23 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is Tronsave working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 182 of 182 checks got a reply (100.0%), average response time 466 ms. The bar chart above shows every period we have measured.
Is Tronsave still maintained?
The linked repository no longer exists on GitHub — it was deleted or made private. We show this because it changes what you can expect: an unmaintained server may keep answering for months and then stop without warning.
How do I connect Tronsave?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Tronsave need an API key?
No. Tronsave completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 29 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Tronsave?
It answers our handshake in 466 ms on average, which is faster than 25% of all working MCP servers we measure. That is on the slow side — worth knowing if the tool sits inside an interactive loop. The comparison comes from our own checks across the whole registry, every 15 minutes.