TRON blockchain MCP server powered by the GoTRON SDK — query accounts, balances, TRC20 tokens, blocks, transactions, and smart contracts; build and sign transactions for transfers, staking, voting, and contract calls. Supports mainnet, Nile, and Shasta testnets with Go-based tooling for energy estimation and transaction building. Available via stdio or hosted Streamable HTTP
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.5/5 across 43 of 43 tools scored. Lowest: 2.7/5.
Several tool groups have overlapping responsibilities (e.g., get_energy_prices/get_bandwidth_prices/get_chain_parameters, get_pending_transactions/get_pending_by_address/is_transaction_pending, and analyze_account vs get_account plus its resource/permission variants). These create boundary confusion despite clear descriptions, and with 43 tools an agent will likely select the wrong one occasionally.
All tools follow a consistent snake_case verb_noun pattern (e.g., get_account, transfer_trx, delegate_resource, unfreeze_balance). Even the few multi-word verbs (estimate_energy, trigger_constant_contract) remain predictable. No camelCase or inconsistent verb styles.
With 43 tools, the server is heavy. While the TRON domain is broad, the tool surface is bloated with many near-synonyms and split functionalities that could be consolidated. The rubric flags 25+ tools as too many; 43 clearly exceeds that.
The server covers a wide range of read and transaction-building operations, including staking, governance, contracts, and TRC20. However, it lacks critical lifecycle steps: there is no sign or broadcast tool, and no ability to deploy contracts or create accounts. This is a significant gap for a tool that returns unsigned transactions.
analyze_accountAComprehensive account overview: balance, resources, staking, voting, permissions, and delegations in a single call
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON base58 address (starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description presents the tool as a read-only overview, but the annotations mark destructiveHint=true and readOnlyHint=false. This is a direct contradiction, as no destructive behavior is disclosed. The description fails to clarify what destructive actions might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that packs a clear list of contents and immediately states the tool's value proposition. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the included data categories, which is useful for understanding the return scope. However, with no output schema and no mention of side effects (especially given destructiveHint=true), the description leaves significant gaps in what the agent should expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the address parameter fully ('TRON base58 address (starts with T)') with 100% coverage. The description adds no additional parameter semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('overview') and enumerates the covered account aspects (balance, resources, staking, voting, permissions, delegations), clearly distinguishing this aggregated tool from the more granular get_account/get_account_resources siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'comprehensive account overview' implies using this when one needs a complete account snapshot, providing clear context. However, it doesn't explicitly state when not to use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_transfer_costBEstimate the cost of a TRX or TRC20 transfer: energy, bandwidth, and TRX burn options
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient TRON address (base58) | |
| from | Yes | Sender TRON address (base58) | |
| amount | Yes | Amount to transfer (e.g., '100') | |
| contract_address | No | TRC20 contract address (omit for TRX transfer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Estimate' which implies a read-only operation, but annotations set readOnlyHint=false and destructiveHint=true, indicating the tool may alter state or be destructive. This is a direct contradiction. The description does not address the 'TRX burn options' side effects or explain why destructiveHint is true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action and key differentiators. Each word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the annotations include a confusing destructiveHint. The description does not explain the return format of the cost estimate, the meaning of 'TRX burn options', or why the tool might be destructive. This is under-specified for an agent to invoke and interpret results confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters (from, to, amount, contract_address) are already described. The description adds little beyond the schema, only referencing TRC20 transfers via contract_address which is already in the schema. It does not clarify which parameter controls the 'TRX burn options'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Estimate the cost of a TRX or TRC20 transfer'. It specifies the resource (transfer) and the components covered (energy, bandwidth, and TRX burn options), distinguishing it from sibling tools like estimate_energy and transfer_trx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a full cost estimate for a transfer is needed, but it does not explicitly mention alternatives or exclusions. It names the coverage (energy, bandwidth, burn) but does not compare with estimate_energy or estimate_trc20_energy, 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.
decode_abi_outputBDecode ABI-encoded output hex from a contract call. Handles return values, revert reasons (Error(string)), and panic codes (Panic(uint256)).
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Hex-encoded output bytes to decode (0x prefix optional) | |
| method | Yes | Method signature (e.g., 'balanceOf(address)') | |
| contract_address | Yes | Contract address (base58, starts with T; needed to fetch ABI for decoding) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Decode ABI-encoded output hex' which implies a non-destructive read operation. However, annotations set destructiveHint=true and readOnlyHint=false, directly contradicting the nature of decode. This is an annotation contradiction, so the score is 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the core function, the second adds value by listing supported decode types. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a relatively simple tool: it explains what it decodes and the supported error types. No output schema is provided, but the description doesn't need to detail returns for this tool. Given the annotation contradiction, there is a slight incompleteness in behavioral expectations, but overall the description is complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptive coverage for all 3 parameters (100%). The description adds no additional parameter-specific details beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Decode ABI-encoded output hex from a contract call.' It distinguishes the tool from siblings by focusing on decoding output, which none of the listed siblings do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no instructions on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a prior contract call result) or contexts where decoding is appropriate, and no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delegate_resourceADelegate energy or bandwidth to another address (Stake 2.0). Returns unsigned transaction hex for signing.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient address (base58, starts with T) | |
| from | Yes | Delegator address (base58, starts with T) | |
| memo | No | Optional memo to attach to the transaction | |
| amount | Yes | Amount in TRX to delegate (e.g., '100.5') | |
| resource | Yes | Resource type | |
| lock_period | No | Lock period in blocks (~3 seconds each). If set, delegation cannot be undone until the lock expires. | |
| permission_id | No | Permission ID for multi-sig transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a crucial behavioral detail not captured by annotations: it returns an unsigned transaction hex for signing, meaning it does not directly execute the delegation. This is significant given destructiveHint=true, as it clarifies that the destructive action is deferred to external signing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, scope, and return behavior with zero wasted words. It efficiently achieves high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter transaction-building tool with no output schema, the description sufficiently covers the core action and return type. It could mention prerequisites or side effects, but annotations and the detailed parameter schema fill major gaps, making it adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have descriptions in the input schema (100% coverage), so the description does not need to add parameter details. The description itself contributes no additional clarification beyond the schema, warranting the schema-heavy baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('energy or bandwidth'), and the target ('another address'), distinguishing it from sibling tools like undelegate_resource. It also mentions 'Stake 2.0' and the unsigned transaction result, leaving no ambiguity about 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only an implied usage context via 'Stake 2.0'. It does not explicitly state when to use this tool over similar alternatives like freeze_balance, nor does it mention when not to use it. This is a typical implied-usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_energyBEstimate energy cost for a smart contract call. Requires a full node with vm.supportConstant=true and vm.estimateEnergy=true; falls back to secondary node if primary does not support it.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Caller address (base58, starts with T) | |
| method | Yes | Contract method signature (e.g., 'transfer(address,uint256)') | |
| params | Yes | Method parameters as JSON array. Plain values: ["TJD...", "1000"] (types inferred from method signature). Typed objects also accepted: [{"address": "TJD..."}, {"uint256": "1000"}] | |
| contract_address | Yes | Smart contract address (base58, starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=true, directly contradicting the description's 'estimate' operation which implies no state change. The description adds no clarification of side effects or safety profile, resulting in a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 provides useful context (node requirements, fallback). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the estimate returns (units, format). It fails to do so, and the contradiction between the read-only nature and destructiveHint annotation leaves the agent uncertain about side effects. The fallback behavior is a positive, but overall completeness is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters are described in the schema. The description adds no parameter-specific details, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Estimate') and resource ('energy cost for a smart contract call'). It distinguishes from sibling 'estimate_trc20_energy' by not limiting to TRC20.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides technical prerequisites (full node capabilities) and fallback behavior, but does not specify when to use this tool versus alternatives or any exclusions. The use case is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_trc20_energyBEstimate energy cost for a TRC20 transfer without creating a transaction. Dry-runs the transfer to check energy requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient address (base58, starts with T) | |
| from | Yes | Sender address (base58, starts with T) | |
| amount | Yes | Amount in human-readable units (e.g., '100.5' for 100.5 USDT) | |
| contract_address | Yes | TRC20 contract address (base58, starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'without creating a transaction' and 'dry-runs', which directly contradicts the annotation destructiveHint=true. This is a major inconsistency. The description also adds some behavioral context (no transaction created), but the contradiction invalidates that benefit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and adds the dry-run behavior without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the return value or output format (no output schema exists), and it fails to reconcile the destructiveHint annotation. For a tool that estimates energy, the agent would benefit from knowing what the response contains (e.g., energy units, cost) and any prerequisites or side effects. The contradiction further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (from, to, amount, contract_address) have descriptions. The tool description does not add any additional parameter semantics beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Estimate energy cost for a TRC20 transfer without creating a transaction.' It uses a specific verb ('estimate') and resource ('TRC20 transfer'), and the 'without creating a transaction' and 'dry-runs' details distinguish it from actual transfer tools like transfer_trc20.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('without creating a transaction', 'dry-runs') which is a clear context for estimation versus actual transfer. It does not explicitly name alternatives or exclusions, but the context is sufficient to guide the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
freeze_balanceAStake TRX for energy or bandwidth (Stake 2.0). Returns unsigned transaction hex for signing.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Account address (base58, starts with T) | |
| memo | No | Optional memo to attach to the transaction | |
| amount | Yes | Amount in TRX to stake (e.g., '100.5') | |
| resource | Yes | Resource type | |
| permission_id | No | Permission ID for multi-sig transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true, but the description adds key behavior: 'Returns unsigned transaction hex for signing.' This tells the agent that the tool does not execute the stake directly but generates a transaction to be signed and broadcast, adding valuable context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main verb 'Stake', and every word earns its place. The second sentence about the return value is essential and not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema, the description is adequate: it states the purpose, the return value, and the resource type. Missing details like locking duration or prerequisites are not critical for the agent's initial evaluation, and the annotations cover the safety profile. Slightly more detail could be added, but the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not add parameter-specific meaning beyond the schema; for example, the 'resource' enum is fully documented in the schema. The description's mention of energy/bandwidth aligns with the parameter but offers no new details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Stake TRX for energy or bandwidth (Stake 2.0)' – a specific verb and resource. It distinguishes from siblings like unfreeze_balance and transfer_trx by naming the staking action and the two resource types, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (staking to obtain energy or bandwidth) and names the resource types, but it does not explicitly mention when to use this tool versus alternatives like delegate_resource or unfreeze_balance. There is no 'when not to use' guidance, so the usage 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.
get_accountBGet TRON account balance and details including TRX balance, bandwidth, energy, frozen resources, and account type
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON base58 address (starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=true, implying a mutating, destructive operation. The description's leading verb 'Get' and its reference to reading balance and details directly contradicts these annotations, making the safety profile confusing and potentially dangerous for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, and lists the key return categories without unnecessary words. It is appropriately sized for a simple lookup tool and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description does not clarify the return format or structure. The contradictory annotations (destructiveHint=true) leave the tool's safety context ambiguous, and given the many sibling tools, the description fails to position this tool clearly, resulting in an incomplete contextual picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single 'address' parameter with type and format (base58 address starting with T), giving a schema coverage of 100%. The tool description adds no additional parameter semantics, so the schema carries the explanatory burden and 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.
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 'TRON account', then enumerates the specific details returned (TRX balance, bandwidth, energy, frozen resources, and account type). This clearly distinguishes the tool from more specialized siblings like get_account_resources or get_account_permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the many sibling tools. It does not mention that get_account is the general-purpose balance/details tool, nor does it direct users to specific siblings for resource-only or permission-only queries, so the agent receives no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_permissionsBGet the permission structure of a TRON account including owner, active, and witness permissions with multi-sig keys and thresholds
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON base58 address (starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false and destructiveHint=true, which directly contradict the description's read-only 'Get' operation. This is a serious inconsistency and the description does not clarify or compensate for the conflicting behavioral signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 tool's purpose and key output elements, appropriate for a simple one-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the description names the expected response contents, the conflicting annotations (destructiveHint=true, readOnlyHint=false) make the tool's behavior unclear and untrustworthy. With no output schema and no usage context, the description is not complete enough for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter 'address' is described as a TRON base58 address starting with T. The tool description adds no further parameter semantics beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource: the permission structure of a TRON account, including owner, active, and witness permissions with multi-sig keys and thresholds. This clearly distinguishes it from sibling tools like get_account and analyze_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as get_account or analyze_account. The description gives no context on prerequisites, scenarios, or exclusions, leaving usage largely implied by the tool name and generic 'get' semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_resourcesBGet energy and bandwidth usage and limits for a TRON account
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON base58 address (starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations state readOnlyHint=false and destructiveHint=true, while the description says 'Get', implying a read-only operation. This is a direct contradiction. No additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is front-loaded with the verb and object, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple getter, the description lacks output format details (e.g., units for energy/bandwidth, limits structure). With contradictory annotations and no output schema, it leaves the agent guessing about side effects and return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single 'address' parameter with its description. The tool description adds no extra meaning beyond the schema's field details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and clearly identifies the resource (energy and bandwidth usage and limits) and target (TRON account). This distinguishes it from sibling tools like get_account or get_delegated_resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_account or get_delegated_resources. It simply states what it does without any contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bandwidth_pricesBGet current and historical bandwidth prices on the TRON network
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: the description says 'Get' implying a read-only operation, but annotations set readOnlyHint=false and destructiveHint=true. No additional behavioral context is provided, making the tool's safety profile confusing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the verb and resource. Every word earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema getter, the description is nearly complete, covering current and historical scope. However, it does not mention return format or historical range limits, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is 100% covered. The description adds no parameter details, but none are needed. Baseline 4 applies because there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'bandwidth prices on the TRON network' and distinguishes from sibling 'get_energy_prices' by naming bandwidth. It also specifies scope: current and historical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_energy_prices. It states only what the tool does, with no examples, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_blockAGet a TRON block by number or latest. Use include_transactions to get transaction details with decoded contract data (sender, receiver, amounts) and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max transactions to return when include_transactions is true (default: 50) | |
| offset | No | Skip first N transactions (default: 0, for pagination) | |
| block_number | No | Block number (omit for latest) | |
| transaction_type | No | Filter transactions by type (e.g., 'TransferContract', 'TriggerSmartContract') | |
| include_transactions | No | Include decoded transaction details with contract data — sender, receiver, amounts (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, which directly contradicts the read-only operation implied by 'Get a TRON block'. The description does not address this inconsistency or add any behavioral context beyond what is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose and followed by a key usage hint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description should give more detail about what the agent can expect in the response. It covers transaction details but not the block's own structure or default behaviors. The annotation contradiction also adds confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well-documented. The description adds value by linking include_transactions to decoded data and pagination, and by clarifying that block_number can be omitted for the latest block.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a TRON block by number or latest, using a specific verb and resource. It distinguishes itself from sibling tools like get_transaction by focusing on block retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using include_transactions to obtain decoded transaction details and pagination. However, it does not explicitly mention when to use this tool over alternatives like get_transaction, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chain_parametersCGet TRON network node info and current energy/bandwidth prices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description contradicts annotations: it describes a read-only 'Get info/prices' call, but annotations include destructiveHint=true and readOnlyHint=false. This is an Annotation Contradiction. The description also fails to disclose any actual behavioral traits such as whether prices are cached or how node info 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that leads with the verb 'Get'. It is appropriately concise with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and contradictory annotations, the description is not complete enough. It does not state what fields or structure the response will have, nor does it clarify the apparent conflict between a read-only description and destructive annotations. The one-liner covers the basic topic but leaves important operational context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds some meaning about the output scope (node info, energy/bandwidth prices), but there is no parameter semantics burden to carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets TRON network node info and current energy/bandwidth prices. It is a specific verb+resource, but it does not distinguish this tool from sibling tools like get_energy_prices, get_bandwidth_prices, or get_network, so it misses the differentiation needed 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description does not mention exclusions, alternatives, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contract_abiBGet the ABI of a smart contract on TRON. Automatically resolves proxy contracts (ERC-1967). Note: many TRON contracts are deployed without on-chain ABI — if empty, check TronScan for verified source code.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_address | Yes | Smart contract address (base58, starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true and readOnlyHint: false, which directly contradict the description's 'Get' action that is clearly non-destructive and read-only. This is a severe annotation contradiction, and per the rubric, transparency must be scored 1 when the description contradicts annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes a critical caveat in the second sentence without redundancy. Every word earns its place, making it both concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description covers the essential behavior (proxy resolution) and a key real-world pitfall (empty ABIs requiring TronScan). However, it does not describe the return format or structure of the ABI, which would be useful given no output schema, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole parameter (contract_address) is already described with base58 format in the schema. The tool description adds no additional parameter meaning or usage details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource 'ABI of a smart contract on TRON', making the tool's purpose immediately obvious. It also adds distinct behavior (proxy resolution) and a practical caveat about TRON contracts lacking on-chain ABIs, distinguishing it from sibling tools like decode_abi_output or list_contract_methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a follow-up action (check TronScan if ABI is empty) but does not explain when to use this tool versus alternatives such as decode_abi_output or list_contract_methods. There is no explicit guidance on selecting this tool over siblings, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contract_eventsAGet decoded events emitted by a smart contract via TronGrid REST API. Returns a compact summary per event. Use a small limit and paginate with fingerprint to control response size
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1-200, default 10). Start small to avoid large responses; use fingerprint to paginate for more | |
| event_name | No | Filter by specific event name (e.g. Transfer, Approval) | |
| fingerprint | No | Pagination cursor from previous response meta.fingerprint — pass to fetch the next page | |
| max_timestamp | No | Maximum block timestamp in milliseconds | |
| min_timestamp | No | Minimum block timestamp in milliseconds | |
| only_confirmed | No | Only return confirmed transactions | |
| contract_address | Yes | TRON smart contract base58 address (starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims this is a read-only operation ('Get decoded events'), but the annotations state readOnlyHint: false and destructiveHint: true. This is a direct contradiction. The description provides no additional behavioral context, so it fails to clarify the tool's side effects, permissions, or impact, resulting in a severe transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each serving a distinct purpose: stating what the tool does, describing the output format, and providing a usage tip. It is front-loaded with the primary action and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a comprehensive schema, the tool lacks an output schema, and the description does not explain the shape of the 'compact summary.' More critically, the contradiction with annotations leaves the tool's actual behavior ambiguous. The description is adequate for a simple read operation but falls short when considering the suspicious annotation profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds no new parameter-level semantics beyond what the schema already provides. The advice on limit and fingerprint is redundant with the schema's parameter descriptions. No value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get decoded events emitted by a smart contract via TronGrid REST API.' It uses a specific verb and resource, and distinguishes itself from sibling tools like get_transaction_history or get_trc20_transfers by focusing on decoded contract events. The mention of 'compact summary' further clarifies the output nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 decoded contract events) and gives operational guidance: 'Use a small limit and paginate with fingerprint to control response size.' However, it does not explicitly mention alternatives or when not to use this tool, so it lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_delegatable_amountBGet the maximum amount of energy or bandwidth an account can still delegate
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON base58 address (starts with T) | |
| resource | Yes | Resource type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states a read-only 'Get' operation, but annotations declare readOnlyHint=false and destructiveHint=true. This is a direct contradiction, so the description misleads about the tool's behavior. No additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description doesn't state the return format, units, or calculation details. The annotation contradiction further undermines contextual clarity, making it insufficient for an agent to fully understand consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters (address and resource) with descriptions. The description adds the semantic connection that the resource is energy or bandwidth, but does not add format or syntax details, so baseline 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb 'Get' and a resource 'maximum amount of energy or bandwidth an account can still delegate', differentiating it from siblings like delegate_resource (which performs delegation) and get_delegated_resources (which lists existing delegations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'can still delegate' implies this is for checking remaining delegatable capacity before delegating, which is clear context. However, it does not explicitly name alternatives or state when not to use it, so a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_delegated_resourcesBGet resources delegated to and from an account (Stake 2.0 delegation info)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON base58 address (starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'Get' resources, which implies a read-only operation, but the annotations declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false. This is a direct contradiction, and the description fails to disclose any behavioral traits that would reconcile this conflict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's purpose without any fluff. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and misleading annotations, the description is not complete enough. It fails to clarify the seemingly destructive nature suggested by annotations or describe the return structure of delegation info, leaving significant gaps for an agent to interpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'address' as a TRON base58 address, providing 100% schema coverage. The description adds no additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets resources delegated to and from an account, specifically Stake 2.0 delegation info. It uses a specific verb (Get) and resource (delegated resources), and distinguishes itself from sibling tools like delegate_resource and undelegate_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool (to retrieve delegation info), but it does not explicitly mention alternatives or when not to use it. Since the purpose is obvious, it earns a 3 for implied usage but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_energy_pricesAGet current and historical energy prices on the TRON network
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Get' which implies a read-only operation, but annotations declare destructiveHint=true and readOnlyHint=false. This directly contradicts the description, creating serious confusion about the tool's safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-formed sentence that immediately conveys the tool's purpose without any redundant text. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description is somewhat thin, but it conveys the core functionality. However, it omits details about price units, historical range, and any caveats, and the annotation contradiction makes the overall context incomplete and confusing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not add parameter-level detail. The schema coverage is 100% (empty schema), and the description provides no misleading parameter information, earning the baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get'), the resource ('energy prices'), and the network ('TRON'), making it distinct from sibling tools like get_bandwidth_prices. It is an unambiguous statement of 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving current and historical energy prices, but does not explicitly state when to use it versus alternatives like get_bandwidth_prices or estimate_energy. No exclusions or alternative tool suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_networkAGet current MCP server connection info: network name, node address, and latest block
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool 'gets' information, implying a read-only operation, but the annotations declare destructiveHint=true and readOnlyHint=false. This is a direct contradiction, so the description fails to provide trustworthy behavioral context. Annotation contradiction flag set to true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and lists the specific return values. Every word contributes to understanding the tool, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 adequately lists the return fields. However, it does not address the behavioral implications of the contradictory annotations (destructiveHint, readOnlyHint=false), leaving the agent uncertain about side effects. This gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 context about what the tool returns, which is useful given no output schema, but there are no parameter semantics to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 as 'current MCP server connection info', listing the exact fields returned (network name, node address, latest block). This clearly distinguishes it from sibling tools like get_block or get_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description—use when you need connection info—but there is no explicit guidance on when to use this tool versus alternatives (e.g., get_block for block details). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pending_by_addressBGet pending transactions for a specific address from the mempool
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON address (base58, starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Get pending transactions'), but the annotations declare readOnlyHint=false and destructiveHint=true, which contradicts the nature of a getter. The description does not address this inconsistency or disclose any side effects. This is a serious contradiction, warranting a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded with the action and resource, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description lacks essential context such as what the response contains (full transactions? hashes?), whether it polls the mempool, and whether it is safe. The contradictory annotations further increase the need for clarifying text, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the only parameter 'address' is described as 'TRON address (base58, starts with T)'. The description adds no extra semantic information beyond restating 'specific address'. Per the baseline rule, this earns a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Get pending transactions for a specific address from the mempool.' It includes a specific verb ('Get'), a defined resource (pending transactions), and a scope (specific address), which differentiates it from sibling tools like get_pending_transactions (all mempool) and is_transaction_pending (by hash).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool versus get_pending_transactions, is_transaction_pending, or other address-related tools. It implies address-specific use but offers no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pending_transactionsBList pending transaction IDs and pool size from the mempool
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max transaction IDs to return (default: 10) | |
| offset | No | Skip first N transaction IDs (default: 0, for pagination) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'List' which indicates a read-only operation, but the annotations declare readOnlyHint=false and destructiveHint=true. This is a direct contradiction. The description does not add any behavioral context beyond the annotations, and the annotation conflict makes the tool's behavior unclear and potentially misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose. It contains zero filler and is appropriately sized for a simple list operation. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description lacks important context. The contradictory annotations undermine trust, and the return format (e.g., how pool size and IDs are structured) is not described. Since there is no output schema, the description should clarify what the tool returns, but it only mentions 'pool size' fleetingly. The description is incomplete for an agent to safely select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters (limit and offset) with clear descriptions. The tool description adds no extra meaning beyond what the schema already states. The schema does the heavy lifting, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('pending transaction IDs and pool size from the mempool'), clearly distinguishing it from siblings like get_pending_by_address or is_transaction_pending. It tells the agent exactly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to fetch pending transactions from the mempool, but it does not explicitly mention when to use this tool versus alternatives such as get_pending_by_address or is_transaction_pending. No exclusions or alternative comparisons are provided, so the context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_proposalBGet full details of a governance proposal by ID, including the complete list of approval addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes | Proposal ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations. It states 'Get full details' implying a read-only operation, but annotations include destructiveHint: true and readOnlyHint: false. The description provides no disclosure of side effects, permissions, or required authentication, making it misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the key action and includes an informative detail about the return value. It is concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return values, which it does partially by mentioning approval addresses. However, it fails to address the annotations indicating destructive behavior, leaving critical context unexplained. The tool appears simple, but the contradiction makes it incomplete for an agent to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with proposal_id described as 'Proposal ID'. The description merely references 'by ID' without adding additional meaning about format, source, or range. Since the schema fully covers the parameter, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 full details of a governance proposal by ID, specifically including the complete list of approval addresses. This verb+resource phrasing distinguishes it from siblings like list_proposals, which lists proposals without full detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific proposal ID is known and detailed information is needed, but it does not explicitly mention when not to use this tool or provide alternatives. There is no direct comparative guidance with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_token_priceAGet the current USD price of TRX or a TRC20 token. Uses CoinGecko with caching.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token to price: 'TRX' or a TRC20 contract address (e.g., TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t for USDT) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, while the description says 'Get the current USD price'—a read-only operation with no destructive or mutating behavior mentioned. This is a direct contradiction, so the description fails to align with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and the second sentence provides useful context about the data source. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple price lookup with one self-documented parameter, the description is functionally complete. It could optionally mention that caching may delay price freshness, but this is a minor omission. The annotation contradiction slightly undermines overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is detailed (includes an example address). The tool 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('current USD price of TRX or a TRC20 token'), clearly distinguishing it from sibling tools like get_account or get_trc20_balance. It is unambiguous and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (when a current USD price for TRX or TRC20 is needed) and provides no exclusions. It does not explicitly name alternatives, but no other sibling tool serves this purpose, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transactionBGet transaction details by transaction ID
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | Transaction hash / txid (64-char hex string) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description suggests a read-only operation ('Get transaction details'), but annotations indicate destructiveHint=true and readOnlyHint=false. This is a direct contradiction, fundamentally misleading the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose. No unnecessary words or sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The simple parameter count and schema coverage are sufficient for a basic get tool, but the contradiction with annotations makes the description inadequate and potentially dangerous. No output schema is provided, and the description does not clarify return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond the schema's description of transaction_id as a hash/txid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves transaction details using a transaction ID, using a specific verb and resource. It distinguishes from sibling tools like get_transaction_history and is_transaction_pending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies appropriate usage context: when you have a transaction ID and need details. It does not explicitly exclude alternatives or mention when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transaction_historyBGet transaction history for a TRON address via TronGrid REST API. Returns a compact summary per transaction. Use a small limit and paginate with fingerprint to control response size
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1-200, default 10). Start small to avoid large responses; use fingerprint to paginate for more | |
| address | Yes | TRON base58 address (starts with T) | |
| only_to | No | Only show incoming transactions | |
| only_from | No | Only show outgoing transactions | |
| fingerprint | No | Pagination cursor from previous response meta.fingerprint — pass to fetch the next page | |
| max_timestamp | No | Maximum block timestamp in milliseconds | |
| min_timestamp | No | Minimum block timestamp in milliseconds | |
| only_confirmed | No | Only return confirmed transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Get transaction history' and 'Returns', implying a read-only operation, while annotations declare destructiveHint=true and readOnlyHint=false. This is a direct contradiction, and the description provides no additional behavioral context to resolve it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the tool's purpose. The second sentence offers a relevant operational tip without unnecessary words. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and contradictory annotations, this description is too thin. It does not address the filtering parameters (only_to/only_from, min/max_timestamp, only_confirmed) or clarify the destructiveHint annotation. The return format is only vaguely described as 'compact summary'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description's mention of 'small limit' and 'fingerprint' adds no new meaning beyond the schema's detailed parameter descriptions. No parameter semantics beyond the schema are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Get), the resource (transaction history for a TRON address), and the return format (compact summary). It is distinguishably scoped for address-level history, setting it apart from siblings like get_transaction or get_trc20_transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool (for a TRON address) and provides a practical usage tip about using a small limit and paginating with fingerprint. However, it does not explicitly name alternatives or exclusions, such as using get_trc20_transfers for TRC20-specific transfers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trc20_allowanceBQuery how many tokens a spender is approved to transfer on behalf of the owner. Flags unlimited approvals as high risk.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | Token owner address (base58) | |
| spender | Yes | Approved spender address (base58) | |
| contract_address | Yes | TRC20 token contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description calls the operation 'Query' (read-only), but annotations set readOnlyHint=false and destructiveHint=true. This is a direct contradiction; the description claims a safe read while annotations warn of destructive behavior. Per rules, any contradiction forces a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover the primary query behavior and the high-risk flag without redundancy or unnecessary details. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and the unlimited approval flag, but with no output schema it fails to specify the return format (e.g., exact number, units). The contradiction between the read-only description and destructive annotations further undermines completeness, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all three required parameters (owner, spender, contract_address) with descriptions. The tool description adds no extra meaning beyond what 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Query' and clearly identifies the resource being read: 'how many tokens a spender is approved to transfer on behalf of the owner.' It distinguishes itself from sibling tools like get_trc20_balance (balance) and transfer_trc20 (transfer) by focusing on allowance/approval amounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when checking spending allowances but doesn't explicitly state when to use this tool over alternatives such as revoke_approval or transfer_trc20. No exclusions or conditional guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trc20_balanceCGet TRC20 token balance for an account
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON base58 address | |
| contract_address | Yes | TRC20 contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint: true and readOnlyHint: false, which directly contradicts the description's claim that this is a getter. The description provides no disambiguation or disclosure of any side effects, creating a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It effectively communicates the core function in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with fully documented parameters, the contradictory annotations (destructiveHint: true for a balance getter) create a critical gap in understanding. The description does not address or resolve this, leaving the agent uncertain about safety and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters (address and contract_address) with descriptions. The description adds no additional semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a TRC20 token balance for an account, using a specific verb and resource. It does not explicitly distinguish from sibling tools like get_trc20_allowance or get_account, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives or any prerequisites. It is a bare statement of functionality, so the agent receives no guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trc20_token_infoBGet TRC20 token metadata (name, symbol, decimals, total supply)
| Name | Required | Description | Default |
|---|---|---|---|
| contract_address | Yes | TRC20 contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This is an annotation contradiction. The description states 'Get TRC20 token metadata,' which implies a read-only, non-destructive operation, but annotations declare readOnlyHint=false and destructiveHint=true. The description does not address this contradiction or clarify side effects, leaving the agent with conflicting signals about whether invoking this tool may alter state or destroy data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action ('Get') and resource, with output fields in parentheses. It contains no unnecessary words and conveys maximum relevant information in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description lists the returned metadata fields, which is helpful. However, the contradictory annotations (destructiveHint=true) are not resolved by the description, and there is no mention of safety or side effects. Given that the description should compensate for missing output schema and conflicting annotations, it falls short of full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the only parameter 'contract_address' described as 'TRC20 contract address'. The description does not add additional semantic meaning for the parameter beyond what the schema provides. The baseline of 3 applies because the schema fully documents the parameter, and the description's mention of metadata fields does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get TRC20 token metadata (name, symbol, decimals, total supply)' clearly states a specific verb ('Get') and resource ('TRC20 token metadata'), listing the exact fields returned. It distinguishes from sibling tools like get_trc20_balance and get_trc20_allowance by focusing on metadata rather than balances or allowances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any exclusions. For example, it does not mention that for TRC20 balances one should use get_trc20_balance or for allowances get_trc20_allowance. Usage context is implied only by the tool name and description, not explicitly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trc20_transfersBGet TRC20 token transfer history for a TRON address via TronGrid REST API. Returns a compact summary per transfer with token info. Use a small limit and paginate with fingerprint to control response size
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1-200, default 10). Start small to avoid large responses; use fingerprint to paginate for more | |
| address | Yes | TRON base58 address (starts with T) | |
| only_to | No | Only show incoming transfers | |
| only_from | No | Only show outgoing transfers | |
| fingerprint | No | Pagination cursor from previous response meta.fingerprint — pass to fetch the next page | |
| max_timestamp | No | Maximum block timestamp in milliseconds | |
| min_timestamp | No | Minimum block timestamp in milliseconds | |
| only_confirmed | No | Only return confirmed transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description presents a read-only lookup ('Get TRC20 token transfer history'), but the annotations indicate readOnlyHint=false and destructiveHint=true, which directly contradict the described behavior. This is a serious inconsistency with no explanatory context added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with front-loaded purpose, followed by practical pagination guidance. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and a rich schema, the description covers the essential operational concern (response size control) and notes the return format ('compact summary per transfer with token info'). It does not explain every parameter, but the schema fills that gap, and no output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters. The description adds only general advice about limit and fingerprint, which largely echoes the schema. No additional semantic value beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('TRC20 token transfer history for a TRON address'), naming the underlying API (TronGrid REST). This distinguishes it from sibling tools like get_transaction_history or get_trc20_balance which cover different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives operational guidance on controlling response size ('Use a small limit and paginate with fingerprint'), but does not explicitly compare to alternatives or state when not to use. The TRC20 qualifier implies when it should be used, but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
is_transaction_pendingBCheck if a specific transaction is still in the pending pool (mempool)
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | Transaction hash / txid (64-char hex string) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a non-destructive read-only check ('Check if...'), but the annotations state readOnlyHint=false and destructiveHint=true, directly contradicting the description. This is a serious inconsistency that could mislead an agent about side effects. No additional behavioral context (e.g., return format, error cases) is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose without superfluous words. It is concise and well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and the description conveys the core purpose, the absence of an output schema means the description should explicitly mention the return value (e.g., boolean) or error behavior. The annotation contradiction further undermines completeness, as it would make an agent uncertain about side effects. Overall, it is minimally adequate but lacks important contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameter descriptions, including 'Transaction hash / txid (64-char hex string)', so the description adds no extra semantic value beyond what is already in the schema. The baseline of 3 is appropriate because the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check'), the target resource ('a specific transaction'), and the specific scope ('still in the pending pool (mempool)'). This distinguishes it from siblings like get_transaction or get_pending_transactions, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a transaction ID and want to check pending status) but provides no explicit when-to-use vs alternatives, exclusions, or prerequisites. It does not mention sibling tools like get_transaction for confirmed status, so guidance is limited to implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_contract_methodsBGet a human-readable summary of a smart contract's methods with signatures, inputs, outputs, and mutability. Auto-resolves proxy contracts.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_address | Yes | Smart contract address (base58, starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Get a human-readable summary'), but the annotations assert destructiveHint=true, readOnlyHint=false, and idempotentHint=false, which directly contradicts the description. No additional behavioral details are provided, making the tool's actual behavior misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences, with the main purpose front-loaded and the proxy behavior adding useful context. Every phrase earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core output content and highlights proxy auto-resolution, but it lacks an explicit mention of the return format or error cases, especially given no output schema exists. The annotation contradiction further undermines the completeness of the behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, contract_address, already has a clear schema description ('Smart contract address (base58, starts with T)'). The tool description adds no additional semantic detail about the parameter itself, so the baseline score of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('smart contract's methods'), and elaborates on what the summary includes: signatures, inputs, outputs, and mutability. This clearly distinguishes it from siblings like get_contract_abi and gets the core purpose across in one sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention of 'Auto-resolves proxy contracts' provides a hint about when this tool is useful, but there is no explicit guidance on when to use it instead of alternatives. It does not name any sibling tools or state exclusions, leaving usage mostly implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_proposalsAList governance proposals on the TRON network with pagination support. Returns a compact summary per proposal (use get_proposal for full details including approval addresses). Newest first by default.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max proposals to return (default: 5) | |
| order | No | Sort order by proposal ID: 'desc' (default, newest first) or 'asc' (oldest first) | |
| offset | No | Skip first N proposals (default: 0, for pagination) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false and destructiveHint=true, but the description describes a read-only list operation ('List', 'Returns a compact summary'). This directly contradicts the annotations, which is a serious inconsistency that could mislead the agent. Per the rubric, score is 1 and annotation_contradiction is flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and return type, with no redundant information. Every phrase earns its place, including the pointer to get_proposal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list tool with optional parameters, and it mentions what it returns. However, the contradictory annotations create a confusing safety profile (destructiveHint=true for a read operation), and the description does not explicitly clarify that the operation is read-only, leaving the agent with conflicting signals. Thus, despite the description's own clarity, the overall context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for all three parameters (limit, order, offset) with clear descriptions. The description adds minimal extra value, like mentioning 'pagination support' and 'newest first by default', but these are already implied by the schema. Baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists governance proposals on the TRON network with pagination, using a specific verb and resource. It distinguishes itself from the sibling tool get_proposal by noting that this returns a compact summary while get_proposal provides full details including approval addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly points to get_proposal as the alternative when full details are needed, providing clear guidance on when to use this tool vs. the sibling. This helps the agent choose the right tool for the desired level of detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_witnessesBList super representatives (witnesses) on the TRON network with pagination support.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max witnesses to return (default: 5) | |
| offset | No | Skip first N witnesses (default: 0, for pagination) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'List', implying a read-only operation, while annotations set destructiveHint=true and readOnlyHint=false, a direct contradiction. No other behavioral details (e.g., side effects, permissions, return format) are provided, so transparency is critically lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no wasted words. It is appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the contradiction between the read-only description and destructive annotation creates significant confusion. There is no output schema, and the description does not clarify expected return values or default behavior, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents limit and offset with clear descriptions, covering 100% of parameters. The description adds the term 'pagination support' which maps to these parameters but provides no additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists super representatives (witnesses) on the TRON network and explicitly mentions pagination support. This is a specific verb+resource combination that distinguishes it from account, block, and transaction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for enumerating witnesses with pagination, which provides clear context. However, it does not explicitly contrast this with other list tools like list_proposals nor provide when-not-to-use guidance, so usage guidance is 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.
revoke_approvalABuild unsigned transaction to revoke a TRC20 token approval (sets allowance to 0)
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | Token owner address (base58) — the account revoking the approval | |
| spender | Yes | Spender address to revoke | |
| fee_limit | No | Fee limit in TRX (default 15, max 15000) | |
| permission_id | No | Permission ID for multi-sig transactions | |
| contract_address | Yes | TRC20 token contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive and non-read-only behavior. The description adds the crucial detail that the tool builds an unsigned transaction, implying it does not execute the change itself, and clarifies the allowance is set to zero. This goes beyond what annotations provide without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, and it avoids redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a rich schema and annotations, the description adequately covers the tool's function and effect. It does not detail return values, but the phrase 'Build unsigned transaction' implies the output. It is complete enough 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already well-documented (e.g., owner, spender, fee_limit). The description does not add additional parameter-specific meaning, but the schema fully carries the burden, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: building an unsigned transaction to revoke a TRC20 token approval. It specifies the effect (sets allowance to 0) and uses a specific verb ('build') with a distinct resource, differentiating it from sibling tools like transfer_trc20 or get_trc20_allowance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (revoking token approvals) but does not explicitly state when to prefer this over alternatives or mention any prerequisites. It lacks clear when-to-use or when-not-to-use guidance, though the context of 'building an unsigned transaction' is implicitly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transfer_trc20ACreate an unsigned TRC20 token transfer transaction. Returns transaction hex for signing.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient address (base58, starts with T) | |
| from | Yes | Sender address (base58, starts with T) | |
| amount | Yes | Amount in token units (human-readable, e.g., '100.5') | |
| fee_limit | No | Fee limit in TRX, range 0-15000 (default: 100) | |
| permission_id | No | Permission ID for multi-sig transactions | |
| contract_address | Yes | TRC20 contract address (base58, starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it explicitly states the transaction is unsigned and that the tool returns a hex for signing, implying that no state change occurs until external signing and broadcasting. This is valuable nuance given destructiveHint=true, as it clarifies that the tool itself does not execute the transfer. However, it does not elaborate on the signing/broadcasting process or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two short sentences that directly state the tool's purpose and output. No filler or redundant information is present, making it easy for an agent to process quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters with a fully described schema and annotations, the description adequately explains the core function and output. It is missing guidance on the subsequent signing/broadcast step and how the optional parameters (fee_limit, permission_id) affect the transaction, but these are documented in the schema. Overall, it is sufficiently complete for its intended use, though a brief note on the resulting hex's purpose would enhance clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter clearly explained (e.g., base58 addresses, human-readable amount, fee limit range). The description does not need to add parameter-specific details, and it does not. It provides a general overview of the transaction type, which aligns with the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as creating an unsigned TRC20 token transfer transaction, using the specific verb 'Create' and the resource 'unsigned TRC20 token transfer transaction'. It distinguishes itself from sibling tools like transfer_trx (native TRX) and trigger_contract (generic contract calls) by specifying the exact token standard and output. The additional detail about returning a transaction hex for signing removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used for TRC20 token transfers and that the returned hex is for signing, but it does not explicitly state when to use it over alternatives (e.g., transfer_trx for native TRX) or when not to use it. There is no mention of prerequisites or complementary tools for signing/broadcasting, so the usage context is only partially conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transfer_trxACreate an unsigned TRX transfer transaction. Returns transaction hex for signing.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient address (base58, starts with T) | |
| from | Yes | Sender address (base58, starts with T) | |
| memo | No | Optional memo to attach to the transaction | |
| amount | Yes | Amount in TRX (e.g., '100.5') | |
| permission_id | No | Permission ID for multi-sig transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate non-read-only and destructive hints, the description adds valuable context by clarifying the transaction is unsigned and meant for signing, meaning it does not broadcast immediately. This behavior is not fully captured by the annotations alone, so the description enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the first sentence front-loading the core purpose and the second providing return information. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the schema fully documents parameters and annotations cover safety profile, the description completes the picture by specifying the return format (transaction hex for signing). No output schema exists, but the description adequately covers what the tool returns and what to do with it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for all five parameters, so the description does not need to add parameter-specific details. The baseline of 3 applies because the description adds no extra semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Create' and resource 'unsigned TRX transfer transaction', distinguishing it from sibling tools like transfer_trc20 (which handles TRC20 tokens). It also states the return type (transaction hex), adding further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the tool's purpose for creating unsigned TRX transfers, which implies its usage context. However, it does not explicitly mention when not to use it or name alternatives like transfer_trc20, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trigger_constant_contractBCall a read-only (view/pure) smart contract method. No transaction created, no fees. Returns decoded result. Provide either method+params OR data (pre-packed calldata).
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Pre-packed ABI calldata as hex (0x prefix optional). When provided, method and params are ignored. | |
| from | No | Caller address (base58, starts with T; optional — defaults to zero address) | |
| method | No | Method signature (e.g., 'totalSupply()', 'balanceOf(address)'). Required unless data is provided. | |
| params | No | Method parameters as JSON array. Plain values: ["TJD...", "1000"] (types inferred from method signature). Typed objects also accepted: [{"address": "TJD..."}, {"uint256": "1000"}] | |
| token_id | No | TRC10 token ID for simulating TRC10 token transfers | |
| call_value | No | Amount in SUN to send with call (default: 0, 1 TRX = 1000000 SUN). Required for simulating payable functions. | |
| token_value | No | TRC10 token amount to send with call (default: 0) | |
| contract_address | Yes | Smart contract address (base58, starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is read-only ('view/pure', no transaction, no fees), but annotations declare readOnlyHint=false and destructiveHint=true, directly contradicting the description. This is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose ('Call a read-only smart contract method') and packs useful information, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a clear purpose, the description is incomplete due to the contradiction with annotations. It doesn't address the actual destructive/write nature implied by annotations, making the overall context misleading and incomplete for an agent relying on it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents all 8 parameters with 100% coverage, so the description adds little beyond the 'method+params OR data' relationship, which is already implied by the data parameter's description. The description does not add significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (call), resource (smart contract method), and scope (read-only view/pure), distinguishing it from the sibling write tool trigger_contract. The phrase 'No transaction created, no fees' reinforces its read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells users to provide either method+params OR data, and notes that it's a read-only call with no fees. It implies when to use this tool compared to a write-like contract call, though it doesn't explicitly name an alternative like trigger_contract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trigger_contractACall a smart contract method. Returns unsigned transaction hex for signing. Provide either method+params OR data (pre-packed calldata).
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Pre-packed ABI calldata as hex (0x prefix optional). When provided, method and params are ignored. | |
| from | Yes | Caller address (base58, starts with T) | |
| method | No | Method signature (e.g., 'transfer(address,uint256)'). Required unless data is provided. | |
| params | No | Method parameters as JSON array. Plain values: ["TJD...", "1000"] (types inferred from method signature). Typed objects also accepted: [{"address": "TJD..."}, {"uint256": "1000"}] | |
| fee_limit | No | Fee limit in whole TRX (integer), range 0-15000 (default: 100) | |
| call_value | No | Amount to send with call in SUN (default: 0) | |
| permission_id | No | Permission ID for multi-sig transactions | |
| contract_address | Yes | Smart contract address (base58, starts with T) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as destructive and non-read-only. The description adds the crucial behavior that it returns an unsigned transaction for signing, implying no broadcast or execution. This complements annotations 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of an output schema, the description should clarify the exact return structure and emphasize that the transaction is not broadcast. It only says 'unsigned transaction hex' which is suggestive but imprecise. It also omits differentiation from trigger_constant_contract, though the annotations partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for all 8 parameters. The description's mention of 'method+params OR data' restates the already-documented mutual exclusivity, adding no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Call a smart contract method' clearly states the action and resource. Adding 'Returns unsigned transaction hex for signing' distinguishes it from read-only calls like trigger_constant_contract, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides input-mode guidance ('Provide either method+params OR data') but gives no context on when to prefer this tool over alternatives such as trigger_constant_contract or transfer_trx. No when-to-use or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
undelegate_resourceAReclaim previously delegated energy or bandwidth (Stake 2.0). Returns unsigned transaction hex for signing.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Address to reclaim from (base58, starts with T) | |
| from | Yes | Delegator address (base58, starts with T) | |
| memo | No | Optional memo to attach to the transaction | |
| amount | Yes | Amount in TRX to undelegate (e.g., '100.5') | |
| resource | Yes | Resource type | |
| permission_id | No | Permission ID for multi-sig transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the write nature is known. The description adds key context by stating the tool returns an unsigned transaction hex for signing, which is not covered by 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the action, scope, and return type without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 the presence of rich annotations and full schema descriptions, the description covers the essential behavioral aspect (returning an unsigned transaction hex) and the domain (Stake 2.0). It does not over-explain details already present in structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is already described with type and purpose. The description adds no extra parameter-specific meaning beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Reclaim') and resource ('delegated energy or bandwidth'), plus the Stake 2.0 context. This distinguishes it from the sibling tool 'delegate_resource' and from legacy 'unfreeze_balance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously delegated' implies when to use this tool, but it does not explicitly mention alternatives or when not to use it. There is no comparative guidance against 'unfreeze_balance' or 'delegate_resource'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unfreeze_balanceAUnstake TRX (Stake 2.0). Returns unsigned transaction hex for signing. Note: unstaked TRX has a 14-day withdrawal period.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Account address (base58, starts with T) | |
| memo | No | Optional memo to attach to the transaction | |
| amount | Yes | Amount in TRX to unstake (e.g., '100.5') | |
| resource | Yes | Resource type | |
| permission_id | No | Permission ID for multi-sig transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses that the tool returns an unsigned transaction hex for signing rather than directly unstaking, and notes the 14-day withdrawal period. These are meaningful behavioral insights not available elsewhere in the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences, front-loaded with the core action. Every sentence adds value: the action, the return format, and the timing consequence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with annotations and full schema coverage, the description covers the core action, the return value (unsigned hex), and an important timing caveat. However, it lacks differentiation from withdraw_expire_unfreeze and undelegate_resource, which could confuse an agent in this tool-dense environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no parameter-specific meaning. It does not explain how the amount, resource, or other parameters affect the operation, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Unstake TRX (Stake 2.0)' which is a specific verb+resource action. It explicitly distinguishes this from freeze_balance (staking) and withdraw_expire_unfreeze (withdrawing after the unfreeze period) by referencing Stake 2.0. The return type (unsigned transaction hex) further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as withdraw_expire_unfreeze or undelegate_resource. The description implies the usage from the verb 'Unstake' but does not provide explicit context or exclusions, leaving the agent to infer from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_addressAValidate a TRON address and convert supported inputs to TRON base58/hex. Accepts base58 (T...), TRON hex (41...), or Ethereum/EVM format (0x...).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | TRON address (base58 T..., hex 41..., or Ethereum 0x...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes the tool as validating and converting addresses, which is inherently a read-only, non-destructive operation. However, the annotations declare destructiveHint: true, implying potential harmful side effects. This creates a direct contradiction between the description and the metadata, as the description gives no indication of destructive behavior and the operation described cannot plausibly be destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and resource, followed by the accepted input formats. Every word earns its place; there is no fluff or redundancy. It is front-loaded and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, so the description should explain both input and expected output behavior. It clearly covers input formats, but does not specify what the tool returns (e.g., a boolean validity indication, the converted base58 address, or an error). This gap leaves the agent uncertain about the return value, making the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of the parameter, describing the address field with the same formats (base58 T..., hex 41..., or Ethereum 0x...). The description adds no additional semantic information beyond what the schema states, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validating a TRON address and converting supported inputs to base58/hex. It uses specific verbs ('validate', 'convert') and the resource (TRON address), and lists accepted input formats. This distinguishes it from sibling tools like analyze_account or get_account, which focus on other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 you need to validate or convert a TRON address in any of the supported formats. It provides clear context about the accepted input types, but does not explicitly mention alternatives or when not to use it. Since it is a standalone utility with no closely related siblings, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vote_witnessAVote for super representatives. Returns unsigned transaction hex for signing. Requires staked TRX (1 TRX staked = 1 vote).
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Voter address (base58, starts with T) | |
| memo | No | Optional memo to attach to the transaction | |
| votes | Yes | Map of witness address to vote count, e.g., {"TKSXDA...": 100, "TLyqz...": 50} | |
| permission_id | No | Permission ID for multi-sig transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond the annotations: it returns an unsigned transaction hex for signing, meaning it does not broadcast or modify state directly. This clarifies the actual side-effect profile and is consistent with the non-read-only annotation. It also mentions the staking requirement, which is a precondition, but does not elaborate on error cases or multi-sig behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with three clear parts: action, return type, and requirement. It is front-loaded with the primary purpose and contains no filler words, making it both concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, 4 parameters (including a nested object), and moderate complexity. The description explains the return type (unsigned transaction hex) and the core prerequisite (staked TRX), which is essential. It could have been more explicit about the exact output format or that the transaction must be signed externally, but it covers the main usage context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 4 parameters with descriptions and an example for the votes map. The description adds the semantic constraint '1 TRX staked = 1 vote', which directly informs how the vote counts in the votes parameter should be interpreted. This goes beyond the schema, which simply defines the map structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Vote for super representatives') and the specific resource (super representatives/witnesses). It also distinguishes from siblings like list_witnesses and freeze_balance by mentioning the return of an unsigned transaction for signing, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the key prerequisite: 'Requires staked TRX (1 TRX staked = 1 vote)'. This gives clear context on when to use the tool (i.e., after staking) and implicitly contrasts with alternatives like freeze_balance or delegate_resource. However, it does not explicitly name alternatives or state 'use this when you want to vote', leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
withdraw_expire_unfreezeAWithdraw TRX that has completed the 14-day unstaking period (Stake 2.0). Returns unsigned transaction hex for signing.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Account address (base58, starts with T) | |
| memo | No | Optional memo to attach to the transaction | |
| permission_id | No | Permission ID for multi-sig transactions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds valuable context by noting it returns an unsigned transaction hex for signing, which informs the agent that the tool does not execute the withdrawal directly. This goes beyond the annotations, though it could mention edge cases like duplicate withdrawals or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only three parameters, one required, and no output schema, the description is sufficiently complete. It explains the action, the timing constraint (14-day period), and the return format. No critical information is missing 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters already documented in the input schema. The description adds no additional meaning to the parameters, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Withdraw') and resource ('TRX that has completed the 14-day unstaking period'), which distinguishes it from sibling tools like unfreeze_balance or transfer_trx. It also specifies the return type (unsigned transaction hex), making 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: after the 14-day unstaking period completes. This gives clear context for usage. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
