Vote 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 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / from / descriptionPrevious value: -"Voter address"New value: +"Voter address (base58, starts with T)"Input schema / properties / memoAdded value: +{
+ "description": "Optional memo to attach to the transaction",
+ "type": "string"
+}Input schema / properties / permission_idAdded value: +{
+ "description": "Permission ID for multi-sig transactions",
+ "type": "number"
+}Input schema / properties / votes / descriptionPrevious value: -"Map of witness address to vote count"New value: +"Map of witness address to vote count, e.g., {\"TKSXDA...\": 100, \"TLyqz...\": 50}"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.
Add one secure layer between your agents and this server.
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.