TRON Energy/Bandwidth MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools are generally well-differentiated with specific purposes covering distinct lifecycle stages (build/sign/broadcast patterns) and resource types. Minor potential confusion exists between register (agent auth) and register_pool (creating a selling pool), and the various get_order* tools, but descriptions clarify boundaries adequately.
Naming Consistency4/5
Follows consistent snake_case verb_noun patterns throughout (e.g., buy_energy, get_balance, configure_auto_selling). Minor deviations include abbreviation 'tx' in broadcast_signed_permission_tx versus full 'transaction' in broadcast_transaction, and bare 'register' versus verb_object elsewhere.
Tool Count3/5
At 27 tools, the set is heavy for the domain despite covering a complex blockchain resource trading workflow. While permission management necessitates separate build/sign/broadcast steps, and both swaps and voting are included, the count exceeds the typical 3-15 range for well-scoped servers and approaches the 'too many' threshold.
Completeness3/5
Covers CRUD operations for pools, auto-selling configuration, and order management, but has notable gaps: despite the server name and price endpoints supporting bandwidth, there is no buy_bandwidth tool (only buy_energy). Additionally, manual claim_rewards and cancel_order operations appear missing.
Average 3.9/5 across 24 of 27 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It states a read-only operation but does not disclose non-obvious behaviors such as authentication needs, rate limits, side effects, or response structure. It adds minimal context beyond the stated purpose.
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?
Two concise sentences with no fluff, front-loaded with the primary action. The description could have been expanded with relevant details without sacrificing brevity, so it is efficient though not maximally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional params, no output schema), the description is adequate but lacks completeness. It does not explain the return format or any pagination, which would be helpful for an agent. Sibling tools provide some context but the description alone is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it omits details on how 'durationMinutes' filters results or the effect of not specifying 'resourceType'. No examples or clarifications are provided.
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 the tool retrieves total available Energy and Bandwidth across active pools, specifying a concrete verb and resource. It is distinct from siblings like 'buy_energy' (purchase) and 'get_market_overview' (broader view), showing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking resource availability before purchase ('Shows how much resource can be purchased right now'), but it lacks explicit when-to-use or when-not-to-use guidance. No alternatives are named, though context from sibling tools suggests it's for querying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool returns delegation progress, but does not mention any side effects, permissions, or rate limits. Since it's a read operation, the omission is minor.
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?
Single sentence with no redundant information, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter; description adequately conveys purpose. No output schema is needed for this basic retrieval tool, but could mention that it returns status and progress.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter fully described in the schema as 'Order ID (UUID format)'. The description adds no additional meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed status including delegation progress, with a specific verb and resource. It distinguishes from sibling tools like 'get_orders' which likely lists orders, but does not explicitly differentiate from similar status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as 'get_orders' for listing or 'get_onchain_status' for on-chain details. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It states output format (price per unit in SUN) but lacks details like whether it's read-only, caching behavior, or authentication requirements. For a tool with no annotations, more transparency is needed.
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 extremely concise, consisting of two short sentences with no superfluous information. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description adequately hints at the return format. For a simple price fetch tool, the description is sufficiently complete, though it could benefit from mentioning any rate limits or data freshness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'resourceType' is well-described in the schema itself. The description adds no new meaning beyond reiterating the filter and default, so the baseline score of 3 is appropriate.
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 specifies the verb 'Get', the resource 'TRON Energy and Bandwidth minimum prices', and the scope 'all duration tiers'. It distinguishes itself from siblings like 'estimate_cost' or 'get_available_resources' by focusing on price retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'estimate_cost' for cost estimation). It fails to mention conditions or exclusions, leaving the agent to infer usage purely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: creates a market order, fills from pools, deducts balance. However, without annotations, it omits details on insufficient balance handling, response format, synchronicity, or fees. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no superfluous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a financial transaction tool with 5 parameters and no output schema, the description covers the essential process but lacks details on errors, response, and prerequisites. It is mostly complete for a straightforward purchase.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have descriptions in the schema (100% coverage), so the description adds minimal new information beyond restating the schema. Baseline score of 3 is appropriate.
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 the tool's action: purchasing TRON Energy for a target address via a market order. It specifies the resource type and that it deducts cost from the user's balance, distinguishing it from query tools like get_prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_available_resources or get_prices. It lacks prerequisites like checking balance or understanding pool availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates a read operation returning breakdown categories but does not disclose authentication requirements, rate limits, or what happens if no earnings exist. Some context is provided but incomplete.
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?
The description is a single concise sentence with front-loaded key information (verb, resource, breakdown). No extraneous words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides the return categories but lacks details on return format, pagination, or behavior for empty results. It is adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The description adds 'optionally filter by date range' which reinforces but does not add new meaning beyond the schema. Baseline score of 3 is appropriate.
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 the tool gets an earnings breakdown by pool, specifying three categories (total earned, pending payout, paid out) and optional date filtering. It is distinct from sibling tools like 'withdraw_earnings' or 'get_balance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving earnings data and mentions optional date filtering, but does not provide explicit guidance on when to use this tool over 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It lists the informational categories the tool returns (prices, availability, durations, etc.), which gives some insight into its scope. However, it omits critical behaviors such as whether the operation is read-only, whether it requires authentication, potential rate limits, response size, or performance implications. The description is adequate but not thorough.
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?
The description is a single, clear sentence with a list of components and a brief usage note. It is concise and front-loaded with the key purpose. While it could be slightly more structured (e.g., separated into purpose and output details), it contains no filler and efficiently conveys the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the content of the output but not its format or field names, which is significant since no output schema exists. The presence of several sibling tools (e.g., get_prices, get_available_resources, get_orders) creates a need for differentiation, but the description does not specify how this overview relates to those individual queries. It is somewhat complete but lacks depth in clarifying boundaries and return structure.
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 has zero parameters, so the schema provides no parameter details. In such cases, the baseline is 4, and the description adds value by describing the output content ('prices, availability, allowed durations...'). The description contributes meaning beyond the schema by contextualizing what the overview includes, which helps an agent interpret the results.
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 it provides a comprehensive market overview covering prices, availability, allowed durations, order constraints, and transaction types. It explicitly defines the resource ('market overview') and the verb ('get'). This distinguishes it from sibling tools like get_prices or get_available_resources, which focus on specific subsets. The added line 'Useful for agents to understand what they can purchase' clarifies the intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only suggests general applicability ('useful for agents to understand what they can purchase'), but provides no explicit guidance on when to use this tool versus its many siblings (e.g., get_prices, get_available_resources, get_orders). It does not mention prerequisites, alternatives, or scenarios where this tool is preferred or should be avoided. This absence makes it harder for an agent to decide which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states data is fetched directly from TRON blockchain (read operation), but fails to mention error handling, latency, rate limits, or what happens if the pool address is invalid.
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?
Two sentences, each adding value: first lists returned data, second explains source and requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists all returned fields, making it informative despite no output schema. However, it lacks details on error responses or response format, which would be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the only parameter (optional with default behavior). The tool description does not add extra meaning beyond 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool gets live blockchain state for a pool, listing specific data items (balance, frozen resources, voting status, rewards, delegations). It clearly distinguishes from siblings like get_balance or get_pool_delegations by being the comprehensive on-chain status tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (requires API key) but does not provide guidance on when to use this tool versus alternatives, such as when to use get_balance for a simpler query or get_pool_delegations for specific delegation info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only implies read operation but does not disclose authentication needs, rate limits, or behavior when no delegations exist. Minimal behavioral context beyond basic functionality.
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?
Two concise sentences, front-loaded with main action and resource, no filler. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains the tool's purpose and parameter behavior. No output schema, but return values are implied. Could mention pagination or limits, but overall complete for a simple filtering tool.
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?
Schema has 100% coverage for single parameter 'poolAddress' with description. Description adds that omitting it shows all pools, providing meaningful behavior beyond schema.
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?
Clearly states verb 'Get' and resource 'active delegations from your pools', with specific details on what information is shown (who received energy/bandwidth, expiry). Distinguishes from sibling tools focusing on other aspects like resources, balance, or transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or prerequisites, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the withdrawal is processed on-chain and may take a few minutes, which is useful. However, it omits potential fees, reversibility, failure handling, or confirmation details. The disclosure is adequate but not exhaustive.
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?
Two concise sentences: first states purpose, second gives minimum and timing. No wasted words. Front-loaded with the key action. Perfectly structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple withdrawal tool with one parameter and no output schema, the description covers the essential aspects: what, how much, and processing time. It is complete enough for an agent to use correctly. However, it could mention any post-withdrawal balance changes or confirmation responses, but those are implied or covered by other tools like get_balance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'amount' exists, and the schema already describes it as a number with exclusiveMinimum 0. The description adds the minimum of 100 TRX, which is helpful. Since schema coverage is 100%, baseline is 3; the description adds marginal value by restating the minimum but does not explain other aspects like precision or format.
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 the action: 'Withdraw TRX from your account balance to your wallet.' The verb 'withdraw' combined with resource 'earnings' and currency 'TRX' is specific and unambiguous. It distinguishes itself from sibling tools like 'buy_energy' or 'execute_swap' by focusing on withdrawal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the minimum withdrawal amount (100 TRX) but provides no guidance on when to use this tool vs alternatives. It does not specify prerequisites (e.g., sufficient balance, registered wallet) or when not to use it. The usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full behavioral disclosure burden. It states a mutation (update) but fails to disclose whether changes are immediate, require specific permissions, or affect existing active selling orders. No response behavior is described.
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?
Two sentences, no redundant phrases. Front-loaded with the action and key behaviors. Every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description covers the main operations but omits details like response format, error cases, or permission requirements. Adequate for basic use but incomplete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the description groups parameters thematically (toggle, set, duration) but adds minimal new meaning beyond the schema's individual parameter descriptions. Baseline 3 is appropriate.
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 the verb 'Update' and the resource 'auto-selling configuration', listing specific operations (toggle energy/bandwidth selling, set reserves, duration constraints). It distinguishes from sibling 'get_auto_selling_config' by implying this is the update counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'Pass the configId from get_auto_selling_config', providing a clear prerequisite. It implies when to use this tool (update) versus siblings (get), though it lacks explicit exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states that the tool returns a deposit address, but does not disclose whether it is idempotent, requires authentication, or has any side effects. Minimal transparency beyond the basic function.
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?
Single sentence, no extraneous words, directly states the tool's purpose. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is minimal. It tells what the tool does but lacks details like address persistence, usage instructions, or return format. Adequate for a straightforward tool but could be more informative.
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, and schema coverage is 100% vacuously. The description adds meaning by specifying that the deposit is for TRX, which provides context beyond the empty schema. Baseline for 0 parameters is 4.
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?
Description clearly states the tool gets a deposit address for topping up account balance with TRX. It uses specific verb 'Get' and resource 'deposit address', distinguishing it from sibling tools like get_balance or get_earnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for depositing TRX but does not explicitly state when to use or avoid, nor provides alternatives among siblings. Guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description transparently states behavior: returns recent orders sorted by creation time with optional status filter. It lacks disclosure on pagination or rate limits, but the core behavior is clear.
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?
The description is two concise sentences, well-structured and front-loaded. It is efficient but could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not fully explain what fields each returned order contains, leaving the agent partially uninformed about the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 'optional status filter', but this is already evident from the schema. No additional parameter semantics are provided.
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 'Get your order history', specifying the verb and resource, and distinguishes itself from 'get_order_status' by indicating it returns a list of recent orders with optional filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing order history, but does not explicitly state when to use it versus alternatives like 'get_order_status' for a single order, nor provides when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions broadcasting and verification but lacks details on side effects, failure modes, verification outcome, rate limits, or network fees. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no unnecessary words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. Description explains broadcast and verification but does not cover return values, success/failure criteria, or error handling. Partial coverage for a tool with a post-broadcast verification step.
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?
Both parameters have descriptions in schema (100% coverage). Description adds context: poolAddress as 'the pool address that the permission was granted on', signedTransaction as 'from tronWeb.trx.sign()', clarifying its source and structure.
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?
Description clearly states the verb 'broadcast' and the resource 'signed AccountPermissionUpdate transaction', and mentions verification. It distinguishes from siblings like 'build_permission_transaction' (build vs. broadcast) and 'broadcast_transaction' (generic vs. permission-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Use this after signing the transaction from build_permission_transaction', providing explicit prerequisite context. Mentions 'Requires authentication.' However, does not explicitly exclude alternatives or describe 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.
Behavior3/5
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 automatic selection of the best SR, permission requirements, and auto-claim of rewards. However, it does not describe side effects (e.g., overwriting previous votes), error handling, or the result of the action. More detail would be beneficial.
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 concise (three sentences), front-loaded with the core purpose, and each sentence contributes unique information (action, prerequisites, reward behavior). No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action tool with no output schema, the description covers purpose, prerequisites, and one behavioral aspect. However, it lacks information about the return value, what happens if voting fails, or the impact on existing votes. Completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (poolAddress), which already explains its purpose and default behavior. The tool description adds no further parameter details beyond what the schema provides, so it meets the baseline but does not exceed it.
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 the action ('Vote'), the resource ('Super Representative (SR)'), and the selection criterion ('highest APY'). It also mentions the goal of earning voting rewards. The tool is distinct from sibling tools, none of which involve voting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisites (VoteWitness permission, API key) and mentions auto-claim behavior. It implies when to use (to earn rewards) but does not explicitly exclude alternative tools or scenarios. However, no sibling tool serves the same purpose, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It implies a read-only calculation with no side effects, which is transparent. It could explicitly state that no resources are purchased or modified, but the current description is sufficient for a simple estimation tool.
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?
The description is a single sentence that front-loads the main action. It is efficient, though it could be slightly reworded to include key parameter defaults for completeness. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values. It mentions 'get the energy needed and cost in TRX,' which gives a general idea but lacks detail (e.g., whether it returns a single value or both, units). For a simple estimation, this may be adequate, but it could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds that inputs include transaction count and type, but does not elaborate on defaults or e-num constraints beyond what the schema provides. Thus, it adds minimal additional meaning, meeting the baseline of 3.
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 the tool's purpose: 'Calculate the cost of purchasing TRON Energy or Bandwidth.' It specifies the verb (calculate), the resource (cost of energy/bandwidth), and the inputs (transaction count and type). This effectively distinguishes it from sibling tools like buy_energy or get_prices, which involve actual purchases or price lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need to estimate cost before purchasing. It mentions providing transaction count and type. However, it does not explicitly state when not to use it or list alternatives, leaving room for improvement in guiding the agent to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It notes the API key requirement, which is useful, but does not disclose other behavioral aspects such as read-only nature (implied by 'get'), rate limits, or data freshness.
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 sentence that immediately states the tool's purpose and key features. Every word is necessary, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description covers the main purpose and prerequisites adequately. However, it lacks details on return format or whether data is real-time, which could be improved.
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?
There are no parameters (0), so the schema alone provides no parameter info. The description adds value by listing the specific statistics included, which helps the agent understand the output beyond an empty schema.
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 the tool retrieves comprehensive statistics for energy/bandwidth pools, listing specific metrics (delegations, revenue, utilization, APY). This distinguishes it from sibling tools like get_pool_delegations or get_earnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this tool over alternatives. It implies broader coverage via 'comprehensive,' but lacks explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool returns an unsigned transaction for client-side signing and requires an API key. However, it doesn't disclose potential side effects, idempotency, or what happens in error cases. For a quoting tool, the safety profile is less critical, but the description could be more transparent about the lack of state modification.
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 concise with three sentences, front-loaded with the main purpose, and every sentence adds value. There is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and 4 parameters, the description covers the purpose, usage guidance, and basic return type (unsigned TX). It could be slightly improved by mentioning what data the quote includes (e.g., expected output amount, price impact) or any time limit on the quote, but it is largely complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters, so the baseline is 3. The description does not add additional semantics beyond what the schema already provides for the parameters; it only adds context about API key requirement and usage flow.
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 it retrieves a price quote and unsigned transaction for swapping tokens on SunSwap DEX. It distinguishes itself from the sibling tool 'execute_swap' by specifying that this tool is for getting the quote and unsigned TX, while the other handles submission after signing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: use this tool to get an unsigned TX, then sign it client-side and submit via 'execute_swap'. It also mentions the requirement for an API key. However, it doesn't explicitly state when not to use this tool or discuss alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, description discloses key behavior: auto energy delegation before broadcast and different modes based on authentication. However, lacks details on failure states or permissions needed.
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?
Two sentences, front-loaded with main purpose, no extraneous information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main functionality and modes but does not describe return value for authenticated broadcast (only cost estimate for unauth). With no output schema, this is a gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter txData is well-described in schema (100% coverage). Description adds context ('pre-signed transaction with auto energy delegation') but does not significantly extend schema meaning. Baseline 3 is appropriate.
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?
Description clearly states the verb 'broadcast' and resource 'pre-signed TRON transaction', and distinguishes by mentioning auto energy delegation, setting it apart from siblings like broadcast_signed_permission_tx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (pre-signed transaction needing delegation), authentication methods (API key or USDC), and behavior without authentication (cost estimate). Could be more explicit about alternatives but provides good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses it returns unsigned transaction, requires authentication, and preserves permissions, but does not detail failure modes or side effects.
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?
Three concise, front-loaded sentences with no wasted words, efficiently conveying purpose and workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it specifies returns unsigned transaction. Workflow context with sibling broadcast tool is clear, but could mention what happens if not signed.
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?
With 100% schema coverage, description adds context: includeVote defaults to true, poolAddress is T-address format, enhancing parameter meaning.
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 specifies the tool builds an AccountPermissionUpdate transaction for granting PowerSun platform permissions, distinguishing it from sibling tools like broadcast_signed_permission_tx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear instructions: sign with private key and broadcast using sibling tool. Mentions that existing permissions are preserved, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses required/optional permissions and API key requirement. Implicitly read-only. With no annotations, adds necessary behavioral context.
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?
Three sentences, each earning its place: purpose, permissions list, and usage tip. Front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete enough for a simple verification tool. Covers when to run, what is checked, and a requirement. Minor gap on return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The description adds minimal extra meaning beyond pointing to the parameter.
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 the verb (verify) and resource (permissions on pool address), lists specific permissions, and distinguishes from sibling tools like build_permission_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Run this after granting permissions to confirm the platform can operate your pool.' No explicit alternatives or exclusions, but adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions automatic energy delegation before broadcast and payment methods. However, it does not cover failure states, idempotency, or side effects beyond delegation.
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?
Three sentences, no fluff, front-loaded with the action. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and detailed input schema, the description covers the essential workflow and payment options. Could mention broadcast confirmation or error handling, but it is fairly complete for its complexity.
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?
Schema coverage is 100% with a description for txData. The description adds workflow context ('Get the unsigned TX... sign it, and submit here'), clarifying the purpose of the parameter beyond the schema.
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 it executes a pre-signed swap transaction with automatic energy delegation, distinguishing it from generic broadcast tools like broadcast_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly outlines the workflow: get unsigned TX from get_swap_quote, sign it, submit here. Also notes payment methods (API key or x402 USDC). Does not explicitly state when not to use, but sufficient context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description indicates read-only behavior ('View execution history'), lists output fields, and notes authentication requirement. Lacks mention of pagination or error cases but sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose and scope, second lists output and requirement. No redundant words, efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explicitly mentions returned fields (status, amounts, hashes, timestamps), authentication, and pool scope. Lacks detail on default behavior for omitted poolAddress but schema covers that. Adequate for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and description does not add significant meaning beyond the schema's parameter descriptions. Baseline score of 3 is appropriate as the schema already documents parameters.
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?
Description clearly states it views execution history of automatic actions for a pool, listing specific action types and output fields. This distinguishes it from sibling tools that perform manual actions or configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Requires API key' and implies use for pool's auto-action history. While no explicit exclusions or alternatives, the context is clear and it's the only tool for this specific purpose among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates a read operation ('Get') and mentions the authentication requirement. However, it does not detail the response format, potential rate limits, or data freshness, but given the tool's simplicity (no parameters, no side effects), this is sufficient.
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 extremely concise—two short sentences. The first sentence immediately states the purpose, and the second adds an important requirement. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers what the tool does (get TRX balance and deposit info) and a key requirement (API key). It could be improved by clarifying the deposit information scope, but overall it is sufficient for an agent to invoke correctly.
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 has zero parameters, so the baseline is 4 per the guidelines. The description correctly implies no input is needed, matching the input schema which is 100% covered.
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 the tool's function: 'Get your current TRX balance and deposit information.' It uses a specific verb 'Get' and identifies the resource. This distinguishes it from sibling tools like get_available_resources or get_market_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires API key authentication') but provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest other tools for different purposes, which is a missed opportunity given the list of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description explicitly says 'Get' indicating read-only. Mentions output details (resources, duration, reserves) without hiding mutations. No side effects implied.
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?
Single sentence that efficiently communicates purpose and return content, with no filler or redundancy.
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 zero parameters and no output schema, the description fully covers what the tool does and returns. Sibling tools confirm this is a read operation, so no gaps.
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 in schema, so description cannot add value there. Baseline 4 for zero-param tool.
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?
Clearly states it gets auto-selling configuration for pools, listing specific return fields (resources, duration constraints, reserves). Distinct from sibling tools like configure_auto_selling and get_auto_action_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied use for reading config vs. writing (configure_auto_selling) but no explicit when-not or alternatives. Context signals show no required parameters, so usage is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool creates a pool and auto-selling configuration, requires subsequent permission granting, and requires an API key. Without annotations, this is sufficient for a registration tool. Could be improved by mentioning if it is idempotent or destructive.
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?
Three sentences, front-loaded with the main purpose. Each sentence adds value: purpose, requirement, and verification step. No wasted words.
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 no output schema and moderate complexity, the description covers the registration process, necessary permissions, and verification step. References sibling tool for checking permissions. Complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. Description only mentions paymentAddress, adding no extra meaning to the other three parameters. Baseline score of 3 is appropriate.
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?
Clearly states the verb 'register' and the resource 'TRON address as an energy/bandwidth selling pool'. Distinguishes from sibling tools like check_pool_permissions and configure_auto_selling by specifying it creates the pool and auto-selling configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit post-registration steps (grant permissions, use check_pool_permissions) and mentions API key requirement. Lacks explicit when-not or alternatives, but the context of sibling tools makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the registration flow and authentication requirements (none needed initially). Missing details on error states or expiration, but overall provides sufficient behavioral context.
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?
Two sentences, efficiently conveying purpose, steps, and dependency on sibling tool. No wasted words.
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 single parameter and no output schema, the description fully explains the registration process, including next steps and the required signing method. Context is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds no new info beyond schema's own description for 'address' (both say 'Your TRON wallet address (T-address format, 34 characters)'). Schema coverage is 100%, so baseline is 3; description doesn't elevate it further.
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?
Description clearly states the tool starts registration by providing a TRON address, returns a challenge string to sign, and links to verify_registration. Distinguishes from sibling verify_registration by explicitly mentioning it.
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 step-by-step process: provide address, sign challenge with tronWeb.trx.signMessageV2(), then call verify_registration. Also states 'No authentication required', guiding correct usage and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns an API key, upgrades the session to authenticated, and that no authentication is required to call it. It also notes that after verification, authenticated tools work in the session without reconnecting. This is good behavioral context for a state-changing tool.
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?
Three concise sentences, front-loaded with the primary purpose. No redundant or unnecessary information. Every sentence adds value.
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?
No output schema, but description states it returns an API key. Explains the before/after state of the session. Parameters are fully documented in schema with additional context from description. Sufficient for an agent to understand how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions, and the tool description adds valuable context: 'address' must match the register call, 'signature' is from tronWeb.trx.signMessageV2, and 'challengeId' comes from the register tool. This explains the workflow and parameter origins beyond the schema.
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 the tool's purpose: 'Complete agent registration by verifying your signed challenge. Returns an API key and upgrades the current session to authenticated.' It identifies the resource (agent registration) and the action (verify) with specific outcomes. Differentiates from siblings like 'register' by explaining it's the verification step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: after 'register', before using authenticated tools. It lists examples of tools that become available ('buy_energy, get_balance, register_pool, etc.'). No explicit when-not or alternatives, but given the sequential nature of registration, it's sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![powersun-tron-mcp MCP server](https://glama.ai/mcp/servers/Hovsteder/powersun-tron-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Hovsteder/powersun-tron-mcp)

Score Badge

Copy to your README.md:

[![powersun-tron-mcp MCP server](https://glama.ai/mcp/servers/Hovsteder/powersun-tron-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Hovsteder/powersun-tron-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hovsteder/powersun-tron-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server