mcp-server-tron

Server Quality Checklist

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

Latest release: v1.1.7
Disambiguation2/5
Many tools have overlapping purposes, especially block queries (get_block, get_latest_block, get_block_by_num, get_block_by_id, get_block_by_latest_num, get_block_by_limit_next) and transaction queries (get_transaction, get_transaction_info, get_transaction_by_id, get_transaction_info_by_id). While descriptions attempt to differentiate, the sheer number of similar functions makes it difficult for an agent to reliably choose the correct one.
Naming Consistency3/5
The naming largely follows a snake_case verb_noun pattern (e.g., get_balance, list_witnesses, create_proposal), but there are inconsistencies such as get_now_block vs get_latest_block vs get_block_by_latest_num, broadcast_hex vs broadcast_transaction, and inconsistent use of 'v2' suffixes (get_delegated_resource vs get_delegated_resource_v2). Mixed prepositional phrases and varying noun forms reduce predictability.
Tool Count1/5
With 97 tools, the server is extremely over-scoped. The calibration indicates that 50+ tools is an extreme mismatch, and this server far exceeds that. Many tools appear redundant or overly granular, making the set unwieldy for an agent to navigate effectively.
Completeness4/5
The tool set covers an extensive range of TRON functionalities: wallet management, blocks, transactions, contracts, staking, delegation, accounts, witnesses, proposals, events, and indexed data. It is nearly comprehensive, though minor gaps exist such as a full transaction simulation tool (only energy estimation is provided) and some potential missing governance features.
Average 3.9/5 across 97 of 97 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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?
The description adds no behavioral context beyond what annotations already declare (destructiveHint=true, idempotentHint=false). It does not mention that broadcasting is irreversible, requires a properly signed transaction, or what happens on network rejection. The bar is lower because annotations exist, but the description still fails to provide meaningful operational 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 concise sentences, front-loaded with the core action. Every word contributes meaning, and there is no redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, irreversible network operation, the description is notably sparse. It lacks information about return values, error cases, or the irreversible nature of broadcasting. With no output schema and minimal annotations, the description should compensate, but it does not.
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 adds marginal value by clarifying the transaction format as a 'full signed transaction JSON object', though this slightly conflicts with the schema's 'JSON string' type. No additional meaning is provided for the 'network' parameter.
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 action (broadcast) and the resource (signed transaction) to the TRON network, making the purpose unambiguous. It implies a distinction from broadcast_hex by specifying 'full signed transaction JSON object', though it does not explicitly name alternatives.
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 is provided on when to use this tool versus alternatives like broadcast_hex or create_transaction. The description only states what it does, not the conditions or prerequisites for using it.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds no behavioral context beyond that, such as network default, error conditions, or what fields are returned. It neither contradicts the annotations nor enriches them.
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?
A single, front-loaded sentence. Every word is necessary for the basic purpose, with no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with no output schema and many closely related siblings. It does not explain what 'transaction details' includes, nor does it differentiate from get_transaction_info or get_transaction_by_id. The optional network parameter is only in the schema, not synthesized into the description.
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 includes descriptions for both txHash ('Transaction hash') and network ('Network name. Defaults to mainnet.'), covering all parameters. The description's phrase 'by transaction hash' aligns with the schema but adds no additional semantic nuance, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource ('transaction details') with the lookup key ('by transaction hash'). However, it does not distinguish from sibling tools like get_transaction_info or get_transaction_by_id, which appear to serve similar purposes.
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_transaction_info or get_transaction_by_id. There is no mention of use cases, prerequisites, or exclusions.
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?
The description only repeats the input method (by number or hash) which is already in the schema. It adds no behavioral context beyond the annotations (readOnlyHint, idempotentHint, etc.). Since annotations already cover safety, the description contributes nothing further, but it does not contradict them.
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, concise sentence that immediately states the tool's purpose and input types. There is no filler or redundancy.
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 is simple (2 params, no output schema) and annotations cover safety, so the minimal description is somewhat adequate. However, with numerous sibling tools and no mention of what 'block details' include or return format, the context is incomplete for an agent to fully understand the tool's place.
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 both parameters (network and blockIdentifier), so the schema already explains the inputs. The description adds no extra meaning beyond what the schema provides, earning the baseline score.
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 action (Get) and resource (block details) and specifies the input types (block number or hash). However, it does not distinguish from sibling tools like get_block_by_num or get_block_by_id, so it stops short of a 5.
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?
There is no guidance on when to use this tool versus the many sibling block-related tools (get_block_by_num, get_block_by_id, get_latest_block, etc.). No exclusions, alternatives, or context are provided, leaving the agent to guess.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. However, the description adds no additional behavioral context, such as whether the block is finalized/pending, error conditions, or return format. It simply restates the tool name 'now' as 'current latest,' offering no new information beyond annotations and schema.
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 of eight words, with no filler or redundant phrasing. It is extremely concise and directly states the core action.
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?
This is a simple read-only tool with one optional parameter, no output schema, and good annotation coverage. However, given the large number of sibling block-retrieval tools, the description lacks enough context to help an agent select it confidently. It neither explains how it differs from similar tools nor describes any edge-case behavior, leaving some ambiguity.
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 schema has 100% coverage for the single parameter 'network' with a clear description ('Network name. Defaults to mainnet.'). The tool description itself does not mention the network parameter, so it adds no extra semantic value. Baseline of 3 applies because the schema carries the full parameter documentation.
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 uses the specific verb 'Get' with a clear resource ('current latest block information') and scope ('from the network'). It is clear and unambiguous, but it does not distinguish this tool from siblings like get_latest_block or get_block_by_latest_num, so it does not fully meet the 'distinguishes from siblings' criterion.
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. With many sibling block-related tools (e.g., get_latest_block, get_block_by_latest_num, get_block_by_num), the lack of any usage context or exclusions is a significant gap.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the write nature is known. However, the description adds no behavioral context beyond the annotations, such as irreversibility, network fees, or whether the transfer originates from the currently selected wallet. It fails to disclose any additional side effects or safety considerations.
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, well-formed sentence that directly states the purpose. It is concise and easy to parse, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks important context for a destructive, non-idempotent operation. It does not explain the return value (e.g., transaction hash), the behavior when the optional amount is omitted, or the implications of the network parameter. This is especially problematic given the openWorldHint and no output schema.
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 covers all three parameters with descriptions (e.g., 'Amount to send in TRX (e.g., 10.5)', 'Network name. Defaults to mainnet.'), so the schema carries the burden. The description only aligns with the 'to' parameter and adds no extra meaning about amount or network.
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 'Transfer TRX to an address' clearly states the action (transfer), resource (TRX), and destination (an address), distinguishing it from siblings like transfer_trc20 (which sends TRC20 tokens) and withdraw_balance (which likely withdraws from a contract). It is specific and unambiguous.
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?
There is no guidance on when to use this tool versus alternatives or any prerequisites such as needing a selected wallet or sufficient balance. The description does not mention when not to use it or suggest any other tool for related operations.
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?
The description repeats the readOnlyHint from annotations without adding any new behavioral context. It does not describe return behavior, error handling, ABI fetching behavior, or any side effects. Annotations already cover safety, but the description contributes no additional transparency.
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 concise sentence with no unnecessary words. It front-loads the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no output schema, and many sibling tools with overlapping functionality (multicall, fetch_contract_abi, get_contract), this one-line description is insufficient. It does not explain what the function returns, when to use it versus alternatives, or how it handles missing ABIs.
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 descriptions cover all five parameters (abi, args, network, functionName, contractAddress) with useful details, so the baseline is 3. The tool description itself adds no parameter semantics beyond that.
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 identifies the tool as calling read-only functions on a smart contract. The 'read-only' qualifier distinguishes it from write_contract and deploy_contract, and it clearly specifies the resource (smart contract) and action (call functions).
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. It does not mention that write operations should use write_contract, nor does it clarify when to use multicall or fetch_contract_abi. Lacks any contextual cues beyond the basic purpose.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety. The description adds the specific scope of reading TRX balance, but does not go beyond what annotations and the schema already convey.
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 concise sentence, front-loaded with the action and resource. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-described parameters and complete annotations, the description is functional. However, given the large sibling list with similar balance tools, a brief note on when to prefer this tool would improve 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?
Schema description coverage is 100% for both parameters, with the schema describing address format and network default. The tool description does not add additional parameter semantics, so the baseline of 3 applies.
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's function with a specific verb ('Get') and resource ('TRX balance for an address'). It implicitly distinguishes from sibling token balance tools by specifying TRX, but does not explicitly name alternatives.
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 is given on when to use this tool versus alternatives. With siblings like get_token_balance and get_account_balance present, the description lacks exclusions or contextual direction.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds the output categories (receipt/confirmation status, energy usage, logs), which is useful, but it does not cover error behavior, return format, or latency/confirmation timing.
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, front-loaded sentence with a parenthetical clarifying the content. It contains no fluff or redundant phrasing, making it 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?
With no output schema, the description lists the main return categories but does not explain the response structure, behavior for invalid hashes, or whether confirmation is required. For a simple 2-parameter read-only tool with strong annotations, this is minimally acceptable but leaves gaps.
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 descriptions cover 100% of parameters: txHash is described as 'Transaction hash' and network as 'Network name. Defaults to mainnet.' The tool description adds no additional parameter semantics, so the baseline score of 3 applies.
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 operation ('Get transaction info') and specifies the content (receipt/confirmation status, energy usage, logs). It is a specific verb+resource but does not differentiate from sibling tools like get_transaction_info_by_id or get_transaction.
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 is provided on when to use this tool versus alternatives such as get_transaction, get_transaction_info_by_id, or get_events_by_transaction_id. The description only states what the tool does, not the appropriate context or exclusions.
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 annotations already indicate destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the agent knows this is a state-changing operation with external effects. The description adds little beyond saying 'Deploy' — it does not mention that deployment costs TRX, permanently writes to the blockchain, or that the contract address is derived from the sender. This is acceptable given annotation coverage, but the description could have added context about fees or irreversibility.
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, concise and to the point. It communicates the essential action without unnecessary words. It is front-loaded with the verb 'Deploy' and the resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a non-trivial operation (deploying a contract), but the description does not mention what the tool returns (e.g., contract address), any prerequisite (e.g., a selected wallet), or caveats (e.g., fee costs). There is no output schema to fall back on, so the description should have filled that gap. It falls short for an agent to fully understand the deployment flow.
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 provides descriptions for all 6 parameters, achieving 100% coverage. The description only mentions 'ABI and Bytecode', which is already present in the schema. It does not add syntax, format details, or clarify constructor arguments or fee limits. Since the schema is fully documented, a baseline 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 action ('Deploy'), the resource ('smart contract'), the target network ('TRON network'), and key inputs ('ABI and Bytecode'). This distinguishes it from sibling tools like write_contract (which interacts with existing contracts) and read_contract (which reads state). The verb and resource are specific and unambiguous.
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 explicit guidance on when to use this tool versus alternatives. It does not mention that deployment is irreversible, requires a selected wallet, or should be used for new contracts only. The purpose implies usage, but there are no when-to-use or when-not-to-use instructions, and no reference to sibling tools.
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?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds little behavioral context. It does not disclose that freezing locks funds, that unfreezing is required to recover TRX, or any other side effects. The 'Stake 2.0' hint is the only extra insight.
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, front-loaded sentence with no filler. It efficiently conveys the action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a staking operation with significant implications (locked funds, later unfreeze), the description is too sparse. It does not explain the staking lifecycle or consequences, leaving an agent potentially under-informed. Sibling tools like unfreeze_balance_v2 highlight the missing context.
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 each parameter (amount, network, resource) already has a clear description. The tool description adds no parameter-specific meaning, 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 states the specific action ('Freeze TRX') and outcome ('get resources'), and the parenthetical 'Stake 2.0' adds relevant context. It clearly distinguishes from siblings like transfer_trx, unfreeze_balance_v2, and delegate_resource.
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 bandwidth or energy, but it does not explicitly discuss when to use this tool versus alternatives like delegate_resource or when not to use it. No exclusions or comparative guidance are provided.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds minimal extra behavior, only clarifying that 'net' refers to bandwidth. It does not discuss return format, pagination, or other runtime behavior, but with annotations present this is acceptable.
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, focused sentence of eight words. It is front-loaded with the action and resource, contains no filler, and every word 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?
For a simple read-only tool with rich annotations and complete schema, the description is adequate. It explains the core purpose, and the schema covers parameters. However, it could benefit from mentioning that it focuses specifically on bandwidth vs. energy, and could hint at the return structure, but this is not critical for a low-complexity 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%, with each parameter (address and network) already described in the schema. The description adds no new parameter semantics beyond the word 'net' clarifying bandwidth, which is useful but not substantial. Baseline 3 is appropriate.
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 verb 'Get' and the specific resource 'bandwidth (net) resource information' for an account. It is clear but does not explicitly differentiate from sibling tools like get_account_resource or get_bandwidth_prices, so it misses the top score for sibling differentiation.
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_account_resource or get_account_balance. It does not state exclusions, prerequisites, or typical scenarios, leaving the agent without explicit usage direction.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying what data is returned (ABI, function signatures, raw metadata), but it does not add further behavioral context such as network behavior, response format, or exceptions. It is adequate but not rich.
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, well-structured sentence. It front-loads the action and resource, then lists specific deliverables. Every word earns its place.
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 its simplicity (2 params, no output schema) and strong annotations, the description is largely complete. It tells users the key return contents. However, it lacks any guidance on how it differs from the many sibling read tools, which would make it fully self-contained 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?
Schema description coverage is 100%, with both parameters (network and contractAddress) already documented. The tool description adds no extra parameter meaning beyond the schema. Baseline for full schema coverage is 3, so it is appropriate.
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 uses a specific verb ('Get') and resource ('contract'), and specifies the scope: ABI, readable function signatures, and raw metadata. It clearly states what the tool does, but it does not explicitly distinguish it from similar sibling tools like get_contract, fetch_contract_abi, or read_contract, so it misses the sibling-differentiation criterion for a 5.
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 gives no explicit guidance on when to use this tool over alternatives. It mentions 'high-level information' which implies a use case, but there are no exclusions or references to sibling tools, leaving the agent without clear decision support for choosing between this and many similar contract-related tools.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral context. It does not disclose things like return format, potential null results, or network connectivity requirements, but it remains consistent with annotations.
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, concise sentence that front-loads the core function without unnecessary words or repetition. It is perfectly sized for a simple tool.
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 read-only tool with one optional parameter and no output schema, the description is largely sufficient. It could be improved by noting that it returns the block object or that 'network' defaults to mainnet, but the schema already covers the parameter default.
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 provides a complete description for the single optional parameter 'network' with its default value, so the description adds no additional parameter semantics. With 100% schema coverage, the baseline of 3 is appropriate.
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 the latest block from the network, with a specific verb and object. However, it does not differentiate from the sibling tool 'get_now_block', which may be synonymous, so it lacks explicit sibling distinction.
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 is provided about when to use this tool versus alternatives like get_block or get_now_block. There is no mention of exclusions, alternatives, or preferred contexts, leaving the agent to infer usage from the 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the detail 'current active', which scopes the result set, but provides no additional behavioral context like pagination defaults or ordering.
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?
A single sentence that is concise, front-loaded, and free of filler. Every word 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?
For a simple read-only list tool with a clear schema and annotations, the description is adequate. It communicates the resource and scope, though it could be slightly more complete by mentioning the pagination parameters or aligning with the sibling 'list_witnesses'.
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 covers 100% of parameters with descriptions (limit, offset, network), so the schema carries the descriptive weight. The description adds no extra meaning beyond what the schema already provides.
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 action ('Get') and the resource ('paginated list of current active Super Representatives'). It is specific enough to understand the tool's purpose, though it does not explicitly distinguish itself from the sibling 'list_witnesses' tool.
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 is provided about when to use this tool over alternatives. The description only states what it does without any context for when to select it, nor mentions exclusions or alternative tools.
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 annotations already disclose read-only, idempotent, and non-destructive behavior, so the description only needs to add extra context. It adds that the tool returns 'status and content', which is helpful but does not disclose pagination, error behavior, or network-specific nuances. The description does not contradict annotations.
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, extremely concise, and directly states the operation and target. There is no filler or redundant content, maximizing clarity per word.
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 tool is simple with two well-documented parameters and comprehensive annotations. The description conveys the core purpose, and the schema handles parameter details. However, the presence of similarly named sibling tools could lead to confusion without explicit differentiation, so it is 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 description coverage is 100% with both 'value' (transaction hash) and 'network' (defaults to mainnet) documented. The description adds no additional parameter semantics beyond what the schema already provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries transaction status and content by transaction hash, using a specific verb and resource. It does not explicitly distinguish itself from sibling tools like get_transaction or get_transaction_info_by_id, which may perform similar functions, so it misses the top score.
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 gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or alternative tools, leaving the agent to infer usage solely from the 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?
Annotations already cover read-only and non-destructive behavior, so the description adds the specific receipt contents returned. This is useful but does not go beyond annotation coverage to disclose edge cases, authorization requirements, or rate limits, making it adequate but not exceptional.
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, front-loaded sentence that communicates the purpose and key output fields without any redundant or extraneous wording. It is concise and well structured.
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 query tool, the description covers the essential return values and the annotations disclose the read-only nature. It does not describe the response format or error handling, but these are minor omissions given the tool's simplicity and lack of an output schema.
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 already documents both parameters with clear descriptions (transaction hash and network). The description does not add any additional parameter semantics, so it relies entirely on schema coverage, which is at 100%.
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 queries a transaction receipt and enumerates specific fields (energy usage, fee, logs, confirmation status) by transaction hash. However, it does not explicitly differentiate from similarly named siblings like get_transaction_info or get_transaction_by_id, so it lacks sibling differentiation.
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 is provided on when to use this tool versus alternatives. The description states what it does but does not mention when it is preferred or excluded, leaving the agent without decision support.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, covering the safety profile. The description adds minimal context by mentioning 'Stake 2.0', which hints at the staking mechanism, but does not disclose important behavioral details like whether the unfrozen amount becomes immediately withdrawable or if there is a waiting period. This is acceptable given the annotation coverage, but not exceptional.
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, well-structured sentence that immediately conveys the action and purpose. Every word is purposeful, with no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a state-changing operation with no output schema and has several related sibling tools. The description is too terse to fully convey the unfreeze workflow, such as the relationship to withdrawal after unfreezing, the meaning of Stake 2.0, or any restrictions. A more complete description would explain what happens after unfreezing and how this differs from withdraw_expire_unfreeze.
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 three parameters (amount, network, resource), so the schema already fully documents meaning and defaults. The description adds no additional parameter-level semantics, matching 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 uses a specific verb 'Unfreeze' with a resource 'TRX' and clarifies the purpose 'to release resources (Stake 2.0)', which clearly distinguishes it from the sibling tool freeze_balance_v2. It is concise and unambiguous about the tool's core function.
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 withdraw_expire_unfreeze or cancel_all_unfreeze_v2. There are no scenarios, prerequisites, or exclusions mentioned, leaving the agent to infer usage solely from the tool's name and brief 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?
Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=false. The description adds that the operation uses 'staked resources' from 'the configured wallet', which implies a prerequisite that resources must be staked and a wallet must be selected. However, it does not disclose side effects like lock periods, whether delegation can be revoked, or the transaction nature. Given annotation coverage, this is adequate but not rich.
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 concise sentence that places the action first and includes the key differentiators (resource types and destination). Every word earns its place; there is no filler or redundant phrasing.
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 moderate complexity (6 params, no output schema), the description is minimally sufficient: it states what the tool does and the main scoping. However, it lacks usage context such as when to delegate vs freeze, prerequisites, or any side effects/return value. With rich sibling tooling, a bit more context would improve completeness, but the schema and annotations cover the essential mechanics.
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 schema has 100% description coverage for all 6 parameters, each with clear descriptions. The description does not add extra parameter semantics beyond the schema, so the baseline of 3 is appropriate. It does implicitly say the resource parameter is BANDWIDTH or ENERGY, but that is already in the schema enum.
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 ('Delegate'), the resource being delegated ('staked resources (BANDWIDTH or ENERGY)'), and the target ('another address'). This distinguishes it from sibling tools like undelegate_resource (opposite direction), freeze_balance_v2 (staking, not delegating), and transfer_trx (transferring TRX, not resources). The verb+resource+destination structure makes the purpose unambiguous.
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. It does not mention prerequisites (e.g., needing staked resources first) or exclusions (e.g., not suitable for undelegation). Users must infer from the name and 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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds context about using the configured wallet but does not disclose return format or behavior when no wallet is selected.
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?
One sentence of nine words, front-loaded with the verb and resource. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits the return value (likely the signature). Given there is no output schema, this gap affects completeness. It also does not explicitly mention wallet-selection prerequisites, though 'configured wallet' hints at it.
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 schema fully describes the single parameter with 'The message to sign'. The description adds only the qualifier 'arbitrary', which slightly enhances meaning but does not provide format or constraints 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 uses a specific verb ('Sign') with a clear object ('arbitrary message') and resource ('configured wallet'). It distinguishes itself from transaction-signing tools by emphasizing 'arbitrary', making the purpose unambiguous.
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 offers no guidance on when to use this tool versus alternatives, such as off-chain message signing vs. transaction signing. It also omits prerequisites like having a wallet selected.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds minimal behavioral context beyond the read-only query nature, such as the Stake 2.0 versioning, but does not discuss response format, pagination, or any side effects. No contradiction with annotations.
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, front-loaded sentence that immediately states the action and resource. Every word earns its place, and there is zero extraneous content.
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 read-only query with full schema coverage and safety annotations, the description is nearly complete. It states the core query semantics and the Stake 2.0 context. The main gap is not clarifying when to use this vs. get_delegated_resource_v2, and no mention of return value specifics (though no output schema exists to mandate that).
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%, with each parameter having a clear description (e.g., 'Delegator address', 'Recipient address', 'Network name'). The tool description does not add any additional parameter-level meaning, so the baseline of 3 applies.
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 verb 'Query' and the resource 'amount of resources delegated from one account to another', and adds the context 'Stake 2.0' which helps distinguish it from other delegation tooling. However, it does not explicitly differentiate from the closely named sibling get_delegated_resource_v2, so it falls short of a 5.
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 the tool is used to query delegated resource amounts, and the 'Stake 2.0' context gives some situational framing. Yet there is no explicit guidance on when to prefer this tool over alternatives like get_delegated_resource_v2 or get_delegated_resource_index, nor are any exclusions mentioned.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the tool's safety profile. The description adds no extra behavioral detail beyond the core function, which is acceptable for a read-only query.
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 redundancy, front-loaded with the core function.
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 read-only event query with robust annotations and a fully documented schema, the description is sufficient. It lacks explicit mention of return format or volume, but these are not critical for this straightforward 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?
The input schema has 100% coverage with descriptive parameter explanations, so the description adds no additional parameter semantics. Baseline 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 states a specific action (get all events) and identifies the resource (events emitted by a specific transaction). This clearly distinguishes it from sibling tools that retrieve events by contract address or block number.
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 is provided on when to use this tool versus alternatives like get_events_by_contract_address or get_events_by_block_number. The description only states the function without any usage context or exclusions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond the tool's purpose; it does not mention edge cases like no scheduled maintenance or return format. It does not contradict the annotations.
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?
A single, concise sentence that front-loads the action and object. No redundant words or filler.
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 read-only tool with one optional parameter and full schema coverage, the description is largely sufficient. It could mention possible null/absent maintenance windows, but overall it gives enough context for correct invocation.
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 fully documents the single 'network' parameter, including its type and default value (mainnet). The description adds no additional parameter semantics, so it matches the schema-coverage baseline.
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 uses a specific verb ('Get') and a clear resource ('the timestamp of the next network maintenance window'). It is unambiguous and distinguishes itself from sibling tools that fetch network info, chain info, or node info.
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, no prerequisites, and no exclusions. It simply states what the tool does, leaving the agent to infer usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the scope 'all' proposals but does not disclose return format, pagination, or network default behavior beyond schema. It meets the baseline but does not enrich context significantly.
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, clear sentence that front-loads the core action. There is no fluff or redundant information; every word contributes to understanding.
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 tool is simple: one optional parameter, read-only, no output schema. The description adequately explains what it does. It could mention that it returns a list/array of proposals or that the network defaults to mainnet, but these are minor gaps. Overall, it is sufficient 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?
Schema description coverage is 100% for the single optional 'network' parameter, so the schema already documents it. The description adds no extra meaning about parameter syntax or behavior, which is fine given the high coverage. 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 tool's purpose: 'List all network governance proposals.' It uses a specific verb ('list') and resource ('network governance proposals'), and it naturally distinguishes from sibling tools like get_proposal, which retrieves a single proposal.
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 is provided on when to use this tool versus alternatives. The description does not mention that get_proposal should be used for a specific proposal, nor does it clarify that this is the go-to for a broad overview. There is no when-not or exclusion 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?
Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, but the description does not elaborate on side effects, reversibility, or network-specific behavior. It does add the prerequisite that the wallet must already be an SR, which is useful. However, it doesn't disclose whether the update is reversible or if it affects anything beyond the URL, though annotations already cover safety hints.
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, front-loaded with the action. It earns its place by adding the prerequisite. No redundant information. Slightly terse but acceptable for a simple update.
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 2 params, 100% schema coverage, and no output schema, the description provides the essential prerequisite but lacks details about network-specific behavior or confirmation of the update. For a simple update this is adequate, though it could mention the effect of the 'network' parameter on which wallet's URL is updated.
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 the description of 'url' and 'network' in the schema is sufficient. The tool description adds minimal value beyond the schema, but it does state 'URL' and 'mainnet' default. Since schema is complete, a baseline of 3 is appropriate.
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 action ('Update the SR node website URL') and the resource ('the configured wallet' / SR), which is specific and distinct from sibling tools like update_account or create_witness. It does not explicitly distinguish from all sibling tools, but the verb+resource+target is clear enough.
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 a clear prerequisite: 'must already be an SR'. This implies when to use the tool (for existing SRs) and implicitly excludes creating a witness or updating other account info. It does not name alternative tools explicitly, but the context is sufficient given the sibling list.
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 annotations already declare destructiveHint=true and readOnlyHint=false, indicating a network-side write operation. The description adds contextual detail about the payload (signed, protocol buffer-encoded) but does not disclose potential side effects like irreversibility, gas costs, or failure modes. With annotations covering the safety profile, a score of 3 is appropriate.
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, front-loaded sentence that communicates the essential action and payload format without wasted words. It is concise and directly readable.
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 tool's simplicity and the existence of annotations and a complete schema, the description is adequate but lacks detail on return values, error behavior, or the default network. With no output schema, the description could have mentioned expected response or side effects, but the core action is clearly covered.
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 description coverage is 100%, with both parameters (network, transaction) having descriptions. The tool description adds extra semantic context ('protocol buffer-encoded', 'signed') that goes beyond the schema's 'Signed transaction hex string', enriching the understanding of the primary 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 tool's function: broadcasting a signed, protocol buffer-encoded transaction hex string to the TRON network. It uses a specific verb ('Broadcast') and resource ('transaction hex string'), and the 'protocol buffer-encoded' qualifier distinguishes it from potential siblings 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies a prerequisite (a signed transaction) but does not reference sibling tools such as create_transaction, sign_message, or broadcast_transaction, nor does it explain when this specific encoding format is required.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds return value details (current block number and RPC endpoint) but does not provide additional behavioral context like network-specific behavior or response shape beyond what annotations imply.
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, clear sentence that front-loads the purpose and output. Every word earns its place, with no redundant or vague phrasing.
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?
For a simple read-only tool with rich annotations (safe, idempotent) and a fully described optional parameter, the description is complete. It states exactly what the tool returns, which is sufficient for an AI agent to select and invoke it 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?
Schema description coverage is 100% (the only parameter 'network' is fully described). The description does not add any extra parameter details, but the schema already provides the semantics, so the baseline 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 function: 'Get information about a TRON network' with specific output details (current block number and RPC endpoint). This distinguishes it from sibling tools like get_chain_parameters or get_node_info, which focus on different aspects.
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 is provided on when to use this tool versus alternatives. The description simply defines the tool without mentioning any scenarios, exclusions, or comparisons to related tools such as get_latest_block or get_chain_parameters.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the 'recent' scoping constraint but does not disclose pagination behavior (e.g., fingerprint token) or the meaning of onlyConfirmed beyond what the schema lists. No contradiction with annotations.
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, front-loaded sentence that states the verb and resource immediately. Every word earns its place, with no redundant phrasing or filler.
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 7 parameters and multiple sibling event tools, a one-sentence description is sufficient to convey the core purpose but lacks explicit differentiation from siblings and does not mention pagination or confirmation behavior. Schema and annotations cover many details, but the description leaves the agent to infer usage context.
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% with useful descriptions for all 7 parameters, including defaults, enums, and filter options. The description adds no extra parameter semantics beyond what the schema provides, so the baseline score applies.
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 uses a specific verb ('Get') and resource ('events emitted by a specific contract address'), clearly distinguishing it from event-fetching siblings that filter by transaction ID, block number, or latest block. The contract-address scope is explicit and unambiguous.
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 a specific contract address is known, but it does not explicitly mention alternatives or provide when-not guidance. With multiple event-fetching tools in the sibling list, some differentiation would help, but the 'by contract address' phrasing gives a clear contextual clue.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the mutation nature is known. The description adds no additional behavioral context such as irreversibility, network broadcast, or fee implications. It does not contradict the annotations, but it also doesn't enrich beyond what structured data already reveals.
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, front-loaded sentence that directly states the verb and object. It is appropriately sized for a simple transfer operation, with no extraneous words or repetition of schema details.
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 schema covers all parameters and annotations declare the tool destructive, the description provides minimal but sufficient context for the core action. However, it omits higher-level details such as broadcast behavior, network defaults, or wallet prerequisites. It is adequate but not rich, especially for a tool that moves value.
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 describes all four parameters (tokenAddress, to, amount, network) with 100% coverage and clear descriptions, including that 'amount' is raw amount with decimals. The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.
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 'Transfer TRC20 tokens to an address' uses a specific verb ('transfer') and clearly identifies the resource (TRC20 tokens) and destination (address). It distinguishes logically from sibling tools like transfer_trx, which transfers TRX or other tokens.
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 a use case (when you want to transfer TRC20 tokens) but provides no explicit guidance on when not to use it, or how it differs from alternatives like transfer_trx or write_contract. No prerequisites or contextual triggers are mentioned, leaving the agent to infer from the token type.
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?
Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false. The description adds the wallet requirement, which is useful, but does not elaborate on side effects, transaction broadcasting, or return behavior. No contradiction with annotations.
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 short sentences with zero filler. Every word earns its place, and the key point ('state-changing') is front-loaded.
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 6 parameters and no output schema, but the description provides only the essential purpose and a wallet prerequisite. It lacks details on expected return values, failure modes, or how it compares to transfer tools. Annotations and schema cover some gaps but not the return/process aspects.
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 each parameter is well-described (e.g., abi, args, value). The tool description adds no parameter-specific information, so it falls at the baseline for high schema coverage.
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 uses the specific verb 'Execute' and resource 'state-changing functions on a smart contract,' clearly distinguishing this from read_contract. It states the core action without ambiguity.
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 state-changing operations but does not explicitly list when to use it versus alternatives like read_contract for reads or transfer_trx for transfers. The prerequisite 'Requires configured wallet' offers some context but no exclusions.
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?
Annotations already indicate readOnlyHint=false (mutation), destructiveHint=false, and openWorldHint=true. The description adds the 'SR only' authorization constraint, which is useful. However, it does not disclose whether this creates an on-chain transaction, requires signing/broadcasting, or what side effects may occur beyond the openWorldHint.
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 short, front-loaded sentences. The first states the action and scope, the second instructs on required input. No wasted wording, perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should clarify what the tool returns or whether it broadcasts a transaction. It doesn't. For a governance proposal creation (likely an on-chain operation), the lack of side-effect and return-value information is a significant gap, especially with openWorldHint=true.
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 parameters property includes a clear description with an example. The tool description's second sentence restates the schema but adds no new meaning. Baseline 3 applies as the schema does the heavy lifting.
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 states 'Create a new network governance proposal (SR only)' with a specific verb, resource, and scope restriction. It clearly distinguishes from sibling tools like approve_proposal, delete_proposal, and list_proposals by focusing on creation and parameter changes.
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 gives clear context (used for creating governance proposals with parameter changes) and an explicit authorization requirement (SR only). It doesn't name alternative tools, but the verb 'create' plus the proposal context implicitly differentiate it from approval/deletion/list 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?
The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, establishing it as a safe read operation. The description adds context beyond the annotations by specifying TronGrid indexed data, the inclusion of token info and human-readable values, and pagination behavior with default/max limits. This adds meaningful behavioral context without redundancy.
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 long and front-loaded with the core purpose. Every clause earns its place: the first sentence states the main function and data source, the second describes return content and pagination. No fluff or repetition.
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 straightforward read tool with rich annotations and full schema coverage, the description is reasonably complete. It explains return data composition, pagination parameters, and default/max limits. It does not delve into each filter (minTimestamp, onlyConfirmed, etc.), but those are already well-documented in the schema. The absence of an output schema is fine because the description summarizes the return content.
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% with all 10 parameters documented. The description does not significantly expand on parameter meanings, but it does clarify the pagination mechanism (limit + fingerprint) and mentions human-readable values not present in the schema. This adds marginal value, so a 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 uses the specific verb 'Get' and resource 'TRC20 token transfer history for an account', clearly distinguishing this from sibling tools like get_account_transactions (which likely covers TRX transfers) and get_account_trc20_balances (balances, not history). The additional context 'from TronGrid indexed data' further narrows the purpose.
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 guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions or alternative tools, leaving the agent to infer from the name and sibling list. While the purpose is clear, the tool lacks 'use this when X' direction.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety behavior. The description adds little beyond the annotations, simply restating the query behavior without further details like error conditions or result format. No contradiction with annotations.
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 imparts both the purpose and the key usage instruction without any filler or repetition. It is front-loaded and efficient, earning a high score for conciseness.
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 read-only query tool, the description adequately explains the input (full transaction JSON) and the output (list of accounts), even without an output schema. It could specify more about the returned accounts (e.g., format or ordering), but the core information needed to invoke the tool is present.
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%; both 'network' and 'transaction' have descriptive text. The description's phrase 'Pass the full transaction JSON object' reinforces the schema's parameter description but does not add meaningfully new semantics beyond what's already in the input 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 uses a specific verb 'Query' and a clear resource 'the list of accounts that have signed a given transaction', which precisely identifies the tool's function. This purpose is distinct from sibling tools, as none explicitly mention an approved list of signers.
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 instruction 'Pass the full transaction JSON object' gives a direct usage input requirement but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The usage is implied by the clarity of the purpose, but there is no explicit context or alternative naming.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the Stake 2.0 scope but does not disclose additional behavioral details such as return format or error conditions. No contradiction with annotations.
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, front-loaded sentence with no redundant information. It efficiently communicates the core function.
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 read-only tool with two parameters and strong annotations, the description is adequate. It clearly identifies the purpose and scope, though it does not explicitly state the return value format, but the name implies a count.
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 covers 100% of parameters (address and network) with descriptions. The tool description adds no additional meaning beyond the schema, so the baseline 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 uses a specific verb 'Get' and resource 'remaining available unstake (unfreeze) operations' with a clear scope 'for an address in Stake 2.0'. It accurately reflects the tool name and distinguishes it from sibling unfreeze-related tools by emphasizing the count of operations rather than amounts.
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 phrase 'in Stake 2.0' implies usage context, but the description does not explicitly state when to use this tool over alternatives like get_can_withdraw_unfreeze_amount or unfreeze_balance_v2. No exclusions or alternative tool names are provided.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'historical' and 'unit price' but does not disclose additional behaviors such as return format, pagination, or default network handling. This is adequate but not rich.
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?
A single, well-structured sentence with no redundant words. The key action and resource are front-loaded, making it immediately scannable.
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 read-only tool with one optional parameter and no output schema, the description is sufficient to convey the core purpose. It does not describe the response format, but the name and purpose imply a list of prices. Given good annotations, the description feels complete enough for an agent to select and invoke 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?
Schema coverage is 100%: the only parameter 'network' is fully described in the schema ('Network name. Defaults to mainnet.'). The description adds no extra parameter information, so the baseline 3 applies.
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 uses a specific verb 'Query' with a clear resource 'historical bandwidth unit price' and scope 'TRON network'. It distinguishes from sibling tools like get_energy_prices by explicitly mentioning bandwidth, making the purpose unambiguous.
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 when to use the tool (when bandwidth prices are needed) but provides no explicit exclusions or alternatives. It does not reference get_energy_prices or other similar tools, so guidance on tool selection is only implicit.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is well covered. The description adds useful context about the inclusive/exclusive range semantics, but does not disclose potential pagination behavior or limits, though these are less critical given the read-only nature.
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 is concise, front-loaded, and directly communicates the primary function. It contains no unnecessary words or repetition of schema details.
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 read-only list tool with strong annotations and a fully documented schema, the description is adequate. It explains the range semantics and what is returned. However, the tool's name 'limit_next' hints at possible pagination or limit behavior that is not addressed, and there is no output schema to clarify the exact 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 the parameters are already well-documented in the schema with their inclusive/exclusive meanings. The description adds minimal additional meaning beyond stating the range, which is essentially a restatement of the parameter descriptions.
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 a list of block objects within a specified inclusive/exclusive range. It uses a specific verb ('Retrieve'), names the resource ('block objects'), and defines the scope with the [startNum, endNum) notation, distinguishing it from sibling tools that fetch single blocks by num/id or the latest block.
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 its use for fetching a range of blocks, giving clear context on the input range. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative tools for single-block queries.
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?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful context about the unit (Sun) and Stake 2.0, but does not disclose additional behavioral traits such as default network handling or edge cases like zero balance.
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 with the action front-loaded, no redundant wording, and every phrase serves a 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?
Given the absence of an output schema, the description clearly conveys the return value (maximum amount in Sun) and the key inputs. It lacks specifics about the response format, but for this simple query the description is largely sufficient.
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 descriptive parameter comments for address, network, and resource. The description adds no extra meaning beyond what the schema provides, so baseline 3 applies.
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 the maximum delegatable TRX amount (in Sun) for a given address and resource type under Stake 2.0. It uses a specific verb ('Get') and resource, and is easily distinguished from siblings like 'delegate_resource' or 'get_delegated_resource_v2'.
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 to know delegation capacity before delegating, but does not explicitly state when to use this tool over alternatives or provide exclusions. No direct mention of sibling tools or when-not conditions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, providing the safety profile. The description adds useful return-format context ('structured fee information similar to gas price queries') but doesn't disclose other behavioral traits such as authentication needs or rate limits. No contradiction with annotations.
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, two sentences, and front-loaded with the primary purpose. Every word adds value, and it is well-structured for quick comprehension.
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 tool is simple with one optional parameter and no output schema. The description sufficiently covers the tool's purpose and return-type orientation, though it doesn't enumerate all possible returned fields. Given the low complexity and annotations, this is almost complete; a slightly more detailed explanation of the returned structure could make it a 5.
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 'network' parameter, and the schema already explains it defaults to mainnet. The description does not add any additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.
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 uses a specific verb 'Get' with a clear resource 'current chain parameters' and explicitly mentions 'Energy and Bandwidth unit prices,' which distinguishes it from sibling tools like get_energy_prices and get_bandwidth_prices. It effectively communicates the tool's scope and purpose.
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 context by stating it returns fee information similar to gas price queries, but it does not explicitly guide when to use this tool versus alternatives like get_chain_info or get_energy_prices. There are no exclusions or alternative recommendations, so it's adequate but not explicit.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds the nuance that ABI is included 'if verified', which is a useful behavioral condition. No other behavioral traits (e.g., default network, rate limits) are disclosed beyond the annotations.
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?
A single sentence with clear front-loaded action ('Get raw contract metadata'), no filler, and every word contributes value. It is appropriately sized for the tool's simplicity.
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 read operation with 2 parameters and no output schema, the description states the primary return components (ABI and bytecode) and the on-chain source. It leaves the full scope of 'raw metadata' unspecified, but is adequate for basic use and the annotations cover safety.
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 covers 100% of parameters with descriptions: network defaults to mainnet, contractAddress is the contract address. The description adds no additional parameter meaning beyond the schema, so the baseline of 3 is appropriate when schema does the heavy lifting.
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 specifies 'Get raw contract metadata from the chain, including ABI (if verified) and bytecode' – uses a specific verb and resource, and differentiates from sibling tools like fetch_contract_abi by including bytecode and raw metadata. The 'if verified' nuance adds clarity about the ABI's conditional availability.
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 raw contract metadata but does not explicitly state when to prefer this over get_contract_info or fetch_contract_abi, nor does it provide exclusions. The context is clear but lacks explicit alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint). The description adds the directional scope of the index but does not disclose return format, pagination, or other behaviors. With annotations present, this is adequate but not especially rich.
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, well-structured sentence with no filler. It front-loads the verb and resource and earns every word.
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 read-only query with two parameters and no output schema, the description covers the essential semantics. It could be improved by noting how this tool differs from the similarly named get_delegated_resource_account_index_v2, but the annotations and schema fill most remaining gaps.
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 both parameters (address and network). The description does not add any parameter-level detail beyond what is in the schema, 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 states the verb 'Query' and the resource 'resource delegation index', and explicitly defines what the index contains: incoming and outgoing delegations. This makes the tool's purpose immediately obvious and distinguishes it from related getter tools in the sibling set.
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 indicates the tool is used for an account, but it does not provide explicit guidance on when to use this tool versus alternatives like get_delegated_resource or get_delegated_resource_account_index_v2. The usage context is implied rather than stated.
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 annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds valuable context: it specifies that the details include bandwidth and energy, and clarifies the Stake 2.0 scope. This goes beyond the generic safety hints, though it does not describe the return format or potential error cases.
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, focused sentence with no redundant information. It front-loads the action and resource, and every word contributes to understanding 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?
For a read-only query with no output schema, the description adequately conveys the tool's input scope (two addresses) and output domain (bandwidth and energy details). It could be more explicit about whether the response contains both quantities or a list of delegation records, but the current level is sufficient for basic usage.
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 already provides complete descriptions for all three parameters, including the default for 'network' and the Base58/hex format hints for addresses. The description text does not add additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate given 100% schema coverage.
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: retrieving delegated resource details (bandwidth and energy) between two addresses under Stake 2.0. It uses a specific verb ('Get') and resource ('delegated resource details') and explicitly mentions the Stake 2.0 context, which differentiates it from older delegation tools like get_delegated_resource.
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. It does not mention any exclusions or conditions, nor does it reference sibling tools such as get_delegated_resource (v1) or get_delegated_resource_index, so an agent has no basis for choosing this over related options.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so there is no contradiction. The description adds value by enumerating the returned content categories (version, config, peers, machine info), going beyond the annotation hints. It does not mention network-dependent behavior beyond the schema default.
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?
A single, front-loaded sentence that states the action and resource with no filler. Every word contributes to explaining what the tool does.
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 read-only tool with no required parameters and no output schema, the description plus annotations are sufficient: safe read, open-world hint, and content scope are covered. Additional output format or resolution details are not necessary at this complexity.
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% coverage for the single optional network parameter, including default behavior. The description adds no parameter-level detail, so the schema fully carries the semantic weight; 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 uses a specific verb+resource: 'Get detailed information about the current TRON node' and names concrete data categories (version, config, peers, machine info). This clearly distinguishes it from sibling tools like get_chain_info (chain-level metadata) and list_nodes (network node listing).
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 guidance on when to use this tool versus alternatives such as get_chain_info or list_nodes. Context is implied by 'current TRON node,' but the description does not state exclusions or reference alternative tools.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the 'unclaimed' qualifier, which is useful context, but it does not disclose return format, network behavior, or other operational details. With annotations covering mutation safety, this is adequate but not rich.
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, concise sentence with no filler. It front-loads the action ('Query') and the specific resource, making it immediately clear and easy to parse.
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's simplicity, full parameter documentation, and annotations covering safety, the description is largely complete. However, it does not specify the return format or any caveats about the reward being unclaimed or subject to network conditions, so a minor gap exists.
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% with clear descriptions for both address and network parameters. The description reinforces that the address is the query target but adds no new semantic detail beyond what the schema already provides, so the baseline score of 3 applies.
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 uses the specific verb 'Query' and identifies the exact resource: 'current unclaimed voting reward for an address.' This clearly distinguishes it from sibling tools like get_balance or get_token_balance, which query different types of assets.
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 purpose implies usage for checking unclaimed voting rewards, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage context is only implied by the tool's purpose.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. However, the description adds no extra behavioral context such as whether the balance is returned in raw units, whether the address needs to be base58, or how network defaults are handled. With strong annotations, a score of 3 reflects that the description adds minimal value beyond the structured metadata.
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, clear sentence of eight words. It is perfectly concise, with no wasted words or redundant information, and it is easy to parse at a glance.
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, read-only token balance tool with strong annotations and a fully self-described schema, the description is mostly complete. However, it does not mention return value format (e.g., raw integer vs. decimal-adjusted) or default network behavior beyond the schema. Despite this, the tool's low complexity means the lack of an output schema is less critical, so a score of 4 is given.
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 covers 100% of the parameters with descriptions for address, network, and tokenAddress. The tool description does not add any additional meaning beyond what the schema already provides, 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 'Get the TRC20 token balance for an address' clearly states the action (get), the resource (TRC20 token balance), and the target (an address). The inclusion of 'TRC20' distinguishes it from sibling tools like get_balance (likely native TRX) and get_account_balance. It is specific and unambiguous.
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 obtaining a single TRC20 token balance, but it does not explicitly state when to use this tool versus alternatives such as get_account_trc20_balances (which returns multiple balances) or get_balance (likely for TRX). No exclusions or alternative recommendations are provided, making the guidance merely implicit rather than explicit.
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?
Annotations already provide readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds that it returns receipts for all transactions in a block, but it does not clarify pagination, response structure, or network-specific behavior beyond what the schema already states.
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 front-loaded sentence that immediately names the action, resource, and scope. No unnecessary words or repetition, making it efficient for an agent to parse.
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 simple 2-parameter schema, strong annotations, and no output schema, the description is largely complete. It could be more explicit about returning a list/array of receipts and mentioning the optional network parameter, but these are inferable from the schema and the word 'all transactions.'
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%, with clear descriptions for both parameters ('Block height number' and 'Network name. Defaults to mainnet.'). The tool description adds no extra parameter meaning; it simply restates the block-height focus already present in 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 action ('Get'), the resource ('TransactionInfo (receipts)'), and the scope ('for all transactions in a specific block height'). This distinguishes it from sibling tools like get_transaction_info (which likely retrieves a single transaction's info) and get_block_by_num (which retrieves block data).
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 when to use it (when you need all transaction receipts for a given block height), but it does not explicitly state alternatives or when not to use it. There is no mention of using get_transaction_info for single transaction lookups, which is a key sibling distinction.
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 adds the return format and scope ('all connected') beyond what annotations provide, but does not disclose other behavioral details such as pagination, rate limits, or permissions. Given the annotations already declare readOnlyHint and destructiveHint, the description adds moderate value without being 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 action, and contains no redundant information. It is concise and well-structured.
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 read-only listing tool with one optional parameter, the description covers the primary behavior and return format. Since there is no output schema, stating the return type is valuable. It could be more explicit about accepted network values, but the schema covers that parameter, making the description sufficiently 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?
The input schema already provides a description for the only parameter 'network' (100% schema coverage). The tool description does not add any parameter-specific information beyond what the schema states, so the schema carries the burden and the description adds no extra value.
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 lists all connected node addresses on the TRON network and specifies the return format (array of IP:port strings). This distinguishes it from sibling tools like get_node_info, which likely returns detailed info about a specific node.
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 the tool is for retrieving node addresses, but it does not explicitly state when to prefer it over alternatives or identify exclusions. No alternative tools are mentioned, leaving usage context only implied.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description does not add extra behavioral context such as edge cases or return behavior, but it also doesn't contradict the annotations.
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?
A single sentence that fully conveys the purpose without unnecessary words. It is concise and well-structured, making it easy for an agent to parse quickly.
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 is simple with one parameter, and annotations provide safety context. However, there is no output schema and the description does not mention the return value (the converted address), which would be helpful for complete understanding.
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% with the parameter 'address' described as 'Address to convert (Hex or Base58)'. The description repeats this format information without adding extra semantic detail, so it meets the baseline but adds no further value.
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 with a specific verb 'Convert' and identifies the resource as 'addresses' in 'Hex and Base58 formats'. It is distinct from sibling tools like validate_address or get_wallet_address.
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: whenever an address needs conversion between Hex and Base58. While it doesn't explicitly name alternatives, the context is unambiguous and no other sibling tool serves this purpose.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds semantic context about what the brokerage value means, but it does not disclose additional behavioral details such as return value formatting, error conditions, or network handling beyond what annotations/schema provide.
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: the first states the purpose, the second clarifies the meaning of the returned value. Every word earns its place, with no redundancy or filler.
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?
For a simple read-only query with one required parameter, the combination of description, schema, and annotations provides sufficient context. The description explains the domain concept, making the tool's output interpretable even without an output schema.
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 both parameters (network and witnessAddress) are already described in the schema. The description does not add any parameter-specific meaning, but it does explain the domain concept of brokerage, which indirectly supports parameter understanding. Baseline 3 applies because the schema carries the parameter burden.
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 uses a specific verb+resource structure: "Query the brokerage ratio (dividend percentage) of a Super Representative." This clearly distinguishes it from the sibling mutation tool update_brokerage and other query tools.
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 by explaining what the tool does, but it does not explicitly state when to use it versus alternatives or mention any exclusions. For example, there is no guidance like 'Use this to check an SR's brokerage before voting' or 'Do not use this for total rewards.'
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds no additional behavioral traits beyond rephrasing the purpose; it does not disclose any nuances about network handling or defaults beyond the schema's parameter description. With annotations covering the safety profile, the description adds minimal extra value here.
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, well-structured sentence that conveys the essential purpose without any filler. There is no repetition of schema or annotation information, making it maximally efficient.
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?
For a simple read-only count tool with one optional parameter and no output schema, the description's clarity about the return value (a number) and the resource (pending pool) is sufficient. The complexity is low, and the annotations plus schema cover safety and parameter semantics, so no further context is needed.
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 'network' parameter, and the schema provides a clear description ('Network name. Defaults to mainnet.'). The description does not repeat or add parameter details, but the schema already fully handles this, so the baseline 3 applies.
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 a specific verb ('get') and resource ('number of transactions in the pending pool'), and clarifies the domain term 'mempool'. This distinguishes it from sibling tools like 'get_pending_transactions' that likely return the full list.
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 its use case by focusing on the count, but it does not explicitly say when to use this over alternatives such as 'get_pending_transactions'. No exclusions or alternative tool names are mentioned, so usage guidance is only implicit.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds minimal behavioral context beyond the annotations, such as the tool returning a snapshot of the current pending pool. No additional details about ordering, pagination, or rate limits are provided.
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 of 12 words, front-loaded with the action and resource. There is no fluff or unnecessary detail, making it highly concise and well-structured.
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?
For a simple read-only tool with one optional parameter, the description is complete. It identifies the output (list of transaction IDs) and the context (pending pool/mempool). The annotations and schema cover the remaining safety and parameter details, so no further information is needed.
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 only parameter, 'network', has a description in the schema ('Network name. Defaults to mainnet.'), so schema coverage is 100%. The description adds no additional parameter semantics, yielding the baseline score 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 function: 'Get the list of transaction IDs currently in the pending pool (mempool).' It specifies the resource (pending pool/mempool) and the output ('list of transaction IDs'), which distinguishes it from related siblings like get_pending_size or get_transaction_from_pending.
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 its usage by stating what it does, but it does not explicitly mention when to use this tool versus alternatives such as get_pending_size or get_transaction_from_pending. The context of the pending pool is clear, but no exclusions or alternative guidance is provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no extra behavioral context (e.g., ordering, pagination, or whether the list is cached). It is consistent with annotations, but doesn't go beyond what annotations already provide.
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 short sentences accomplish purpose, output detail, and a pointer to the next step. No wasted words, front-loaded with the action verb.
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 this is a simple read-only list operation with no parameters and good annotations, the description is sufficient. It clearly communicates the core return fields and connects to select_wallet, though it omits details like ordering or whether the list includes all network types.
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, and schema coverage is 100% (trivially). The description explains what the output contains (wallet IDs, types, addresses), which adds value beyond the empty schema. Baseline 4 is appropriate for zero-parameter tools.
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 states a clear action ('List all available wallets') and specifies returned data (wallet IDs, types, addresses). It mentions switching via select_wallet, which implies scoping and distinguishes it from wallet-related siblings, though it doesn't explicitly differentiate from get_wallet_address.
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 a clear usage context: call this to list wallets, then use select_wallet to switch. This gives implicit guidance on when to use it relative to select_wallet, but lacks explicit exclusions or alternative conditions (e.g., when to use get_wallet_address).
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the batch-call trait, but does not disclose return format, failure aggregation behavior beyond the schema, or version nuances. This is modest added context beyond annotations.
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?
One sentence, front-loaded with the core action, zero waste. Every word earns its place.
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 tool's moderate complexity and no output schema, the description gives the core purpose but omits return value shape, result ordering, and explicit failure semantics. It is adequate for tool selection but leaves some gaps for invocation confidence.
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%, with all five parameters documented in the input schema. The description adds no param-specific meaning, so the baseline of 3 applies.
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 executes multiple read-only functions in a single batch call, with a specific verb and resource. This distinguishes it from single-read tools like read_contract and aligns with the tool name.
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 phrase 'in a single batch call' implies usage when multiple reads are needed, providing clear context. However, it does not explicitly name alternatives or state when not to use it, so it stops short of perfect 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?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds that resources move 'back to the configured wallet' but does not disclose additional behavioral traits such as potential failure modes, waiting periods, or effects on the receiver. Thus, the description provides only marginal added transparency beyond annotations.
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 front-loads the action ('Revoke') and concisely covers the key details without any redundancy or irrelevant information.
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?
While the schema and annotations cover the parameters and safety profile, the description lacks information about the return value or post-conditions (e.g., whether it returns a transaction hash). It also does not clarify prerequisites like needing to be the delegator. For a destructive mutation tool with no output schema, the description is adequate but not 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?
The input schema provides 100% coverage with descriptive text for all parameters, including receiverAddress, amount, resource, and network. The description does not add extra meaning beyond what the schema already gives, so the baseline 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 function with a specific verb 'Revoke', specifies the resource types (BANDWIDTH or ENERGY), and identifies the target (receiver address) and destination (configured wallet). This distinguishes it from sibling tools like delegate_resource, which performs the opposite action.
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 implies the usage scenario by mentioning 'previously delegated' resources, making it clear this is for undoing a delegation. However, it does not explicitly name alternatives or provide exclusion conditions, though the inverse relationship with delegate_resource is obvious from 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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds that it sets owner, active, and optional witness permissions, providing some scope context. However, it does not state whether the update replaces existing permissions or merges them, nor does it disclose additional side effects beyond the annotation.
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 concise sentences, front-loaded with the action and purpose, and free of redundant wording. Every word carries meaning.
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 tool is complex, but the schema and annotations cover the detailed configuration thoroughly. The description communicates the overall scope and optional witness permission, though it could clarify whether the update is a full replacement or partial. No output schema exists, but this is a mutation tool, so return behavior is less critical.
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 the schema provides detailed descriptions for all parameters including nested structures. The description only mentions the permission types at a high level, adding little beyond what the schema already states. 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 uses the specific verb 'Update' with the resource 'account permissions' and clearly states the purpose ('multi-signature configuration'). It enumerates the permission types (owner, active, optional witness), distinguishing it from sibling tools like update_account or update_contract_setting.
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 clearly indicates the context for use ('multi-signature configuration') but does not explicitly mention when not to use it or provide alternative tool names. It gives clear context without exclusions, so it earns a 4 rather than a 5.
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?
Annotations already provide the safety profile (readOnlyHint=false, destructiveHint=false). The description adds the access restriction 'SR only' and clarifies the approve/disapprove behavior, but does not disclose further side effects or state changes. It does not contradict the annotations.
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?
A single, concise sentence with no redundant words. Front-loaded with the action and resource, followed by the access restriction. Every word earns its place.
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 tool with three well-documented parameters and no nested objects or output schema, the description provides the essential purpose and the 'SR only' constraint. It is sufficiently 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 schema provides 100% coverage of all three parameters with descriptions. The description itself adds no additional parameter-specific semantics beyond what the schema already states about 'approve' and 'proposalId'.
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 to approve or disapprove') and the resource ('governance proposal'), with the added scoping constraint 'SR only'. This distinguishes it from sibling tools like create_proposal, delete_proposal, and get_proposal.
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 gives clear context (voting on proposals) and includes a usage restriction ('SR only'), but does not explicitly name alternatives or when-not-to-use. This is implied by the clear context.
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?
Annotations already flag this as destructive and non-idempotent. The description adds valuable context beyond annotations: the 9999 TRX burn fee and the requirement of the configured wallet. It does not contradict any annotation.
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 purpose, and no redundant information. Every word earns its place.
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 mutation tool with no output schema, the description covers the core purpose, prerequisites, and cost. It doesn't explain the response/next steps after application, but the tool is straightforward enough that this is a minor gap.
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 both parameters (url, network) are already well-documented. The description text does not add further parameter-level details, but the baseline of 3 is appropriate given the high schema coverage.
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 'Apply' and resource 'Super Representative', uniquely distinguishing it from sibling tools like update_witness or vote_witness. It precisely captures the tool's function.
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?
Usage is implied ('Apply to become an SR') and the prerequisite 'Requires the configured wallet' provides contextual starting point. However, there is no explicit mention of when to use this vs alternatives, nor any exclusions such as 'do not use if already an SR'.
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?
Annotations already declare the tool as read-only and non-destructive, so the bar is lower. The description adds the key behavioral detail that the call is simulated, meaning no on-chain transaction occurs. This goes beyond the annotations and provides valuable 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?
The description is a single sentence that is front-loaded with the core purpose. It conveys the essential information with no wasted words, making it highly concise and appropriately sized for a tool of this simplicity.
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 the tool is a read-only simulation with a self-explanatory schema, the description covers the main purpose effectively. It does not describe the return format (e.g., units of energy), but the absence of an output schema and the simple nature of the tool make this acceptable.
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 all six parameters are already described. The tool description adds no additional parameter information beyond what the schema provides, which is acceptable per the baseline for high coverage.
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 estimates energy consumption for a smart contract call, with the parenthetical 'simulation' specifying that it's a simulation rather than an actual execution. This distinguishes it from related tools like write_contract or update_energy_limit.
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 the tool is used when you want to estimate energy before making a smart contract call, but it does not explicitly state when to use it instead of alternatives. No direct alternatives or exclusions are mentioned, though the context is reasonably clear.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the constraint that the contract must be verified and clarifies the return shape (ABI entry array), which adds modest value beyond annotations.
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, focused sentence that communicates purpose, constraint, and return type without any 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?
With only two simple parameters, no output schema, and strong annotations, the description covers the essential context. It could mention error behavior for unverified contracts, but that's a minor gap.
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 clear parameter descriptions. The tool description does not add extra parameter-level meaning, but the schema fully documents the network and contractAddress. 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 action (fetch), resource (contract ABI), and context (from chain, for verified contracts). It also notes the return type, distinguishing it from broader contract tools like get_contract.
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 phrase 'for verified contracts' gives a clear condition for use, and the return type hints at when this is appropriate. It doesn't explicitly name alternative tools, but the context is sufficient for a simple read operation.
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?
Annotations already declare the tool read-only, idempotent, and not destructive. The description adds value by disclosing the scope of returned data (balance, resources, permissions, frozen balance, votes), which is not present in annotations. No behavioral contradictions.
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?
A single, front-loaded sentence that immediately states the tool's purpose and enumerates key content without redundancy. Every word earns its place.
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, the description provides a helpful summary of returned fields, making the tool's behavior clear. It is concise but sufficiently complete for a simple read-only getter, though it omits a few potential fields (e.g., address, energy) that might be expected in 'full account information'.
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 fully describes both parameters (address and network) with 100% coverage. The description does not mention parameters, but the schema already provides complete semantic information, matching 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 uses the specific verb 'Get' and identifies the resource as 'full account information', explicitly listing key components (balance, resources, permissions, frozen balance, votes). This distinguishes it from narrower sibling tools like get_account_balance or get_account_resource.
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 word 'full' implies this is the comprehensive option versus more specific sibling tools, but there is no explicit statement of when to use this tool or that more specific tools exist for narrower queries. Usage context is implied rather than stated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by specifying the historical block scope and native TRX asset. It does not contradict annotations, though it omits details like the requirement for both blockHash and blockNumber.
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, focused sentence that front-loads the action and resource, with no irrelevant information or 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 simple, read-only nature, the schema covers parameters, and annotations cover safety; the description is sufficient for selection. The absence of an output schema and lack of guidance on the dual block identifiers are minor gaps, but overall the description is complete enough for a low-complexity 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?
The input schema provides full descriptions for all four parameters (100% coverage), so the description does not need to add much. It adds no additional parameter semantics beyond the schema, which is acceptable per the baseline.
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 'Get account TRX balance at a specific block height' uses a specific verb and resource, clearly distinguishing it from sibling tools like get_balance and get_token_balance by focusing on TRX and a specific block height.
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 when to use the tool (when a historical TRX balance at a given block height is needed) but does not explicitly state when not to use it or mention alternatives such as get_balance for current balances. It provides clear context but lacks exclusions or alternative tool references.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral context by specifying the exact resource categories returned, which goes beyond the annotations. It does not introduce any contradictions or unexplained 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?
The description is a single, concise sentence that front-loads the action and resource, followed by a clear list of included details. 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?
For a read-only resource getter with two parameters, the description adequately covers the return content (energy, bandwidth, frozen balance, delegation info) despite lacking an output schema. It could be more comprehensive about the network parameter or response structure, but it is sufficient for selection and invocation.
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 the schema already explains both parameters (address and network). The description does not add any additional meaning or usage details for the parameters, earning the baseline score 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 uses a specific verb ('Get') and resource ('account resource details') and enumerates concrete content: energy, bandwidth, frozen balance, and delegation info. This clearly differentiates it from sibling tools like get_account, get_account_net, and get_delegated_resource.
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 resource-related details but does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions. While the content list hints at its purpose, it lacks explicit 'use this when' 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description complements this by explicitly stating the return content ('block header and transaction list'), which is valuable given the absence of an output schema. It does not mention error cases or network behavior, but the bar is lowered by annotations.
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 concise, front-loaded sentences with no filler. Every word adds value – it states the query mechanism and the expected result.
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 read-only tool with two parameters and good annotations, the description covers the essential purpose and return type. However, it omits details about behavior for nonexistent block heights or invalid network names, which would make it fully complete. The return value description partially compensates for the lack of an output schema.
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 (both 'num' and 'network' have meaningful descriptions). The tool description adds no additional parameter semantics, so it meets the baseline of 3 for high schema coverage.
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 ('Query') and the resource ('block by block height'), and specifies the return content ('block header and transaction list'). This distinguishes it from sibling tools like get_block_by_id, which query by hash.
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 usage context is implied by the phrase 'by block height' – the tool is for when you have a block number. However, it does not explicitly mention alternatives or exclusion criteria, leaving it to the agent to infer when to prefer this over other block-querying 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the time boundary ('since No. 54 Committee Proposal took effect') but does not detail the return format, data source, or any limitations. It provides some additional context but does not go beyond what annotations cover.
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, well-structured sentence that immediately states what the tool does. No unnecessary wording or repetition.
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's simplicity, the description, schema, and annotations together provide sufficient context. The purpose is clear, safety hints are present, and network default is documented in the schema. The lack of an output schema is a minor gap, but not critical for this straightforward query.
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 schema describes the only parameter ('network') with 'Network name. Defaults to mainnet.', giving 100% coverage. The description does not mention parameters but also does not need to, since the schema already provides the semantics. 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 'Query the total amount of TRX burned from on-chain transaction fees since No. 54 Committee Proposal took effect.' This uses a specific verb ('Query') and resource ('total amount of TRX burned'), and uniquely distinguishes it from sibling tools by its precise scope.
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: it is used to retrieve the cumulative TRX burn since a named committee proposal. While it does not explicitly name alternatives or exclusion conditions, the unique scope makes the use case obvious. This qualifies as 'clear context, no exclusions.'
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the Stake 2.0 scope and timestamp, but does not disclose additional behaviors such as default network handling or error conditions.
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, well-structured sentence that immediately conveys the tool's purpose without unnecessary words. It is front-loaded and efficient.
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 tool is simple, has a complete schema, and strong annotations. The description explains what the tool returns and its scope. No output schema exists, but the return concept ('amount') is clear. Minor lack of info about return format or edge cases prevents a 5.
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 all three parameters are already documented. The description does not add extra parameter-level details beyond stating the overall purpose (withdrawable unstaked TRX amount), which is the result rather than parameter semantics. Baseline 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 function with a specific verb ('Get') and a specific resource ('withdrawable unstaked TRX amount'), and scopes it to an address, timestamp, and Stake 2.0. This distinguishes it from sibling write tools like withdraw_expire_unfreeze and related query tools like get_available_unfreeze_count.
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 this tool: to check the withdrawable unstaked amount for a given address and timestamp in Stake 2.0. It does not explicitly name alternatives or exclusions, but the specificity of the description makes the use case apparent.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds valuable behavioral context by stating the tool returns 'historical' data, which goes beyond the schema and clarifies the temporal scope. No contradictions with annotations.
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, concise sentence that is front-loaded with the verb and resource. Every word adds value, with no redundancy or filler.
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 tool is simple with one optional parameter, no required parameters, and no output schema. The description combined with annotations gives a sufficient understanding of what the tool does and its safety profile. However, it does not elaborate on the return format or time range, which would make it fully complete, but given the low complexity, this is adequate.
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% coverage for the single optional parameter 'network', with its own description. The tool description adds no additional parameter semantics, so the baseline of 3 applies as the schema already documents the parameter fully.
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 uses a specific verb 'Query' and a specific resource 'historical energy unit price on the TRON network', clearly distinguishing it from similar siblings like get_bandwidth_prices. The inclusion of 'historical' further differentiates it from estimate_energy, which is forward-looking.
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 when to use it (when needing historical energy prices) but provides no explicit guidance on when not to use it or what alternatives exist. It does not mention related tools like get_bandwidth_prices or estimate_energy, leaving usage context to be inferred from the tool name and 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the 'specific' and 'governance' context but does not disclose behavior like error handling for non-existent IDs or pagination/return format. Given the strong annotations, this is acceptable but not rich.
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?
A single, front-loaded sentence that conveys the essential purpose immediately. No wasted words, no repetitive information, and every part serves meaning.
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 read-by-ID tool, the description plus annotations and schema provide adequate context. It lacks explicit output details (no output schema), but for a basic fetch operation this is generally sufficient. Given the simplicity, it does not need extensive elaboration.
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 both parameters (network and proposalId) are already well-documented. The description's 'by its ID' aligns with proposalId but adds no additional semantic detail. Baseline 3 applies since the schema does the heavy lifting.
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 uses a specific verb ('Get'), clearly identifies the resource ('details of a specific governance proposal'), and specifies the identifier ('by its ID'). This distinguishes it from siblings like list_proposals (which lists) and approve_proposal/delete_proposal (which mutate).
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 clearly implies usage when you already have a proposal ID, which is the primary use case. It does not explicitly name alternatives like list_proposals for enumeration, but the context is clear. Minor exclusion guidance could be added, but not required.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, so the safety profile is well covered. The description adds that it returns the full list of all witnesses, which is useful context, but it does not disclose potential response size or ordering behavior. Given the strong annotation coverage, a 3 is appropriate.
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, concise sentence that front-loads the action and resource. No wasted words; it earns its place.
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 read-only list tool with one optional, well-documented parameter, the description plus annotations provide sufficient context. It clearly states the return scope ('full list of all') but could potentially mention that the response might be large or that pagination is available via a sibling. This is a minor gap for an otherwise simple 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?
The only parameter, 'network', is fully described in the schema ('Network name. Defaults to mainnet.'). The description adds no additional parameter semantics beyond what the schema provides, so the baseline 3 applies when schema coverage is 100%.
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 uses the specific verb 'Get' and explicitly states the resource: 'full list of all Super Representatives (SR / witnesses) on the network.' It clearly distinguishes itself from the sibling tool get_paginated_witnesses by emphasizing 'full list', which implies this returns all witnesses rather than a paginated subset.
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: it returns the complete set of witnesses, implying use when the full list is needed. However, it does not explicitly mention the alternative get_paginated_witnesses for paginated access or state when not to use this tool, so it falls short of explicit exclusion 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the specific behavior of detecting Base58 or Hex format, which is not provided by annotations, enriching the tool's 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?
A single sentence, front-loaded with the action, and no unnecessary words. Every part of the description contributes to understanding 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?
Given the tool's simplicity (one parameter, no output schema) and strong annotations, the description is sufficient. It explains what the tool does and what it detects, though it does not specify the exact return format, which is acceptable for a simple validation 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 coverage is 100%, with the parameter 'address' described as 'Address to validate'. The tool description does not add further semantic detail beyond the schema, so the baseline 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 uses a specific verb 'Validate' with a clear resource 'TRON address' and states the outcome 'detect its format (Base58 or Hex)'. This clearly distinguishes it from sibling tools like convert_address, which likely converts without validating.
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 its use case (checking validity and format) but does not explicitly mention when to choose this over alternatives. No exclusions or alternative tool references are provided, so guidance is only implied.
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?
Annotations already indicate a destructive write operation (readOnlyHint=false, destructiveHint=true). The description adds the timing constraint and effect ('return TRX to available balance') but does not explain failure modes or what happens if called too early. With annotations covering the safety profile, this is adequate but not rich.
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 with no filler. The first sentence states the action clearly, and the second provides timing and effect. Every word earns its place.
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's simplicity (one optional parameter, no output schema), the description covers purpose, timing, and effect effectively. It could mention return format or error handling, but these are not critical for basic invocation.
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 only parameter (network) is fully documented in the schema with name and default. The description adds no extra semantic information about the parameter, so the baseline of 3 applies per the schema coverage rule.
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'), the target ('expired unfrozen balance'), and the context ('Stake 2.0', 'after the unfreezing period'). It differentiates from siblings like unfreeze_balance_v2 and withdraw_balance by specifying the exact condition and purpose.
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 instructs to call 'after the unfreezing period', providing a clear usage condition. It does not name alternatives or when-not-to-use, but the timing context sufficiently distinguishes this from related unstaking 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context beyond annotations: it explains the data source (TronGrid indexed data), the pagination approach (limit + fingerprint), and the default/max limits. This extra context helps the agent anticipate how the API behaves.
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 purpose, and contains no superfluous wording. Every sentence earns its place: the first clarifies the exact resource, the second provides essential pagination constraints.
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 adequately covers the core purpose and pagination, but with 9 parameters and no output schema, it does not fully explain return value shape, sorting behavior, or how filters (minTimestamp, onlyConfirmed, etc.) interact. For a relatively complex tool, this leaves some gaps that an agent must infer from parameter descriptions.
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 the baseline is 3. The description mentions pagination via 'limit + fingerprint' and default/max limits, but these details already exist in the schema's parameter descriptions. The description adds no new semantic meaning beyond what the schema already provides.
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 uses a specific verb ('Get') and clearly identifies the resource ('internal transactions for an account'), and further clarifies that these are triggered by smart contract execution. This effectively distinguishes the tool from siblings like get_account_transactions and get_contract_internal_transactions.
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: to fetch internal transactions from TronGrid indexed data. It also states the pagination mechanism and limits. It does not explicitly name alternatives or exclusions, but the specialized nature of 'internal transactions' strongly implies the appropriate use case.
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 is consistent with the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) and confirms a read-only operation. However, it adds no additional behavioral context beyond what the annotations already provide, such as return format or any edge cases, though the tool's simplicity reduces the need for more.
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, well-structured sentence that immediately states the tool's purpose. Every word contributes meaning, with no fluff or redundant phrasing.
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?
For a no-parameter, read-only list tool, the description fully conveys the scope ('all supported TRON networks') and the action. With annotations describing safety and idempotency, and no output schema required for such a simple return, the description is complete.
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 input schema has zero parameters, so the baseline is 4. The description adds no parameter information because none exist, and that is appropriate; the schema already fully covers this aspect.
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 uses a specific verb ('Get') and resource ('list of all supported TRON networks'), precisely stating the tool's function. This clearly distinguishes it from sibling tools like get_chain_info and get_node_info, which target different resources.
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 whenever a list of supported networks is needed, but it does not explicitly state when to use it or mention alternatives. There are no sibling tools that provide the same functionality, so the guidance is adequate but not explicit about exclusions 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the context that this is from the pending pool, but does not disclose additional behavior such as error handling, return format, or the volatility of pending transactions.
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, succinct sentence that front-loads the purpose and contains no unnecessary words. It is concise and well-structured.
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?
For a simple read-only get-by-ID tool, the description adequately states what it does, and the schema/annotations cover parameters and safety. The only minor gap is lack of mention of the return value format, but 'details' implies the transaction object is returned, which is sufficient.
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?
Both parameters (txId and network) have full descriptions in the schema, achieving 100% coverage. The description adds no new information beyond restating that the lookup is by transaction ID, so it doesn't enhance understanding 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 action (get), the resource (transaction details), and the scope (from the pending pool) using the transaction ID. This distinguishes it from sibling tools like get_transaction (on-chain) and get_pending_transactions (list).
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 implies the use case for retrieving a single pending transaction by ID, but does not explicitly contrast it with alternatives such as get_transaction or get_transaction_by_id. The 'pending pool' scope provides clear context for when to use this tool, though no exclusions are mentioned.
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?
Annotations already mark this as destructive (`destructiveHint: true`), and the description adds valuable context about exactly what gets affected: waiting-period funds are re-staked, and expired funds are auto-withdrawn to the owner. This goes beyond the annotation's generic warning.
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, information-dense sentence that front-loads the core action ('Cancel unstakings') and then explains the two scenarios. There is no redundancy or filler; every clause adds meaningful detail.
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's simplicity (one optional parameter, no output schema), the description covers the primary behavior well. It lacks details about the return value or any prerequisites, but these are not critical for a straightforward cancellation action.
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 only parameter `network` is fully documented in the schema with a description and default value. The tool description does not need to add more, and the schema coverage is 100%, 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 states a specific action ('Cancel unstakings') and explains the two outcomes: re-staking funds still in the waiting period and auto-withdrawing funds past the 14-day period. This distinguishes it from related tools like `unfreeze_balance_v2` and `withdraw_expire_unfreeze`.
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 makes it evident that this tool is for canceling all unfreeze operations by combining re-staking and withdrawal behaviors. It does not explicitly name alternatives or provide exclusion criteria, but the context is clear enough for an agent to select it over per-item 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds the critical auth requirement of needing the contract creator's wallet. It also uses 'on-chain' to imply a permanent state change, going beyond the annotations.
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, front-loaded sentence that conveys purpose and a key context in just 15 words. Every word is informative, with no redundancy or filler.
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 destructive operation with no output schema, the description covers the purpose, the target resource, and a key access constraint. Combined with the destructiveHint annotation and complete param schema, the context is sufficient for safe invocation.
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 already provides full descriptions for both parameters (contractAddress and network, with network defaulting to mainnet). The description adds no additional parameter-level meaning, so the baseline of 3 for 100% schema coverage applies.
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 uses a specific verb 'Clear' with a clear object 'on-chain ABI metadata of a contract', making the purpose unmistakable. It distinguishes itself from sibling tools like fetch_contract_abi (retrieve) and write_contract (modify) by indicating this is a removal operation.
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 states a clear prerequisite: 'Requires the contract creator's wallet', which is essential context for when to use this tool. It does not explicitly mention alternatives or exclusions, but for a specialized clearing operation this is sufficient 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?
Annotations already declare readOnly=false, idempotent=true, destructive=false. The description adds valuable context: the recipient is auto-activated if it doesn't exist, and the return value is an unsigned object that must be signed before broadcasting. This goes beyond the annotation metadata and offers insight into the expected workflow.
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 concise sentences that front-load the primary action and then add the two most important caveats (auto-activation and signing requirement). There is no filler or redundant content.
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 tool is simple, and the description covers the core purpose, the required follow-up action (sign and broadcast), and a key behavioral side-effect. With no output schema, noting that it returns an unsigned transaction object is sufficient, though it could explicitly mention broadcast_transaction as a next step.
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 covers 100% of parameters with clear descriptions (amount in SUN, Base58 addresses, network default). The description does not add further parameter-level meaning beyond what the schema already provides, so the baseline 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 states a specific action: 'Create an unsigned TRX transfer transaction.' It clearly distinguishes this tool from sibling tools like transfer_trx by emphasizing the unsigned nature and the need to sign before broadcasting, indicating it is a preparation step, not a direct transfer.
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 implies usage: when you need an unsigned transaction for later signing, and it mentions the auto-activation behavior. However, it does not explicitly name alternative tools (e.g., transfer_trx or broadcast_transaction) or state when not to use this tool, so it lacks explicit exclusions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: data comes from the TronGrid indexer and may have slight delays compared to on-chain state. This transparency about data freshness is important for user expectations and goes beyond the structured annotations.
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 purpose. The first sentence immediately states what the tool does, and the second sentence adds a necessary caveat about data delays. Every sentence 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?
Without an output schema, the description carries the burden of explaining what the tool returns. It enumerates the key data categories (TRX balance, TRC20 balances, frozen resources, votes) and notes the data source and potential staleness. This is sufficient for a read-only info tool, though it could be slightly more explicit about the response 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 coverage is 100%, and each parameter (address, network, onlyConfirmed) has a clear description. The tool description does not add param-specific detail beyond what the schema provides, but it does set context by listing the data categories returned, which indirectly clarifies the purpose of the address parameter. This aligns with the baseline 3 for high schema coverage.
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 uses a specific verb ('Get') and resource ('comprehensive account information'), and enumerates the exact data categories (TRX balance, TRC20 balances, frozen resources, votes). This clearly distinguishes it from sibling tools like get_balance or get_token_balance, which are narrower in scope.
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: it is for comprehensive account data sourced from the TronGrid indexer. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5. The 'comprehensive' framing implies it is for broad overviews rather than specific queries.
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?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a meaningful behavioral constraint: the node must enable historical balance query. This is valuable context beyond the annotations.
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 concise sentences with the purpose front-loaded. No unnecessary information, every sentence earns its place.
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 exists, but the description communicates the return scope ('all balance change operations') and a key prerequisite. It could benefit from describing the structure of these operations, but given the tool's simplicity and rich annotations, it is sufficiently 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 description coverage is 100% and all parameters are described. The description reiterates the hash and number requirements but does not add new meaning beyond the schema. 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 specific action ('Get all balance change operations') and the resource ('in a block'), distinguishing it from sibling tools like get_block or get_balance. The additional requirements of block hash and number add further specificity.
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 by listing required inputs (block hash and number) and a critical prerequisite (node must enable historical balance query). It does not explicitly name alternatives, but the prerequisites effectively guide usage.
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?
Beyond the readOnlyHint annotation, the description adds useful behavioral context: it starts from the latest solidified block and returns blocks in descending height order. This clarifies the exact base point and ordering, which is not inferable from the schema or annotations.
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?
A single, front-loaded sentence conveys all essential info without waste. It states the action, object, scope, and ordering efficiently.
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 read-only tool with no output schema, the description adequately explains what is returned (blocks) and their order. It doesn't detail block fields, but that's likely consistent with sibling tools. Minor gap: no mention of whether the response includes full block content or just summaries.
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 for parameters is 100% (num and network both have descriptions). The tool description doesn't add significant semantics beyond the schema, so the baseline 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 retrieves the most recent N blocks, with specific scope (starting from the latest solidified block) and ordering (descending height). This distinguishes it from sibling tools like get_latest_block (single block) or get_block_by_num (specific block number).
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 on when to use this tool (when you need the latest N blocks in descending order). It doesn't explicitly name alternatives or state exclusions, but the scope and ordering make the intended 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?
Annotations already indicate a safe, read-only, idempotent operation. The description adds valuable behavioral details: the data source ('TronGrid indexed data') and pagination characteristics ('Supports pagination via limit + fingerprint. Default 20, max 200'). It does not cover rate limits or index lag, but the added context is sufficient given the annotation coverage.
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 purpose, and includes only essential operational details. Every sentence earns its place without 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 9 parameters and no output schema, the description explains the core function and pagination but not the response structure or return format. However, the tool name and description make the response type obvious (internal transactions), and the schema covers parameter details. It is mostly complete for a read-only list tool with rich annotations.
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 the baseline is 3. The description mentions default 20 and max 200, but this duplicates the existing limit parameter description. No additional parameter meaning is provided 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 a specific action ('Get') and resource ('internal transactions for a contract address'), and clarifies the nature of internal transactions as 'triggered by smart contract execution.' This distinguishes it from sibling tools like get_contract_transactions (regular transactions) and get_events_by_contract_address (events).
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: use this tool to fetch internal transactions for a contract address. It implicitly differentiates from regular transaction tools by specifying 'internal' and the execution trigger, but does not explicitly name alternatives or exclusions. Sibling tools like get_contract_transactions are not referenced, so an agent must infer the distinction.
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?
Annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds value by explaining the exact content of the index (incoming and outgoing delegation), which is behavioral context beyond the annotations. No contradictions detected.
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, front-loaded sentence that clearly conveys the tool's purpose and key details. It contains no unnecessary words or repetition.
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 tool is simple with two parameters and no output schema. The description sufficiently explains what the returned index contains, which addresses the absence of an output schema. It does not mention potential edge cases or pagination, but those are not critical for this straightforward read operation.
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 covers both parameters (address and network) with descriptions at 100% coverage. The description does not add any additional parameter-level semantics beyond what the schema already provides, so the baseline 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 function: retrieving the delegated resource account index for an address under Stake 2.0. It also specifies the two directions (who delegated to this address and who this address delegated to), which distinguishes it from sibling tools like get_delegated_resource_index or get_delegated_resource_v2.
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 gives clear context by mentioning 'under Stake 2.0', which helps the agent know when to use this tool. However, it does not explicitly mention alternatives or state when not to use it, despite the presence of similar 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?
The description adds a key behavioral trait—'Can only be set once'—beyond the annotations, which already mark it as destructive and non-idempotent. This clarifies irreversibility, though it doesn't detail side effects or failure behavior.
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 short sentences, front-loaded with the action and resource. No redundant information. Every word earns its place.
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 setter tool, the description covers the essential purpose and the critical one-time constraint. The schema handles parameter specifics, and no output schema is needed. Could mention prerequisites like having a configured wallet, but that's implied by 'configured wallet'.
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 (network and accountName) already described in the schema. The tool description adds no additional parameter meaning, so the baseline score of 3 applies.
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 ('Update') and the specific resource ('name of the configured wallet's account'), with a precise constraint ('Can only be set once'). This distinguishes it from other update* tools in the sibling list, which target different resources.
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 context is clear: use it to rename the currently configured wallet's account. However, it doesn't explicitly mention alternatives or when not to use it, though the 'Can only be set once' hint implies it should not be called repeatedly.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds meaningful context by stating the authentication requirement (creator's wallet) and clarifying the meaning of originEnergyLimit. It does not contradict annotations.
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 concise sentences, front-loaded with the action and parameter, and contains no redundant 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?
For a simple tool with good annotations and full schema coverage, the description covers the essential purpose and the key prerequisite (creator's wallet). It lacks explicit side-effect or alternative guidance, but the annotation context makes this sufficient.
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 adds slight semantic context for originEnergyLimit ('max energy the contract creator will pay per execution') beyond the schema, but does not compensate for the already well-documented 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?
The description clearly states the action ('Update'), the resource ('a contract's originEnergyLimit'), and explains what that value means ('max energy the contract creator will pay per execution'). This distinguishes it from sibling tools like update_contract_setting, which would handle broader settings.
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 implies usage when adjusting the originEnergyLimit, and the prerequisite 'Requires the contract creator's wallet' provides important context. However, it does not explicitly mention alternatives or exclusion conditions, which would elevate it to a 5.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, signaling a write operation without destructive side effects. The description adds the vote conversion rate (1 frozen TRX = 1 vote), which is useful. However, it does not clarify whether votes are additive or replace existing votes, a key behavioral detail.
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, well-structured sentence that front-loads the primary action and provides the essential explanation of voting power. 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?
For a tool with moderate complexity (array parameter, network option), the description covers the core purpose, prerequisite, and vote semantics. It lacks a note about overriding existing votes or interaction with other vote-related tools, but overall it is complete enough 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 input schema provides 100% coverage of both parameters, so the baseline is 3. The description adds meaningful semantic value by explaining the meaning of voteCount (each frozen TRX equals one vote), which is not fully clear from the schema alone.
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 Representatives), and the mechanism (TRON Power). This distinguishes it from sibling tools like delegate_resource or freeze_balance_v2, which serve different purposes.
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 implies the proper usage context by explaining that TRON Power comes from freezing TRX, which establishes a prerequisite. It does not explicitly name alternatives or when not to use, but the context is clear enough for a simple operation.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds meaningful context by specifying the SR-only and creator-only permissions, which are important behavioral restrictions beyond what annotations convey.
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, front-loaded sentence that conveys the action, resource, and constraints without any fluff. It earns its place.
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?
For a simple delete operation with no output schema, the description covers the essential aspects: what is deleted and under what conditions. Annotations cover destructiveness, and the schema covers parameters, leaving no significant gaps for an agent to 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?
Schema coverage is 100%, with both parameters (network and proposalId) already described. The description does not add detail about parameter formats or defaults beyond the schema, so the baseline 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 action (Delete), the resource (a governance proposal), and includes specific constraints (SR only, only the creator can delete it). This distinguishes it from sibling tools like create_proposal and approve_proposal.
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 explicit context on when the tool is applicable: it is restricted to SRs and only the proposal creator. This implies when not to use it. It does not name alternatives, but the constraints are clear enough for an agent to decide.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds the return contents (block header and transaction list) not covered by annotations. This provides concrete behavioral output information without contradicting the read-only nature.
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-load the action and resource, with no redundant phrasing. The sentence about return content adds necessary value and every word earns its place.
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?
For a simple read-only lookup with strong annotations, the description adequately covers purpose, input type (hash), and output (header and transactions). It is sufficient for an agent to select and invoke correctly amid many sibling block-related tools.
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%; both value and network parameters are described. The description's mention of 'block ID (hash)' largely mirrors the schema's value description and adds no new parameter-level semantics. The baseline of 3 is appropriate given high schema coverage.
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 queries a block by its ID (hash) and specifies the return content as block header and transaction list. This distinguishes it from sibling tools like get_block_by_num and get_latest_block by emphasizing the hash-based identifier.
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 phrase 'by block ID (hash)' implies use when a block hash is available, which is a clear usage context. It does not explicitly name alternatives like get_block_by_num, but the large sibling list and this description make the appropriate scenario straightforward.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is well-covered. The description adds the 'configured wallet' concept but does not disclose additional behavioral traits such as what happens if no wallet is configured, which is acceptable for a simple getter with strong annotations.
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 tight sentences, front-loaded with the core action and followed by a targeted use case. No extraneous 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?
For a zero-parameter, no-output-schema getter, the description fully covers what the tool does and when to use it. With good annotations and no complexity, additional details are unnecessary.
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 there is nothing to explain. Baseline is 4 for no params; the description appropriately avoids redundant parameter details.
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 uses a specific verb ('Get') and resource ('address of the configured wallet'), clearly distinguishing it from siblings like list_wallets and select_wallet. The added phrase 'Use this to verify which wallet is active' further clarifies its unique purpose.
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 states a clear use case: 'Use this to verify which wallet is active.' It does not explicitly compare with alternatives or state when not to use it, but the context is clear enough for an agent to select it over sibling list/select 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?
The description adds meaningful behavioral context beyond the annotations: it specifies that only an SR can invoke the tool and explains the economic effect (the SR keeps a percentage, the remainder goes to voters). This aligns with annotations (readOnly=false, destructive=false) and enriches understanding without contradiction.
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 (three clauses), efficient and front-loaded. Every phrase adds value: the action, the synonym, the authorization, and the parameter meaning. No fluff 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?
For a simple tool with only two parameters (one required), full schema coverage, and no output schema, the description sufficiently covers core functionality, authorization, and parameter semantics. There is no critical missing information for correct invocation.
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 already provides comprehensive descriptions for both parameters (network defaults to mainnet; brokerage range 0-100 with an example). The description adds only a minor extra detail (the remainder goes to voters), which is also somewhat implied by the schema's example. Schema coverage is 100%, 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 clearly states the action ('Update') and the resource ('SR brokerage ratio'), with the clarifying synonym 'dividend ratio'. It is unambiguous and distinct from sibling tools like get_brokerage, which is read-only.
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 changing the brokerage ratio) and includes an explicit authorization restriction ('Only callable by an SR'), which serves as a when-not condition. It does not explicitly mention alternatives, but the specific purpose makes the appropriate usage evident.
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?
The description adds context beyond the annotations, specifying the source (accumulated voting rewards) and destination (available balance). It is consistent with readOnlyHint=false. It does not mention side effects or permissions, but the annotations provide the basic safety profile, so this is acceptable.
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, clear sentence with no redundant words. It is front-loaded and efficiently conveys the essential information.
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 simple action, one optional parameter, and adequate annotations, the description provides sufficient context. It states what the tool does and where the funds go, and the schema defines the network parameter. No output schema is present, so not explaining return values is acceptable.
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 schema provides full coverage of the only parameter (network) with a description. The tool description adds no additional meaning beyond that. Baseline 3 is appropriate since the schema does the heavy lifting.
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), the resource (accumulated voting rewards), and the destination (configured wallet's available balance). It is specific and distinguishes from siblings like withdraw_expire_unfreeze, which deals with unfreeze withdrawal, not voting rewards.
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 implies when to use: when there are accumulated voting rewards to withdraw. It mentions the configured wallet, giving some context, but does not explicitly note when not to use or mention alternatives. It is clear enough for a simple action.
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?
Annotations already indicate non-read-only and destructive. The description adds meaningful context by disclosing bandwidth cost from the configured wallet, an external effect not present in annotations. It also notes the requirement for pre-generation, adding behavioral nuance without contradicting annotations.
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 with the primary function stated first, followed by essential cost and prerequisite details. No filler or unnecessary repetition.
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 activation tool with no output schema, it covers the action, cost, and prerequisite. Minor gaps include lack of mention of the network parameter's behavior and return value, but these are either covered by schema or non-critical.
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%, so the baseline is 3. The description adds value beyond the schema by clarifying that the address parameter must reference an already-generated address, which is a semantic prerequisite not present in the schema description.
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 uses specific verb 'activate' and resource 'new account on the TRON network', clearly distinguishing from sibling generate_account by stating the address must be generated beforehand. This makes the tool's purpose unambiguous.
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?
It provides a clear prerequisite (address must be generated beforehand) and a key cost implication (bandwidth from configured wallet). While it doesn't explicitly name alternative tools or state when not to use, the context strongly implies using generate_account first.
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 annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds valuable behavioral context: pagination via limit+fingerprint, default of 20 results, max of 200, and the fact that it covers all transaction types. This goes beyond the annotations and enriches the agent's understanding of how the tool behaves without contradicting any structured metadata.
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 long, front-loaded with the core purpose, and every clause earns its place. It covers purpose, data source, scope, and pagination without any fluff or redundancy. Exceptional conciseness.
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 read-only tool with 9 parameters and no output schema, the description covers the essential context: what it returns (all transaction types), data source, pagination behavior, and defaults. The parameter details are handled by the schema, so the description doesn't need to repeat them. It is slightly light on response structure, but given the tool's simplicity and annotations, it is sufficiently complete.
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%, so the parameters are well-documented individually. The description adds integrated semantic value by explaining the pagination relationship between limit and fingerprint and stating defaults/max, which is not obvious from the schema alone. This pushes it above 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 opens with a specific verb+resource: 'Get transaction history for an account from TronGrid indexed data.' It further clarifies scope by stating 'Returns all transaction types (TRX transfers, contract calls, etc.)', which distinguishes it from specialized siblings like get_account_trc20_transactions or get_transaction. This is a textbook clear purpose.
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 by specifying it returns all transaction types and is sourced from TronGrid indexed data, which implies it is the general-purpose history tool among siblings. However, it does not explicitly mention alternatives or when not to use it (e.g., 'for TRC20-only, use get_account_trc20_transactions'), so it falls short of a perfect 5.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds useful behavioral details like skipping empty blocks, page size limits, and indexing lag. It doesn't disclose exact page size or pagination method, but the advisory about limits is valuable.
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-load the purpose, then state limitations and alternative, with no redundant words or repetition of schema content.
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 exists, but the description effectively covers return limitations (page size, indexing lag) and points to the sibling for precise control. It could mention event structure or pagination handling, but is largely sufficient 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%, so both parameters (network, onlyConfirmed) are well-documented. The description adds no extra parameter-specific semantics, which is acceptable given the schema handles 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 tool retrieves events from the most recent non-empty block, emphasizing it skips empty blocks. This distinguishes it from siblings like get_events_by_block_number and get_events_by_transaction_id.
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?
It explicitly mentions limitations (default page size, indexing lag) and recommends get_events_by_block_number for precise control with pagination, providing a clear alternative and when to use it.
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?
Annotations already declare the operation as read-only, idempotent, and non-destructive, so the bar is lower. The description adds valuable behavioral context beyond annotations: the data source is 'TronGrid indexed data' (suggesting possible latency), it specifies the return shape (addresses and balances), and explicitly notes pagination via limit + fingerprint. It does not discuss rate limits or data freshness, but the added details are meaningful.
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 compact and ends with the most important operational note (pagination) up front. Every word earns its place: it states the action, resource, data source, return contents, and pagination method in just two sentences. No filler or 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?
With no output schema, the description partially compensates by stating what is returned ('holder addresses and their balances'). The 5 input parameters are well-documented in the schema, and the description highlights the key interaction between limit and fingerprint. It lacks mention of orderBy behavior or potential data lag, but given the simplicity of the tool and the annotation coverage, it is sufficiently complete for an agent to invoke it 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?
Schema descriptions cover 100% of parameters, giving the baseline a 3. The description adds a layer of semantic meaning beyond schema by stating that pagination is handled via 'limit + fingerprint', which implies these two parameters work together. This is extra context not present in the individual schema entries, so a 4 is justified.
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 uses a specific verb+resource combination: 'Get token holder list for a TRC20 contract' and clearly distinguishes from sibling tools like get_account_trc20_balances and get_token_balance. It also specifies the data source (TronGrid indexed data) and the core output (holder addresses and balances), leaving no ambiguity about what the tool does.
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 (to enumerate holders of a TRC20 token from indexed data). It implies the use case without explicitly naming alternatives or exclusions, but the context is strong enough for an agent to select it over retrieval of account-specific balances or general contract reads.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the key authorization constraint (creator's wallet) which the annotations don't convey. It doesn't detail potential side effects, but given annotation coverage, this is acceptable.
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 short sentences delivering action, parameter explanation, and a prerequisite. No fluff, front-loaded with the verb. Every clause earns its place.
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 update tool without output schema, the description covers the essential points: action, parameter, and authorization. It omits details like transaction outcomes, but the annotations and simple schema keep the informational load manageable.
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?
Input schema covers all parameters (100% coverage). The description adds semantic value by explaining consume_user_resource_percent as 'user pay ratio', going beyond the schema's generic description. This extra context aids correct value selection.
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 specifies exact action 'Update' with precise resource 'consume_user_resource_percent (user pay ratio)', clearly distinct from sibling tools like update_energy_limit or write_contract. The parenthetical clarifies the domain meaning, removing ambiguity.
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 a clear prerequisite ('Requires the contract creator's wallet'), which sets expectations for when the tool can be invoked. However, it does not explicitly contrast with alternatives or state 'when not to use', leaving some room for inference.
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?
The description adds behavioral context beyond the readOnlyHint annotation by specifying offline generation and the exact return fields. It also discloses the absence of network interaction, which is useful for the agent to understand side effects. There is no contradiction with annotations.
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 function, and contains no filler. Every sentence earns its place, conveying both purpose and key behavioral constraints succinctly.
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?
For a simple tool with no parameters and no output schema, the description fully covers what the tool does, its outputs, and its network behavior. The agent has enough information to select and invoke the tool correctly without needing further guidance.
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 there are no parameter semantics to clarify. The baseline for zero parameters is 4, and the description appropriately adds no unnecessary parameter information.
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 generates a new TRON account offline via keypair generation, distinguishing it from on-chain account creation siblings like create_account by noting no network interaction. It also lists the exact outputs (privateKey, publicKey, address), making the purpose unambiguous.
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 implies when to use the tool by emphasizing 'No network interaction needed,' signaling this is for offline keypair generation. However, it does not explicitly name alternatives or exclusion criteria, unlike the best examples. The context is clear but not fully 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds context beyond annotations by specifying the data source (TronGrid indexed data), the limitation (only contract addresses and raw balances, no metadata), and pointing to a sibling for richer data. This is strong but not exhaustive (e.g., no mention of pagination or formatting).
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 primary purpose, and every clause adds value. The first sentence states what it does; the second clarifies the limitation and provides the alternative. There is no fluff or repetition of schema/annotation information.
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?
For a read-only list tool with good annotations and full schema coverage, this description is complete enough for agent selection and invocation. It communicates scope ('all'), source ('TronGrid indexed data'), output limitation (raw balances only), and directs to the alternative for detailed info. No output schema exists, but the description adequately sets expectations for return content.
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 description adds no parameter-specific information beyond what the schema already provides. The baseline of 3 applies because the schema carries the full burden of parameter semantics, and the description's mention of 'raw balances' is more about output than 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?
The description uses a specific verb plus resource ('Get all TRC20 token balances for an account') and clearly distinguishes from the sibling tool get_token_balance by stating it returns all balances without token metadata. This makes the tool's purpose unambiguous and easy to differentiate.
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?
The description explicitly states what the tool returns and what it does NOT return, then directs users to get_token_balance when detailed token information is needed. This provides a clear when-to-use vs alternative guidance in just two sentences.
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?
Annotations already declare read-only, idempotent, and non-destructive. The description adds behavioral context about pagination via limit/fingerprint and the ability to do full event retrieval, which goes beyond the annotations. However, it does not describe the return format or any network-specific behaviors.
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 the main purpose, then pagination, then the comparison to a sibling. 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?
For a read-only, paginated event query with full schema coverage and strong annotations, the description is sufficient. It provides the core purpose, pagination support, and comparison to an alternative. No output schema exists, but the description's conciseness and the tool's simplicity keep it 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 description coverage is 100%, so the schema already documents all parameters. The description mentions limit and fingerprint in the context of pagination, which adds a small amount of semantic linkage between them, but largely repeats what the schema provides. Baseline 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 events for a specific block, using a specific verb and resource. It also distinguishes itself from get_events_of_latest_block by noting it's preferred for precise block targeting and full event retrieval.
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?
The description explicitly names get_events_of_latest_block as an alternative and states when this tool is preferred. This gives clear context for selecting between them, though it doesn't discuss other sibling event 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?
Annotations already indicate this is a write operation (readOnlyHint=false), idempotent, and non-destructive. The description adds the runtime switching aspect and the Encrypted Storage mode constraint, providing useful context beyond the annotations. No contradiction.
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 the primary action. No filler or redundant information. Every word earns its place.
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?
For a simple tool with one parameter and no output schema, this description is complete. It covers what the tool does, how to get inputs, and a critical precondition (mode). Annotations cover the safety profile.
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 schema covers the single parameter (walletId) with 100% coverage. The description adds context on how to obtain valid wallet IDs (via list_wallets), which gives the parameter practical meaning. This exceeds the baseline for schema-only coverage.
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 ('Switch the active wallet') and the resource ('at runtime'). It distinguishes from siblings by referencing list_wallets, which is relevant since list_wallets is a sibling tool. The purpose is specific and unambiguous.
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 usage context: use list_wallets to find wallet IDs, and notes the Encrypted Storage mode requirement. It doesn't explicitly name alternatives or when-not-to-use, but it gives clear prerequisites and conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: data source (TronGrid indexed data), aggregation by contract, pagination mechanism (limit + fingerprint), and defaults/max page size. This goes well beyond the annotations and sets clear expectations.
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 three sentences long, front-loaded with the core purpose. The second sentence differentiates from a sibling, and the third covers pagination specifics. Every sentence earns its place with no unnecessary fluff.
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 read-only list tool with good annotations and full schema coverage, the description covers purpose, differentiation, and key pagination defaults. It does not describe the output format, but with no output schema and the pagination hint, this is a minor gap. The tool is otherwise well-specified.
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 schema covers all 9 parameters with descriptions, so baseline is 3. The description adds meaning by explaining that transactions are aggregated by contract, giving context to the address parameter. It also explicitly references limit and fingerprint as pagination controls, reinforcing their roles in 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 fetches transaction history for a smart contract from TronGrid indexed data. It explicitly distinguishes itself from get_account_transactions by noting it aggregates transactions BY contract, which differentiates it from the primary sibling tool.
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 names the closest alternative (get_account_transactions) and clarifies the scope difference (by contract vs by account). It also mentions pagination support, implying appropriate use cases. However, it does not explicitly list when-not-to-use scenarios or other alternatives like get_events_by_contract_address.
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:

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

Score Badge

Copy to your README.md:

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

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/BofAI/mcp-server-tron'

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