TronSave MCP Server

Official

by tronsave

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Update Auto-Buy Rule

tronsave_update_auto_buy_setting

Idempotent

Update an existing TRON auto-buy rule by ID to pause/resume it or change price cap, amount, duration, threshold, and limits; requires wallet signature; get IDs from the list tool.

Instructions

Change an auto-buy rule by id: pause or resume it with isActive, or change any of price cap, amount, duration, threshold and limits (only the fields you send change). Side effect: a resumed or loosened rule can start spending internal TRX again. Idempotent for the same arguments. Get ids from tronsave_list_auto_buy_settings. Requires a wallet signature identity.

Input Schema

Name	Required	Description
`id`	Yes	Rule id from `tronsave_list_auto_buy_settings`.
`isActive`	No	false pauses the rule, true resumes it.
`receiver`	No	TRON base58 address that receives each delegation.
`unitPrice`	No	Maximum unit price in SUN, as a decimal string.
`durationSec`	No	Delegation duration of each purchase, in seconds.
`endActiveAt`	No	Optional Unix time in seconds when the rule stops.
`resourceType`	No	ENERGY or BANDWIDTH.
`startActiveAt`	No	Optional Unix time in seconds when the rule starts.
`resourceAmount`	No	Resource units bought each time the rule fires.
`limitBudgetInSun`	No	Optional total budget cap in SUN (decimal string); must be greater than 10000000 (10 TRX).
`limitInOrderCount`	No	Optional cap on the number of orders.
`thresholdResourceAmount`	No	Rule fires when the receiver's remaining resource drops below this many units (TronSave requires at least 100000).

Output Schema

Name	Required	Description	Default
`code`	No
`data`	No
`message`	No
`success`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.4.0Nov 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the annotation hints, the description discloses a meaningful side effect: a resumed or loosened rule can start spending internal TRX again. It also notes the auth requirement and partial-update behavior. The idempotence statement repeats the annotation rather than adding new context, keeping this from a 5.

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

Conciseness4/5

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

The description is compact, front-loaded, and wastes little space. The idempotence clause is largely redundant with the annotation, but the rest of the text is dense with useful routing and side-effect information.

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

Completeness4/5

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

With 12 parameters, a full schema, annotations, and an output schema, the description covers the essential context: id source, partial-update semantics, auth, and spending side effects. It does not explicitly mention that fields like receiver, resourceType, and scheduling times are also mutable, but the schema documents them fully.

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 coverage is 100%, so the baseline is 3. The description adds useful PATCH-like semantics by clarifying that only fields you send are changed and by naming the categories of updatable values, which is more than restating the schema.

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

Purpose5/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 (change an auto-buy rule by id) and explicitly names the two core operations: pause/resume via isActive and field updates. It is clearly distinguishable from sibling tools like create_auto_buy_setting and delete_auto_buy_setting.

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 clear usage context: ids come from tronsave_list_auto_buy_settings, partial updates are supported, and a wallet signature identity is required. It stops short of explicitly saying when to use this versus create/delete siblings or excluding invalid states, so it is strong but not a full routing guide.

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

Deploy Server