---

version: 1.0.1

updatedAt: 2026-05-08T09:55:00+07:00

---

TronSave MCP Server Quickstart

Introduction

mcp-tronsave-streamable is a production-oriented MCP server for the TronSave ecosystem. It exposes TronSave business operations as MCP tools over Streamable HTTP transport, with Redis-backed sessions and strong TypeScript + Zod contracts.

Core capabilities:

• Streamable MCP endpoint at /mcp (POST, DELETE; GET is intentionally disabled)
• Dual authentication model (ApiKey and Signature) with different permission scopes
• Redis-backed MCP/auth sessions
• Typed GraphQL and REST integrations
• Strict input/output schemas for all tools

---

Mission & Tool Categories

Mission Name

TronSave Unified Resource Operations

The server's mission is to provide one MCP interface for platform and internal TronSave operations (authentication, account data, order lifecycle, pricing/estimation, and delegate extension workflows).

Tool Categories (High-Level)

Category	Tool	Requires Login	Short Description
Platform Authentication & Identity	tronsave_get_sign_message	No	Optional helper: returns { message, timestamp } for clients that want a server-provided sign payload.
Platform Authentication & Identity	tronsave_login	No	Creates a server session using apiKey or signature_timestamp.
Platform Authentication & Identity	tronsave_get_user_info	Yes (Signature Session)	Retrieves authenticated user profile and linked internal account information.
Platform Authentication & Identity	tronsave_get_user_permissions	Yes (Signature Session)	Returns enabled permission operations for current user.
Platform Authentication & Identity	tronsave_get_user_auto_setting	Yes (Signature Session)	Reads current auto-sell/automation settings.
Platform Market, Orders & Resource Actions	tronsave_estimate_buy_resource	No	Estimates quote-like buy parameters before creating an order.
Platform Market, Orders & Resource Actions	tronsave_get_user_seller_energy_stats	Yes (Signature Session)	Returns seller-side energy/statistics snapshot.
Platform Market, Orders & Resource Actions	tronsave_get_order	Yes (Signature Session)	Fetches one order detail by id.
Platform Market, Orders & Resource Actions	tronsave_list_orders	No*	Lists orders with paging/filtering (onlyMyOrder requires signature session).
Platform Market, Orders & Resource Actions	tronsave_list_order_books	No	Returns public market order-book buckets.
Platform Market, Orders & Resource Actions	tronsave_get_min_price	No	Returns minimum estimated unit price for selected params.
Platform Market, Orders & Resource Actions	tronsave_list_extendable_delegates	No	Lists extendable delegate candidates for planning/discovery.
Platform Market, Orders & Resource Actions	tronsave_create_order	Yes (Signature Session at backend)	Creates a new market order (onchain / internal only).
Platform Market, Orders & Resource Actions	tronsave_sell_order_manual	Yes (Signature Session at backend)	Executes manual seller-side order fulfillment with signed tx.
Platform Market, Orders & Resource Actions	tronsave_cancel_order	Yes (Signature Session at backend)	Cancels an open order.
Platform Market, Orders & Resource Actions	tronsave_update_order	Yes (Signature Session at backend)	Updates editable fields on an open order.
Platform Automation & Key Management	tronsave_register_auto_sell	Yes (Signature Session)	Creates initial auto-sell configuration.
Platform Automation & Key Management	tronsave_update_auto_sell_setting	Yes (Signature Session)	Updates existing auto-sell configuration.
Platform Automation & Key Management	tronsave_generate_api_key	Yes (Signature Session)	Generates a new internal API key credential.
Platform Automation & Key Management	tronsave_revoke_api_key	Yes (Signature Session)	Revokes current internal API key.
Platform Automation & Key Management	tronsave_delete_auto_buy_setting	Yes (Signature Session)	Deletes one auto-buy rule by id.
Internal Operations	tronsave_get_internal_account	Yes (Session)	Gets internal account/balance details for the current session.
Internal Operations	tronsave_get_deposit_address	Yes (Session)	Returns deposit address for internal funding workflow.
Internal Operations	tronsave_internal_create_extend_request	Yes (Session)	Submits POST /v2/extend-request; requires REST extendData shape.

Note: "Requires Login = Yes" is not enough to determine access for platform tools. Check session type requirements below.

Authentication Session Matrix (Important)

tronsave_login can create two session types:

• ApiKey session (tronsave_login with apiKey)
  • Intended for internal operations.
  • Works for: tronsave_get_internal_account, tronsave_get_deposit_address, tronsave_internal_create_extend_request.
  • Does not satisfy tools that explicitly require "Signature Session".
• Signature session (tronsave_login with signature_timestamp)
  • Required for user-identity tools and most platform mutations.
  • Works for tools marked "Yes (Signature Session)" in this document.
  • Includes wallet-bound identity and permission context used by backend checks.

Security implication:

• If a session token (mcp-session-id) leaks, an attacker can act with the same effective rights until TTL expiry.
• Impact depends on session type:
  • leaked ApiKey session => internal-account scoped actions.
  • leaked Signature session => wallet-bound platform actions allowed by backend permissions.
• Treat both session IDs and upstream credentials as secrets.

---

Connection Guide by Framework

Before connecting from any framework:

1. Run the server (npm run dev or npm start).
2. Ensure Redis is running and env vars are configured.
3. Use one MCP URL:
   • Mainnet: https://mcp.tronsave.io/mcp
   • Testnet: https://mcp.tronsave.io/testnet/mcp

A) OpenClaw

Use an HTTP MCP server entry that points to /mcp:

{
  "mcpServers": {
    "tronsave-streamable": {
      "url": "https://mcp.tronsave.io/mcp",
    }
  }
}

Recommended auth flow:

• ApiKey flow: call tronsave_login with apiKey (raw key), then reuse returned mcp-session-id.
• Signature flow: call tronsave_login with signature_timestamp directly.
  Optional helper: call tronsave_get_sign_message first if your client wants a server-provided signable payload.

B) Claude Desktop

Configure Claude Desktop to use the same Streamable MCP endpoint:

{
  "mcpServers": {
    "tronsave-streamable": {
      "url": "https://mcp.tronsave.io/mcp",
    }
  }
}

Operational notes:

• Keep mcp-session-id consistent after login for stateful tool calls.
• For platform signature-required tools, establish a signature session first.
• Do not send private keys to the MCP server; signing must happen client-side.

C) Custom-Built Agent (Self-Hosted)

If you are building your own agent runtime and know nothing about MCP yet, follow this exact sequence.

Step 1: Initialize MCP session (POST /mcp)

Send JSON-RPC initialize first:

curl -i -X POST "https://mcp.tronsave.io/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2025-03-26",
      "capabilities": {},
      "clientInfo": {
        "name": "custom-agent",
        "version": "1.0.0"
      }
    }
  }'

Important:

• Read response headers and store mcp-session-id.
• You must reuse this mcp-session-id in all next requests.
• protocolVersion in this sample is a known compatible value at doc update time.
• Prefer using your MCP SDK's default/negotiated protocol version when available.
• If protocol versions are incompatible, initialize fails and client must retry with a supported version.

Step 2: Notify server client is ready (POST /mcp, recommended)

After initialize success, send notifications/initialized:

curl -i -X POST "https://mcp.tronsave.io/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: YOUR_SESSION_ID" \
  -d '{
    "jsonrpc": "2.0",
    "method": "notifications/initialized",
    "params": {}
  }'

Step 3: Login before calling protected tools (POST /mcp with tools/call)

You must login before calling any tool marked Requires Login = Yes. tronsave_login accepts one of two argument modes:

• ApiKey mode: send apiKey
• Signature mode: send signature (format: signature_timestamp)

Do not send both apiKey and signature in the same login call.

Access rule after login:

• ApiKey login: internal tools only.
• Signature login: required for any tool that says "Signature Session".
• If you call a signature-required tool from an ApiKey session, backend authorization will reject it.

ApiKey login example:

curl -i -X POST "https://mcp.tronsave.io/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: YOUR_SESSION_ID" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "tronsave_login",
      "arguments": {
        "apiKey": "YOUR_API_KEY"
      }
    }
  }'

Signature login example (direct signature mode):

curl -i -X POST "https://mcp.tronsave.io/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: YOUR_SESSION_ID" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "tronsave_login",
      "arguments": {
        "signature": "YOUR_SIGNATURE_YOUR_TIMESTAMP"
      }
    }
  }'

After login succeeds, continue using the same mcp-session-id.

Step 4: Get all available tools (POST /mcp with tools/list)

Use tools/list to discover tool names, input schema, and descriptions:

curl -s -X POST "https://mcp.tronsave.io/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: YOUR_SESSION_ID" \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/list",
    "params": {}
  }'

What you get from tools/list:

• Tool name (name)
• Human description (description)
• Required input fields (inputSchema)
• Output shape (outputSchema, when provided)

Step 5: Call a tool (POST /mcp with tools/call)

Pick one tool from tools/list, then call:

curl -s -X POST "https://mcp.tronsave.io/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: YOUR_SESSION_ID" \
  -d '{
    "jsonrpc": "2.0",
    "id": 4,
    "method": "tools/call",
    "params": {
      "name": "tronsave_get_internal_account",
      "arguments": {}
    }
  }'

For signature-required platform tools, do:

1. tools/call with name: "tronsave_login" using signature mode
2. Continue calling tools using returned mcp-session-id

Optional helper flow:

1. tools/call with name: "tronsave_get_sign_message"
2. Sign returned message in wallet
3. tools/call with name: "tronsave_login" and signature payload
4. Continue calling platform tools

Step 6: Close session (DELETE /mcp)

When finished:

curl -i -X DELETE "https://mcp.tronsave.io/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: YOUR_SESSION_ID"

Implementation checklist for robust agents:

• Always initialize MCP and login before calling tools marked Requires Login = Yes.
• Persist mcp-session-id per conversation/agent context.
• On SESSION_REQUIRED/stale-session/restart errors, re-run initialize + login flow.
• Always validate tool arguments against tools/list schemas before calling.
• Surface tool errors directly to users for easier troubleshooting.

---

Security Best Practices

• Never transmit wallet private keys or seed phrases to the server.
• Sign messages only in the wallet/client environment.
• Redis stores session payloads as JSON values; do not expose Redis publicly.
• Secure Redis in production:
  • bind to private network only (bind 127.0.0.1 or VPC-private IP)
  • enable auth/ACL (requirepass and user ACLs)
  • enable TLS in transit where supported
  • disable dangerous commands in managed-policy contexts when possible
  • enforce key TTL and eviction policy review for session keys
• If Redis is leaked/compromised, active sessions may be replayed until TTL expiration (session takeover risk).
• Keep SESSION_TTL_SECONDS as short as practical for your UX/security trade-off.
• Enforce authentication if exposing the server on public networks.