TronSave MCP Server
Server Details
Production-ready TronSave MCP server focused on helping agents and clients buy and sell TRON resource quickly through one unified interface, with fast order execution, pricing/estimation tools, and secure session-based workflows.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 20 of 20 tools scored. Lowest: 2.9/5.
Each tool targets a distinct resource or action. For example, `tronsave_create_order`, `tronsave_update_order`, and `tronsave_cancel_order` are clearly separate; market-data tools like `tronsave_estimate_buy_resource` and `tronsave_list_order_books` serve different purposes. No two tools have overlapping functionality.
The naming follows a generally consistent pattern of `tronsave_verb_noun`, e.g., `cancel_order`, `create_order`. However, there are minor inconsistencies: `register_auto_sell` vs. `update_auto_sell_setting` (missing 'setting' suffix) and `delete_auto_buy_setting` (includes 'setting'). Overall, the convention is clear but not perfectly uniform.
With 20 tools for a DeFi order management and automation server, the count is reasonable. It covers core operations (order CRUD, auto-sell, market queries, authentication) without being bloated. A slight reduction or better grouping could improve it, but it's well-scoped.
The tool set covers order management and auto-sell well, but notable gaps exist: there is no `create_auto_buy` or `update_auto_buy` (only delete), and no `revoke_api_key` despite `generate_api_key`. This forces agents to work around missing lifecycle operations, indicating incomplete coverage.
Available Tools
20 toolstronsave_cancel_orderCancel OrderADestructiveIdempotentInspect
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 | Required | Description | Default |
|---|---|---|---|
| orderId | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| message | Yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | Yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions required sessions but does not explain the outcome of cancellation (e.g., order status changes, refunds, reversibility), leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has few parameters and an output schema, the description lacks behavioral details about the cancellation's effects, which is important for an action with side effects. The session requirement is noted, but overall completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage and already describes the `orderId` parameter sufficiently. The description does not add additional meaning beyond what is in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel an existing order') and the resource ('by orderId'), distinguishing it from sibling tools like tronsave_create_order_onchain or tronsave_list_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites ('Requires a valid signature session and mcp-session-id'), guiding when the tool is usable, though it does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_create_orderCreate OrderAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. Prefer aligning with `minResourcePrice` or `buyResourcePrice` from the latest `tronsave_estimate_buy_resource` for the same receiver, amount, and duration. | |
| paymentSignedTx | No | 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 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 | Payment amount in SUN. Prefer deriving from `tronsave_estimate_buy_resource`; if converting to TRX, divide SUN by `1e6`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | No | |
| message | Yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | Yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It discloses authentication requirements (signature session) and conditional parameter requirements, but does not describe side effects, error handling, idempotency, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct information: the core action, parameter conditions, and prerequisites. No redundant or extraneous content. Could be slightly more structured with bullet points, but still concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 7 required, enums) and the presence of an output schema, the description covers key aspects: conditional parameter dependencies, alignment with estimate endpoints, and required session. It does not explain return values (handled by output schema) or ordering constraints, but is largely complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining conditional requirements for paymentSignedTx and paymentPendingRequester, and by advising alignment of orderUnitPrice with estimate results. This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create order) and the key parameter (paymentMethod) with its variants. It mentions prerequisites but does not explicitly distinguish from sibling tools like tronsave_update_order. Nevertheless, the verb and resource are specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to include conditional parameters based on paymentMethod and lists required session context. However, it does not explicitly advise when to use this tool versus alternatives, though the create operation is logically distinct from update or list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_delete_auto_buy_settingDelete Auto Buy SettingADestructiveIdempotentInspect
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 | Required | Description | Default |
|---|---|---|---|
| id | Yes | Auto-buy setting id (`MObjectId`) to delete. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| message | Yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | Yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'permanently' indicating destructive behavior, and mentions required session. However, it lacks details on side effects, failure modes, or whether the action is reversible beyond stating permanence. No annotations are provided to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no redundant words, front-loaded with action and resource. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and an output schema available, the description covers the action, identifier, and prerequisites. It could mention what the response looks like or confirm deletion, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already explains the id parameter. The tool description only reiterates the id format without adding new semantic information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete), the resource (auto-buy setting), and the identifier (id). It distinguishes itself from sibling tools which cover other operations like create, estimate, get, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (valid signature session and mcp-session-id), but does not explicitly specify when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_estimate_buy_resourceEstimate Buy ResourceARead-onlyIdempotentInspect
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. For order-book depth use tronsave_list_order_books; for the minimum unit price only use tronsave_get_min_price.
| Name | Required | Description | Default |
|---|---|---|---|
| receiver | No | receiver address. | |
| unitPrice | No | Unit price in SUN. | |
| durationSec | No | Duration of the order in seconds. Default 15 minutes | |
| resourceType | No | Resource type to buy. Default ENERGY | ENERGY |
| allowPartialFill | No | Allow partial fill of the order. | |
| buyResourceAmount | No | Amount of resource to buy. Default 100000 for ENERGY and 1000 for BANDWIDTH | |
| minResourceDelegateRequiredAmount | No | Minimum amount of resource to delegate. |
Output Schema
| Name | Required | Description |
|---|---|---|
| unitPrice | Yes | Unit price in SUN |
| durationSec | Yes | Delegated duration in seconds |
| estimateTrx | Yes | Estimated TRX cost in SUN |
| availableResource | Yes | Available resource amount |
| systemDepositAddress | Yes | System deposit address for onchain payment |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool estimates pricing and returns fields, but does not mention whether it is read-only, any side effects, authorization requirements, error handling, or preconditions. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and return fields, and ends with usage guidance. No wasted words, highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, many siblings, no annotations), the description explains the tool's role and connection to order creation but lacks details on parameter meanings, error behavior, and preconditions. With an output schema (not shown), return values are partially covered, but overall completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (1 of 6 parameters have a description). The description does not explain individual parameter semantics beyond hinting at unitPrice selection. Given low coverage, the description should compensate but fails to provide details for the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates buy-resource pricing before creating an order, mentions specific returned fields, and names sibling tools (tronsave_order_create*) that it precedes. This distinguishes it from siblings as an estimation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool before any tronsave_order_create* tool to choose order_unitPrice and deposit hints. It provides clear context but does not mention alternative estimation tools or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_generate_api_keyGenerate API KeyADestructiveInspect
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; call tronsave_revoke_api_key on 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | Yes | For `generateApiKey`: the freshly issued internal API key — treat as SECRET, store securely. |
| message | Yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | Yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the key is internal and used for authentication, and that the raw key is returned in `data` with a storage warning. No annotations provided, so the description carries the burden; could mention session requirements for this tool itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with purpose, no fluff, each sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema, the description covers purpose, return value, and downstream usage. Could mention error cases but sufficient for a simple generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters and 100% coverage, so the description adds value beyond the schema by explaining the return value and usage, earning above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a new internal API key for the current user' with a specific verb and resource, distinguishing it from sibling tools like tronsave_revoke_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to use the key in `tronsave_login` with `apiKey`, and to store it securely. Lacks explicit exclusion scenarios but provides clear practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_get_deposit_addressGet Deposit AddressARead-onlyIdempotentInspect
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 | Required | Description | Default |
|---|---|---|---|
| amountTrx | Yes | Amount of TRX to deposit |
Output Schema
| Name | Required | Description |
|---|---|---|
| amountTrx | Yes | Amount of TRX to deposit |
| depositAddress | Yes | TRON base58 deposit address, used for deposit TRX to TronSave internal account |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: it requires a session ID, notes that API keys are not accepted via arguments (server uses cached session key), declares the operation as read-only, and lists constraints (TRX only, min 10 TRX). This exceeds minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences) and front-loaded with the purpose. Every sentence adds value: purpose, prerequisite, trigger condition, constraints, and read-only nature. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description is complete. It covers purpose, usage scenario, auth requirements, constraints, and behavior (read-only). It also explains why API keys are not passed as arguments. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for amountTrx. The description adds 'TRX only' and reaffirms the minimum, but these are already implied or stated in the schema. No additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a deposit address for the TronSave internal account. It also specifies the use case (user asks for deposit address or needs to top up TRX balance), distinguishing it from sibling tools which cover orders, login, and other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to trigger the tool ('if the user asks for a deposit address or needs to top up their TronSave TRX balance'). It also explains the prerequisite (logged-in MCP session from tronsave_login) and constraints (TRX only, minimum 10 TRX), providing clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_get_min_priceGet Minimum Unit PriceARead-onlyIdempotentInspect
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. Pair with tronsave_estimate_buy_resource for full buy quotes and tronsave_list_order_books for depth buckets.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Optional TRON base58 address (`TronAddress`). When omitted, the server uses anonymous/global market context. | |
| buyAmount | No | Resource amount to price (same units as order book / delegate amounts for that resource type). Default 100000 for ENERGY and 1000 for BANDWIDTH | |
| durationSec | No | Delegation window in seconds; must match the duration you plan to use on a real order for comparable quotes. Default 15 minutes | |
| resourceType | No | Market leg: `ENERGY` or `BANDWIDTH`. Default ENERGY | ENERGY |
Output Schema
| Name | Required | Description |
|---|---|---|
| minPrice | 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 `market.estimateMinPrice`). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states 'Read-only' and 'No login required', but does not detail error handling, rate limits, or behavior for invalid parameters. Still, it adequately discloses the core safety profile and auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. The first front-loads purpose and return format; the second provides auth and usage context. Every sentence is substantive with no verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and tool is simple, description covers input-output mapping, auth, and related tools. It does not explicitly mention defaults for omitted parameters, but schema includes defaults. Overall sufficient for a straightforward query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds value by explaining the return unit (SUN per resource unit) and optional address scoping, and links parameters to usage context with related tools. This goes beyond mere repetition of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a read-only market quote (minPrice) for given parameters, and explicitly distinguishes from sibling tools by mentioning `tronsave_estimate_buy_resource` and `tronsave_list_order_books`. The verb 'returns' and resource 'minimum price' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'No login required', 'optional session forwards auth like tronsave_list_order_books', and recommends using with other tools for full quotes or depth. Clearly indicates when and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_get_orderOrder DetailARead-onlyIdempotentInspect
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. Requires a signature session and mcp-session-id. Read-only and idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Target order id (`MObjectId`) to inspect. Use this to confirm current status/price before update, sell, or cancel actions. |
Output Schema
| Name | Required | Description |
|---|---|---|
| order | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation via the verb 'get' and mentions the return format. However, with no annotations provided, it does not disclose potential side effects, authentication requirements, rate limits, or error conditions beyond what is obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core action and adding one additional detail about order types. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It covers the essential purpose and scope. Minor omission: it does not mention prerequisite authentication, but this is likely handled by server-level auth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the 'id' parameter. The tool description adds context about which order types are returned (NORMAL, FAST, EXTEND) but does not enhance parameter semantics beyond the schema. With 100% schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get details), the resource (single order by id), and the return content (compact order information for specific order types). It effectively distinguishes from sibling tools like tronsave_list_orders (list vs single) and tronsave_update_order (update vs read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single order but does not explicitly specify when to use this tool versus alternatives (e.g., tronsave_list_orders for multiple orders). No exclusions or context for when not to use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_get_sign_messageGet Signature MessageARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| message | 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 | 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 helper; clients may provide their own timestamp payload as well. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It explains the purpose and usage but does not cover response format or potential side effects, though the tool is simple and read-only in nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the action and follow-up steps, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, existing output schema), the description adequately covers what the tool does and how it fits in the authentication flow, meeting contextual requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is trivial (100%). With no parameters, the description naturally adds no extra meaning; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a nonce message for wallet authentication, distinguishing it from the sibling tool `tronsave_login`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to sign the message client-side and then call `tronsave_login`, providing clear context on workflow without excluding other uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_get_user_auto_settingUser Auto SettingARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| vote | No | Whether vote-related automation is enabled for the wallet. |
| energy | No | Energy auto-sell pool snapshot; null when energy automation is disabled. |
| bandwidth | No | Bandwidth auto-sell pool snapshot; null when bandwidth automation is disabled. |
| suggestSell | No | Whether suggest-sell UX hints are enabled. |
| withdrawVote | No | Withdraw-vote configuration as a backend-defined string; semantics from TronSave docs. |
| permitOperations | No | Permission rows enabled for this user; null/empty when no automation has been configured. |
| reclaimOnlyTronSave | No | Reclaim flag — when `true`, only TronSave-managed delegations are reclaimed automatically. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses required authentication and session context. It does not mention side effects (unlikely for a get) but provides sufficient behavioral context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. No extraneous words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema present, the description is largely complete. It lacks mention of edge cases (e.g., not configured) but is adequate for a simple retrieval tool. Slight ambiguity exists between 'User Auto Setting' title and 'auto-sell' in description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so baseline is 4. The description adds meaning by specifying that the tool retrieves the auto-sell configuration for the authenticated user, adding context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('current authenticated user's auto-sell configuration'), and the specific field ('autoSettings'). It distinguishes itself from sibling tools that register, update, or delete settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites (valid signature session and mcp-session-id) but does not explicitly state when to use this tool versus alternatives. However, the context of read-only retrieval versus modify/delete siblings provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_get_user_infoUser InformationARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| info | Yes | |
| caller | Yes | TRON base58 address of the caller |
| address | Yes | TRON base58 address |
| balance | Yes | Amount in SUN, onchain balance of the address |
| internalAccount | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that wallet signing is client-side and warns against sending private keys. However, it does not describe error behaviors or rate limits, but for a read-only tool with no parameters, the coverage is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding value: action, prerequisites, and security note. It is front-loaded with the primary action. Slightly wordy on headers but still clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an existing output schema, the description covers everything needed: what it does, authentication requirements, and a security warning. It is fully complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and description coverage is 100% trivially. The baseline is 4, and the description adds no extra param info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves the current authenticated user's profile and account settings, providing a specific verb and resource. While it does not differentiate from sibling tools like tronsave_get_order, the context is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites: a valid signature session from tronsave_login and the mcp-session-id header. Although it does not explicitly say when not to use this tool or list alternatives, the guidance is sufficient for a simple get operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_get_user_permissionsUser PermissionsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| permitOperations | Yes | Permission rows enabled for this user; defaults to `[]` when nothing is configured. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals the authentication requirement and the output field name, but does not disclose behavioral traits like idempotency or rate limits. For a simple get operation, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It front-loads the purpose and follows with the key prerequisite, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists, the description adequately covers the purpose and precondition. It could explicitly state no side effects, but the output schema likely handles return values, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is trivially 100%. The description adds value by explaining what the tool returns (the permission list), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'current authenticated user's enabled permission list', and distinguishes it from sibling tools like get_user_info or get_user_auto_setting by focusing on permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions the prerequisite of a valid signature session and mcp-session-id, providing clear context for when to use it. No explicit alternatives or when-not-to-use are given, but the precondition is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_list_extendable_delegatesExtendable DelegatesCRead-onlyIdempotentInspect
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, use tronsave_internal_create_extend_request with extendData from the authenticated REST POST /v2/get-extendable-delegates (payload shape differs from this GraphQL response).
| Name | Required | Description | Default |
|---|---|---|---|
| receiver | 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 account's delegation. | |
| requester | No | 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 requester string distinct from the receiver. | |
| suggestData | No | 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 are invalid for typical GraphQL input shapes. | |
| resourceType | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| extendableDelegates | Yes | Null when the market has no payload or GraphQL returned no branch; check tool-level errors for hard failures. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states it is a read operation ('Get'), but lacks details on authentication requirements, rate limits, error handling, or what happens if the receiver address is invalid. The minimal disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and 22 words, containing no fluff or repetition. Every word adds value, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complex input schema (nested objects, enums) and the presence of a very similar sibling tool, the description is far too brief. It does not explain the meaning of parameters, the suggestData structure, or how this tool differs from its twin, leaving the agent with incomplete context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool's description does not compensate: it fails to explain any of the four parameters (e.g., 'receiver', 'requester', 'suggestData', 'resourceType'), leaving the agent without guidance on how to set them, especially the complex nested 'suggestData' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'extendable delegate candidates for a receiver address', providing a specific purpose. However, it does not distinguish this tool from the sibling 'tronsave_internal_list_extendable_delegates', which appears to have an identical name and likely similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for selecting delegates for resource operations, but it does not explicitly state when to use this tool versus other sibling tools, nor does it mention prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_list_order_booksOrder BookARead-onlyIdempotentInspect
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. 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 | Required | Description | Default |
|---|---|---|---|
| address | No | Optional viewer/requester wallet context. | |
| durationSec | No | Optional delegation duration filter in seconds. | |
| resourceType | Yes | Order-book side to query (`ENERGY` or `BANDWIDTH`). | |
| minDelegateAmount | No | Optional minimum delegate amount floor for bucket filtering. |
Output Schema
| Name | Required | Description |
|---|---|---|
| orderBook | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions the return structure and optional filters but omits critical details like read-only nature, authorization requirements, rate limits, or side effects. The description is insufficient for an agent to understand the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and primary output, second adds optional filters. No extraneous information, front-loaded with core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (though not shown), the description covers the basics of what the tool returns and its filters. However, it lacks context on pagination, ordering, error handling, or typical usage scenarios, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 25% of schema properties have descriptions (resourceType with enum). The description adds that 'optional amount and duration filters' are supported, corresponding to minDelegateAmount and durationSec, but does not explicitly map to schema fields or explain address. This provides some added value beyond the schema but leaves ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves market order book data for ENERGY or BANDWIDTH and specifies the return format (price buckets with min, max, value). This distinguishes it from sibling tools like tronsave_list_orders and tronsave_get_order, which deal with orders rather than order books.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching order books, and sibling names hint at different operations, but no explicit guidance on when to use this vs. alternatives is provided. The agent must infer context from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_list_ordersList OrdersBRead-onlyIdempotentInspect
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return in one call. Prefer modest limits to avoid huge payloads; page with `offset`. | |
| offset | No | Zero-based row offset for page N (skip first `offset` matches). Omit when starting from the first page. | |
| status | No | Lifecycle filter mapped to GraphQL `isFulfilled`: `ACTIVE` → `UNFULFILLED` (not yet fulfilled), `COMPLETED` → `FULFILLED`. | |
| resourceType | No | Restrict to `ENERGY` or `BANDWIDTH` orders; omit for both. | |
| isOnlyMyOrder | No | 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 omitted, return all orders on the market (no requester filter). |
Output Schema
| Name | Required | Description |
|---|---|---|
| orders | Yes | Matching orders for this page; may be large—use pagination inputs to chunk. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions pagination but does not specify read-only semantics, authentication needs, rate limits, or potential large result sets. Lacks critical safety context for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with no redundant words. However, it could be more structured or enumerated to improve scanability. Still, brevity is a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description lacks completeness for a 10-parameter tool with no schema descriptions. Key filters and pagination mechanics are unexplained, leaving agents to infer or guess. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It names only 4 out of 10 parameters (resourceType, isOwner, isMatching, sort options) while omitting explanation for limit, offset, fromId, myAddress, receivers, isFulfilled, and the structure of sortFilterBy. Partial coverage fails to make the tool usable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get order history' which is a specific verb and resource. Differentiates from sibling tools like tronsave_get_order (singular) by indicating list retrieval. Includes pagination and filter hints, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for listing orders through its description, but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_order for a single order, list_order_books for different data). No exclusion criteria or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_loginLogin SessionAInspect
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 | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Raw API key for internal-tools login. Provide EXACTLY ONE of `apiKey` or `signature`. | |
| signature | No | Signature token in `signature_timestamp` format (timestamp is the signed message). Provide EXACTLY ONE of `apiKey` or `signature`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| expiresAt | Yes | |
| sessionId | Yes | Session id to pass as mcp-session-id in subsequent calls. |
| walletAddress | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the prerequisite call, exact parameter format, and sessionId return. It does not mention rate limits or session expiry, but for a login tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 5 sentences, front-loaded with the main purpose. While clear, it could be slightly more condensed or structured, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existence of an output schema, the description fully covers the authentication flow, prerequisites, and usage modes. No gaps remain for effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3; the description adds value by explaining the exact format for signature (signature_timestamp) and that timestamp is the nonce, and that apiKey is for internal tools. This goes beyond the basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an authenticated server session and returns a sessionId. It distinguishes two login modes (wallet signature and apiKey), and is distinct from sibling tools which are all operational or management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use each mode: wallet signature for platform tools, apiKey for internal tools. It also provides a step-by-step protocol (call tronsave_get_sign_message first). However, it does not explicitly exclude incorrect usage scenarios or mention alternatives beyond the two modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_register_auto_sellRegister Auto SellAInspect
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 | Required | Description | Default |
|---|---|---|---|
| poolSetting | No | ||
| addOnFeature | No | ||
| paymentConfig | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | Yes | Opaque server-defined payload (tx id, setting id, or status text). Treat as identifier-or-message; rely on `message` for human routing. |
| message | Yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | Yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Register auto-sell settings' without mentioning side effects, whether it overwrites existing settings, authentication requirements, or rate limits. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, no wasted words. The first sentence states purpose and lists parameter groups; the second provides usage guidance. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 nested parameters, no schema descriptions, no annotations) and the existence of an output schema, the description covers purpose and usage but omits behavioral details like idempotency. It mentions checking current settings and using an update tool, which hints at behavior, but is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the three optional parameter groups (paymentConfig, poolSetting, addOnFeature) with brief notes like 'energy/bandwidth limits and reclaim' and 'vote, stake, suggestSell'. This adds context but lacks detail on nested fields. It is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Register auto-sell settings for the current user' which is a specific verb and resource. It distinguishes itself from sibling tools like tronsave_update_auto_sell_setting and tronsave_user_auto_setting_get by mentioning them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Check current settings with tronsave_user_auto_setting_get; use tronsave_update_auto_sell_setting for later changes.' This clearly indicates when to use this tool (first-time registration) and when not to (for updates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_sell_order_manualSell Order ManualADestructiveInspect
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 | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | Target order id (`MObjectId`) to manually fulfill. Should be an order eligible for seller-side manual execution. | |
| signedTx | Yes | Required wallet-signed transaction payload (TronWeb shape: `{ txID, raw_data, raw_data_hex, signature[] }`). Must come from client-side signing; never fabricate. | |
| paymentAddress | No | Optional payout/payment address override when settlement flow requires it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| message | Yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | Yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
| delegatedId | No | On-chain delegate id created by the manual sell when the underlying transaction is confirmed; null until confirmation lands. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses that it requires a signed delegate transaction and manual action, but does not detail error handling, side effects, or security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives actionable prerequisite. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered elsewhere. However, missing critical guidance on how to obtain signedTx (e.g., via tronsave_get_sign_message) and what exactly 'manual' entails, leaving gaps for a less experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all params documented). Description adds context by restating the prerequisite for orderId and specifying 'signed delegate transaction' for signedTx, which is marginally more specific than the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Manually fulfill a sell order' with specific resources (orderId, signedTx). Does not explicitly differentiate from sibling tools like tronsave_cancel_order or tronsave_create_order_onchain, but the action is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a prerequisite (call tronsave_order_detail first) but offers no guidance on when to use this tool versus alternatives, nor what conditions warrant manual fulfillment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_update_auto_sell_settingUpdate Auto Sell SettingAInspect
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 | Required | Description | Default |
|---|---|---|---|
| poolSetting | No | ||
| addOnFeature | No | ||
| paymentConfig | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| data | Yes | Opaque server-defined payload (tx id, setting id, or status text). Treat as identifier-or-message; rely on `message` for human routing. |
| message | Yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | Yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It mentions partial fields and same inputs as registration, but lacks details on merge behavior, permissions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and scope, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 complex nested parameters, no annotations, and an output schema, the description fails to explain behavior (merge/overwrite) or return values, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only names the top-level parameters without adding meaning beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('auto-sell configuration'), and distinguishes from the registration tool by specifying 'partial fields'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to read current values with a sibling tool before partial updates, implying when to use this tool and providing an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tronsave_update_orderUpdate OrderAInspect
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 | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | Target order id (`MObjectId`) to update. Order must still be open and editable. | |
| newPrice | No | Optional replacement unit price in SUN. | |
| receiver | No | Optional replacement receiver TRON address. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | GraphQL mutation status code (HTTP-like; `0`/`200` indicates success). Always pair with `success` for routing. |
| message | Yes | Human-readable status text. Populated even on success; localized error messages may appear here on failure. |
| success | Yes | Whether the mutation succeeded at the backend level. Always check this before reading `data`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It mentions 'update' implying a write operation, but does not specify side effects (e.g., whether the update is idempotent, what happens if orderId is invalid, or any authentication requirements). The description is too brief to fully disclose behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and key details. Every word is necessary, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values. It adequately covers the core purpose and parameter roles for a simple mutation tool. However, it could provide more context on behavioral outcomes (e.g., success/error handling) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by naming specific parameters (receiver and newPrice) and clarifying they support partial updates, which groups them meaningfully beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing order by orderId, and mentions partial updates on specific fields (receiver, newPrice). This distinguishes it from sibling tools like tronsave_cancel_order (cancel) and tronsave_create_order_onchain (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for updating existing orders and supports partial updates, but does not provide explicit guidance on when not to use it or suggest alternative tools for other operations. It lacks exclusions or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!