TronSave MCP Server

Generate API Key

tronsave_generate_api_key

Destructive

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 and stop using 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON 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. For `revokeApiKey`: server-defined confirmation string (no key material).
`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`.

TDQS

A4.9/5.0

Behavior5/5

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

Adds significant context beyond annotations: 'Side effect: issues secret material; not idempotent — each call mints a fresh key', rotation behavior, security warnings (never log raw keys). No contradiction with annotations (destructiveHint=true, idempotentHint=false).

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

Conciseness5/5

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

The description is a single paragraph of 4-5 sentences, front-loaded with purpose, then provides usage, behavioral notes, and security warnings. Every sentence adds value, no waste.

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?

Given the complexity (generating secrets, side effects, security), the description covers output ('Returns `data` containing the issued key'), prerequisites, safety warnings, and rotation advice. Output schema exists and description complements it.

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?

No parameters exist, so schema coverage is 100% by default. Baseline for 0 params is 4; the description adds no parameter-level info but the tool has none, so no deduction.

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

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Generate a new internal API key credential for the current user', specifying the verb 'generate' and resource 'API key credential'. It distinguishes from siblings like `tronsave_revoke_api_key` (revoke) and `tronsave_login` (login) by focusing on key generation.

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?

Provides explicit guidance: store key securely, pass to `tronsave_login` for access, treat old keys as rotated. Also mentions prerequisites (signature session, `mcp-session-id`) and implicitly when to use (when a key is needed) versus not (e.g., revocation).

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 tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, with some overlap between signature-based and internal API-based variants (e.g., create_order vs internal_order_create). Descriptions are thorough and help disambiguate. The minor overlap is justified by different authentication methods.

Naming Consistency5/5

Tool names follow a consistent 'tronsave_verb_noun' pattern with clear segmentation (e.g., get/list for retrieval, create/update/cancel for mutations). Internal tools use a consistent 'internal_' prefix. No mixing of conventions.

Tool Count4/5

29 tools is on the higher end but appropriate for a DeFi platform covering multiple resource types, order management, auto-settings, internal accounts, extensions, and authentication. A few tools could be merged (e.g., estimate variants) but overall scope justifies the count.

Completeness3/5

Major operations (CRUD for orders, auto-sell settings, internal account) are covered. Notable gaps include missing create/update tools for auto-buy rules (only delete exists) and limited history for signature-based orders (only internal order history available).

Resources

Need Help?