TronSave runs a live MCP server at https://mcp.tronsave.io/mcp. Point an MCP-capable AI assistant at it and the assistant gets 29 tools for the TronSave market — price a rental, read the order book, place and cancel orders, extend delegations, configure auto-sell, manage API keys. Your private key never goes anywhere near it: every signature happens client-side, in your own wallet.
What MCP is, in one paragraph
The Model Context Protocol is a standard way to hand an AI assistant a set of callable tools. Instead of the model guessing at an API from documentation, the server publishes typed tool definitions and the client calls them. Practically, it is what turns “explain how to buy TRON energy” into “buy me 65,000 energy for an hour, but check the price first.”
TronSave ships two separate integrations. The MCP server is the full one, aimed at desktop assistants and agent frameworks. The WebMCP integration is a small, deliberately read-only set of tools the web app offers to in-browser agents. They are covered separately below because their safety models are not the same.
Endpoints
| Network | Endpoint |
|---|---|
| Mainnet | POST https://mcp.tronsave.io/mcp |
| Testnet | POST https://mcp.tronsave.io/testnet/mcp |
The network is chosen by which endpoint you connect to — there is no network parameter to get wrong. Both respond to a standard MCP initialize handshake and advertise the same tool set, so you can develop an agent against the testnet and move it to mainnet by changing one URL.
In a client that reads a JSON config, that is all the setup there is:
{
"mcpServers": {
"tronsave": {
"url": "https://mcp.tronsave.io/mcp"
}
}
}Logging in — and why there is no anonymous mode
Every tool call requires a session. This is worth stating clearly because it is easy to assume market data is open: call a price tool without logging in and the server returns SESSION_REQUIRED, not a quote. tronsave_login accepts exactly one of apiKey or signature — neither, or both, is rejected.
The signature route is the one TronSave prefers, and it is required for the platform tools:
1. tronsave_get_sign_message -> { message, timestamp }
2. (sign `message` in your own wallet, client-side)
3. tronsave_login { signature: "<signature>_<timestamp>" }
-> { sessionId, walletAddress, ... }
4. every later request: mcp-session-id: <sessionId>Note step 2. The server issues a message; you sign it in your wallet and send back only the signature. Never send a private key to the server — the protocol never asks for one, and any tool or client that does is not TronSave’s.
The API-key route is simpler and suits headless jobs, but it scopes you to the internal-account tools rather than the full platform set.
Two tool families
| Family | Count | Backed by | What it reaches |
|---|---|---|---|
tronsave_* |
22 | GraphQL market | Market discovery plus signature-session mutations: create, cancel and update orders, auto-sell, API keys. |
tronsave_internal_* |
7 | REST, api-key account | Estimate, create, history, details, order book and extend — all scoped to your deposited internal balance. |
The split matters for how an agent spends money. Internal-account tools draw on a balance you deposited in advance, which is a natural spending cap: an agent working through that family can only ever spend what you funded. Platform mutations go through your signature session instead.
What the 29 tools cover
| Area | Tools |
|---|---|
| Session & auth | get_sign_message, login |
| Account | get_user_info, get_internal_account, get_deposit_address, get_user_permissions |
| Pricing & depth | get_min_price, list_order_books, estimate_buy_resource, internal_order_book, internal_order_estimate |
| Orders (platform) | create_order, get_order, list_orders, cancel_order, update_order |
| Orders (internal) | internal_order_create, internal_order_history, internal_order_details |
| Extend | list_extendable_delegates, internal_extend_delegates, internal_create_extend_request |
| Selling | sell_order_manual, register_auto_sell, update_auto_sell_setting, get_user_auto_setting |
| API keys | generate_api_key, revoke_api_key |
| Auto-buy | delete_auto_buy_setting |
(All names carry the tronsave_ prefix; it is dropped in the table for width.) The extend tools are worth knowing about before an agent starts buying repeatedly — extending an existing delegation is usually cheaper than placing a fresh order.
Two of those deserve a flag before you let an agent loose. revoke_api_key immediately breaks every future request using the previous key, and delete_auto_buy_setting permanently stops all future executions of a rule. Both are documented as having exactly those side effects — they are not reversible by re-running the tool.
The freshness rule that will bite you
This is the single most important operational detail, and the server states it in its own instructions: market prices and availability change roughly every 3 seconds — one TRON block. Re-run your estimate or order-book read immediately before creating or updating an order, and never reuse a quote more than a few seconds old.
It matters more with an AI agent than with ordinary code, because a model may spend several seconds reasoning between reading a price and acting on it. An agent that quotes, thinks, explains its plan, and then orders is working from a stale number. If you are writing the prompt, make “re-check the price right before you order” an explicit instruction rather than assuming it.
Two conventions to keep straight while you are at it: all prices are in SUN (1 TRX = 1,000,000 SUN) and all durations are in seconds.
The browser side: WebMCP
The TronSave web app separately exposes a much smaller tool set to in-browser AI agents through the experimental navigator.modelContext API. The design here is conservative by intent, and the three tools are the whole surface:
- Overview — what TronSave is, its key pages, and how to reach the API programmatically.
- Resource price — the current estimated minimum unit price in SUN plus the estimated TRX cost for an amount. Explicitly read-only.
- Open page — client-side navigation to a known page. It never signs or sends a transaction.
There are no money-moving or signing tools in the browser set — that is a deliberate line, not an oversight. Anything that spends requires explicit wallet interaction from you. The integration is also feature-detected, so on a browser without the API it does nothing at all, and it withdraws its tools when the page unmounts rather than leaving a stale set advertised.
A sane safety model
If you are giving an agent access to something that spends money, the boundaries are worth being deliberate about:
- Start on the testnet endpoint. Same tools, no real TRX.
- Prefer the internal-account family for autonomous work. A funded balance is a hard ceiling on what an agent can spend.
- Use a dedicated API key you can revoke without disturbing anything else.
- Keep signing manual for anything large. The signature stays in your wallet by design; do not engineer that away.
FAQ
Which AI clients can use this?
Any MCP client that can connect to a remote server over HTTP — Claude Desktop and Claude Code among them, plus agent frameworks with MCP support. The server speaks the standard protocol, so nothing TronSave-specific is needed on the client.
How would an agent find this on its own?
Through the discovery files TronSave publishes — llms.txt, an API catalog, MCP server card and agent-skills manifest under /.well-known/. They point an agent at this endpoint without anyone pasting a URL.
Do I need an API key, or is a wallet enough?
Either works for logging in, but they reach different things. A wallet signature is required for the platform tools; an API key scopes you to the internal-account tools. You can generate and revoke keys through the server itself.
Can the server sign transactions for me?
No, and that is the point. Signing is always client-side. The server issues a message to sign and accepts the resulting signature — it never handles your key.
Can I try it without spending real TRX?
Yes. Connect to the testnet endpoint instead of the mainnet one. Everything else about the integration is identical.
Is market data available without logging in?
No. Every tool call needs a session, including price and order-book reads. Log in first, even for read-only work.
How does this compare to the SDKs?
The official SDKs are for code you write and control, and the REST API sits under both. MCP is for handing capability to an assistant that decides what to call. For a deterministic backend pipeline, use an SDK; for exploration, ops assistance, or an agent that reacts to conditions, MCP fits better. They all hit the same market.
Bottom line
An AI assistant that can read the TronSave order book and place an order is a genuinely useful thing to have when you are running a payout pipeline or watching energy prices. The integration is built with the right instincts — signing stays client-side, the browser tools cannot spend, and the internal-balance family gives you a natural cap. Start on the testnet endpoint, teach your agent to re-check prices before it orders, and keep the irreversible tools out of reach until you trust it.
Connect an agent: point your MCP client at https://mcp.tronsave.io/testnet/mcp to experiment, then switch to the mainnet endpoint and watch it price against the live energy market.
TronSave publishes this blog and operates the MCP server described here. Tool names, counts, and behaviour reflect server version 1.0.0 at the time of writing and can change — call tools/list for the current set. Giving an AI agent access to tools that spend funds carries risk; start on the testnet and scope credentials tightly. This is not financial advice.
