Skip to main content
Glama
Sign In

TronSave MCP Server

by io.tronsave.mcp
OverviewDiscussionsAdmin

Internal Account Information

tronsave_get_internal_account
Read-onlyIdempotent

Retrieve the Tronsave internal account profile for the current logged-in session (wallet/represent address, balances, deposit address). Requires an internal API key: tronsave_login (api-key mode, or signature mode for a wallet with an internal account) or an Authorization: ApiKey <key> client header. Never pass API keys as tool arguments; the server forwards the key from the session/header to TronSave. Use when the user needs their linked address or balance; for the full wallet profile use tronsave_get_user_info, for the ledger of deposits and payments tronsave_list_internal_transactions. Returns { id, balance (SUN string), representAddress, depositAddress }; any API key in the payload is masked. Read-only.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
idNoInternal account id.
apiKeyNoMASKED internal API key; the full key is never returned.
balanceNoInternal balance in SUN as a decimal string (TRX = SUN / 1e6).
depositAddressNoTRON base58 deposit address; send TRX here to top up the internal balance (min 10 TRX).
representAddressNoTRON base58 address that represents (owns) the internal account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changed
    • changedOutput schema / additionalProperties
      Previous value: -falseNew value: +{}
    • addedOutput schema / properties / apiKey
      Added value: +{
+  "anyOf": [
+    {
+      "description": "MASKED internal API key; the full key is never returned.",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "MASKED internal API key; the full key is never returned."
+}
    • addedOutput schema / properties / balance / anyOf
      Added value: +[
+  {
+    "description": "Internal balance in SUN as a decimal string (TRX = SUN / 1e6).",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / properties / balance / description
      Previous value: -"Amount in SUN"New value: +"Internal balance in SUN as a decimal string (TRX = SUN / 1e6)."
    • removedOutput schema / properties / balance / type
      Removed value: -"string"
    • addedOutput schema / properties / depositAddress / anyOf
      Added value: +[
+  {
+    "description": "TRON base58 deposit address; send TRX here to top up the internal balance (min 10 TRX).",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / properties / depositAddress / description
      Previous value: -"TRON base58 deposit address, used for deposit TRX to TronSave internal account"New value: +"TRON base58 deposit address; send TRX here to top up the internal balance (min 10 TRX)."
    • removedOutput schema / properties / depositAddress / type
      Removed value: -"string"
    • addedOutput schema / properties / id / anyOf
      Added value: +[
+  {
+    "description": "Internal account id.",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedOutput schema / properties / id / description
      Added value: +"Internal account id."
    • removedOutput schema / properties / id / type
      Removed value: -"string"
    • addedOutput schema / properties / representAddress / anyOf
      Added value: +[
+  {
+    "description": "TRON base58 address that represents (owns) the internal account.",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / properties / representAddress / description
      Previous value: -"TRON base58 represent address"New value: +"TRON base58 address that represents (owns) the internal account."
    • removedOutput schema / properties / representAddress / type
      Removed value: -"string"
    • removedOutput schema / required
      Removed value: -[
-  "id",
-  "balance",
-  "representAddress",
-  "depositAddress"
-]
  2. Changed5 schema fields changed
    • changedOutput schema / additionalProperties
      Previous value: -{}New value: +false
    • changedOutput schema / properties / balance / description
      Previous value: -"Account balance in SUN (string)."New value: +"Amount in SUN"
    • changedOutput schema / properties / depositAddress / description
      Previous value: -"TRON base58 deposit address for funding the internal balance."New value: +"TRON base58 deposit address, used for deposit TRX to TronSave internal account"
    • changedOutput schema / properties / representAddress / description
      Previous value: -"TRON base58 represent address (used as order requester)."New value: +"TRON base58 represent address"
    • addedOutput schema / required
      Added value: +[
+  "id",
+  "balance",
+  "representAddress",
+  "depositAddress"
+]
  3. Added
  4. Removed
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantive behavior the annotations cannot express: the auth requirement (tronsave_login internal API key in api-key or signature mode, or an Authorization: ApiKey client header), that the server forwards the key from session/header rather than accepting it as an argument, and that any API key in the payload is masked. These are exactly the operational facts an agent needs before calling a credentialed endpoint.

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?

Front-loaded with purpose, then auth, then sibling routing, then return shape — a sensible information hierarchy with no throwaway sentences. It is dense with parentheticals and repeats a return-shape summary that the output schema already supplies, which keeps it just short of ideal trimness.

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?

Despite having no input parameters, this is a credentialed, session-scoped read, and the description covers the auth paths, key-handling rule, masking behavior, and the sibling routing needed to pick it. With an output schema present, the brief return summary is a bonus rather than a necessity, so nothing an agent needs to invoke it correctly is missing.

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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. It does add one relevant constraint about argument handling (API keys must not be passed as arguments), but that is really auth guidance rather than parameter semantics.

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?

States a specific verb and resource ('Retrieve the Tronsave internal account profile for the current logged-in session') and immediately enumerates the contents (wallet/represent address, balances, deposit address). It explicitly distinguishes itself from the two nearest siblings, tronsave_get_user_info and tronsave_list_internal_transactions, so an agent can route correctly without opening a schema.

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

Usage Guidelines5/5

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

Gives a concrete trigger ('Use when the user needs their linked address or balance') and names both alternatives with the condition that selects them: full wallet profile to tronsave_get_user_info, deposit/payment ledger to tronsave_list_internal_transactions. It also states a hard exclusion — never pass API keys as tool arguments — which is actionable guidance rather than description filler.

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

All TronSave MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources