TronSave MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Create Order

tronsave_create_order

Creates a paid TronSave order to buy and delegate ENERGY or BANDWIDTH to a specified TRON address, using internal balance or an on-chain signed payment.

Instructions

Create a buy order for ENERGY/BANDWIDTH delegated to orderReceiver. SPENDS FUNDS — confirm the plan with the user first. Inputs: orderResourceType, orderReceiver, orderUnitPrice (SUN, not TRX), orderDurationSec, orderResourceAmount, paymentPaymentAmount (SUN), and paymentMethod: internal — debits the TronSave internal balance (needs an api-key login/header or a signature login whose wallet has an internal account); onchain — no login needed, but paymentSignedTx must be the user's wallet-signed TRX transfer to systemDepositAddress. Take price/amount/duration values from the latest tronsave_estimate_buy_resource. Returns { success, message, code, data.orderId } — check success; verify with tronsave_get_order or tronsave_list_orders. Not idempotent: on a timeout, verify before retrying to avoid duplicate orders.

Input Schema

Name	Required	Description
`orderReceiver`	Yes	TRON base58 address (starts with T) that receives delegated resource. Same as `receiver` passed to `tronsave_estimate_buy_resource`.
`paymentMethod`	Yes	Payment method for this order: `onchain` (wallet signed tx) or `internal` (internal balance).
`orderUnitPrice`	Yes	Unit price in SUN per resource unit (NOT TRX). Use `unitPrice` from the latest `tronsave_estimate_buy_resource` for the same receiver, amount, and duration.
`paymentSignedTx`	No	Required when `paymentMethod=onchain`: the user's wallet-signed TRX transfer of `paymentPaymentAmount` SUN to `systemDepositAddress` (from `tronsave_estimate_buy_resource`), TronWeb shape `{ txID, raw_data, raw_data_hex, signature[] }`. Must be produced client-side by the user's wallet; never fabricate or hand-edit.
`orderDurationSec`	Yes	Delegation duration in seconds. Must match the `durationSec` used in `tronsave_estimate_buy_resource`.
`orderResourceType`	Yes	Resource to buy: ENERGY (smart contracts) or BANDWIDTH (transactions). Must match `tronsave_estimate_buy_resource`.
`orderResourceAmount`	Yes	Amount of ENERGY or BANDWIDTH units to purchase. Same as `buyResourceAmount` in estimate when applicable.
`paymentPaymentAmount`	Yes	Total payment in SUN (1 TRX = 1e6 SUN). Use `estimateTrx` (SUN) from the latest `tronsave_estimate_buy_resource`.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.4.0Nov 2, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses that the tool spends funds, requires user confirmation, has different authentication requirements per payment method, returns a success flag with `orderId`, and is not idempotent. It also warns that a timeout should be verified before retrying to avoid duplicate orders, adding substantial safety context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded with purpose and the critical funds-spending warning. Every sentence carries operational value, with no filler, despite covering a complex mutation with multiple payment paths.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a complex, non-idempotent mutation with nested payment transaction requirements, and the description covers authentication modes, estimate dependency, return checking, and retry safety. An output schema exists, and the description still usefully highlights the `success` field and verification path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 100%, so the baseline is 3. The description adds useful cross-parameter semantics: price and amount are in SUN, not TRX; values should come from the latest estimate; and `paymentMethod` changes whether login or a wallet-signed transaction is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: create a buy order for ENERGY/BANDWIDTH delegated to `orderReceiver`. It clearly distinguishes the operation from read-only estimation and order inspection siblings, but does not explicitly contrast it with `tronsave_internal_order_create` or `tronsave_bulk_create_internal_orders`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives strong operational guidance: confirm with the user before spending funds, take values from the latest `tronsave_estimate_buy_resource`, and choose `internal` vs `onchain` based on login and signed-transaction requirements. It also explains the timeout retry procedure, though it does not explicitly name when to prefer the internal or bulk order-creation siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server