powersun-tron-mcp

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

In the absence of annotations, the description carries the full burden and discloses key behavioral traits: broadcasting to the blockchain, verification of permissions after broadcast, and authentication requirement. It could additionally discuss reversibility or failure handling, but the provided details go well beyond minimal disclosure.

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 sentences, each contributing meaningful information: primary action, verification behavior, and usage context. There is no redundancy or fluff, and the most critical information is front-loaded.

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 no output schema and a nested transaction object, the description covers the essential workflow: build, sign, broadcast, and verify. It omits return format and error scenarios, but the additional context signals (siblings, schema) fill enough gaps to make the tool understandable. A slightly lower score would be warranted if the tool had more complex 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 schema already provides 100% parameter descriptions, so the baseline is 3. The description adds value by tying 'signedTransaction' to the output of 'build_permission_transaction', clarifying its origin and expected structure beyond the schema's generic 'from tronWeb.trx.sign()' text.

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 ('Broadcast'), the resource ('signed AccountPermissionUpdate transaction'), and the target ('TRON blockchain'). It also distinguishes itself from the sibling 'broadcast_transaction' by specifying the transaction type and by describing post-broadcast verification, making its unique 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?

Explicitly instructs 'Use this after signing the transaction from build_permission_transaction', providing a clear when-to-use directive and linking to the proper workflow. This effectively differentiates it from the transaction-building sibling and gives actionable sequencing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the transparency burden and does well by disclosing the auto energy delegation step, payment/auth options, and the unauthenticated cost-estimate response. It does not detail every side effect or return value, but the core behavioral traits are covered beyond mere tautology.

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?

Three focused sentences present the action first, then payment modes, then unauthenticated behavior. Every sentence adds useful information, with no redundant or unnecessary wording.

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 moderately complex with a nested txData object and no output schema, and the description covers auth modes and unauthenticated outputs. However, it leaves the authenticated success/response format unstated, which is a notable gap for an agent that needs to interpret the broadcast result.

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 a 100% description coverage for txData with an explanation of the expected object fields, so the description's 'signed transaction data' adds little beyond the schema. This meets the baseline but does not add significant parameter semantics.

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 'Broadcast' and names the resource 'pre-signed TRON transaction', with the added scope 'auto energy delegation'. This clearly distinguishes it from sibling tools like broadcast_signed_permission_tx by specifying the TRON context and delegation behavior.

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 explains when to use the tool (when you have a signed transaction data and need energy delegation) and outlines the authentication modes (API key or x402) as well as the unauthenticated cost-estimate behavior. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of perfect guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the transparency burden. It discloses the unsigned nature, the need for signing and broadcasting, preservation of existing permissions, and authentication requirement. This goes beyond a simple 'build transaction' statement, though it does not cover failure modes or idempotency.

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 deliver the essential purpose, workflow, and a behavioral guarantee. Every sentence earns its place, with no filler or redundant repetition of schema.

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 fully covers the tool's purpose, the build-sign-broadcast workflow, and the return type (unsigned transaction). It omits potential error conditions or effects on existing permissions if re-run, but these are not critical for a transaction builder, so it is nearly 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for poolAddress and includeVote; it focuses on the transaction's purpose rather than parameter-specific 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 it builds an AccountPermissionUpdate transaction granting the PowerSun platform permission to delegate/undelegate resources and optionally vote. This specific verb+resource combination distinguishes it from siblings like broadcast_signed_permission_tx and check_pool_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?

It provides a clear workflow: build unsigned transaction, sign with private key, then broadcast via broadcast_signed_permission_tx. This implies use context and prerequisites, though it does not explicitly name alternatives or when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full behavioral burden. It does disclose key details: creates a market order, filled by available pools, and deducts cost from balance. However, it omits other potentially important behaviors like what happens if no pools are available, whether the order is on-chain, or if the action is reversible. The disclosed information is useful but not comprehensive.

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

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

The description is two sentences: the first states the core function, the second explains the order type and cost implication. Every sentence adds value, and it is front-loaded with the primary action. 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?

Given the tool has no output schema and no annotations, the description provides essential behavioral context (market order, balance deduction) but is incomplete regarding post-execution expectations, such as what the response contains (e.g., order ID, status) or edge cases like insufficient funds. It is adequate for a basic understanding but leaves some 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?

Schema description coverage is 100%, with each parameter having a clear description in the input schema. The tool description adds minimal parameter-specific meaning beyond the schema: it highlights 'target address' and 'deducts cost,' but does not elaborate on txType, txCount, durationMinutes, or resourceType beyond what the schema already provides. 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 and resource: 'Purchase TRON Energy for a target address,' which clearly states the tool's function. It also distinguishes itself from siblings like 'estimate_cost' and 'get_available_resources' by describing it as a market order that executes a purchase, not just an estimate or view.

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 buy energy for an address) and explains that it's a market order, but it does not explicitly mention when not to use it or name alternatives such as 'estimate_cost' for pre-purchase estimation. The context is clear but lacks exclusions or alternative comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries full burden. It discloses an auth requirement ('Requires API key') and indicates a read-only verification operation via 'Verify...'. It could more explicitly state that this tool has no side effects, but the 'verify' wording and the overall context imply a non-mutating check.

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 compact and front-loaded: the main purpose is stated first, followed by specific required/optional permissions with reasons, usage timing, and an auth reminder. Every sentence adds necessary information, with no fluff 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?

For a simple one-parameter check tool with no output schema, the description covers the key context: purpose, permission details, when to use, and API key requirement. It does not describe the exact return format, but that is less critical for a boolean-style permission verification tool. Overall, it is sufficiently complete for a tool of this simplicity.

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% for the single optional parameter poolAddress, which explains its meaning and default behavior. The tool description adds no extra parameter-level detail beyond the schema, 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 a specific verb ('Verify') with a clear resource ('required active permissions on your pool address'). It distinguishes itself from sibling tools by focusing on checking/verification rather than building or broadcasting permission transactions.

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?

Explicitly states when to run this tool: 'Run this after granting permissions to confirm the platform can operate your pool.' It also differentiates from alternatives by listing the required vs optional permissions, implying that permission-granting tools are the prior step. This gives clear context for selection among permission-related siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the purpose and does not explain effects like whether omitted parameters are left unchanged, any permission requirements, reversibility, or validation rules. This is a significant gap for a mutation tool.

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

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

The description is two sentences, front-loaded with the core action, and every clause adds relevant information 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?

For a 9-parameter mutation tool with no output schema, the description lacks essential guidance on how the parameters interact (e.g., whether partial updates are allowed, min/max duration constraints) and what the result of the update looks like. This makes it insufficient for an AI to invoke correctly in many scenarios.

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, so the baseline is 3. The description adds a high-level summary (toggle, reserves, durations) that maps to schema fields but provides no additional format or relationship details beyond what the schema already gives.

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 ('Update auto-selling configuration for a pool') and specifies the key sub-actions ('Toggle energy/bandwidth selling, set reserves, duration constraints'). This distinguishes it from siblings like get_auto_selling_config, which reads configuration.

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 provides a clear usage context ('Pass the configId from get_auto_selling_config'), indicating the tool modifies an existing configuration. However, it does not explicitly contrast with the 'get' sibling or state when not to use it, so slightly below full marks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description must clarify behavior. It clearly indicates a calculation ('Calculate') which implies no transaction execution, and it specifies the inputs and outputs. However, it does not explicitly state that the cost is an estimate or that no purchase is performed, and it omits the influence of parameters like duration on the cost.

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 action and resource, and every word contributes. No 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?

For a 4-parameter tool with no output schema, the description covers the core purpose and output but misses key contextual details such as the role of durationMinutes and resourceType in the calculation, and it does not mention that the result is an estimate subject to change. While schema descriptions fill some gaps, the description alone would not fully prepare an agent for edge cases.

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 parameters with descriptions, so the baseline is 3. The description adds value by explaining that txCount and txType are used to compute 'energy needed' and 'cost,' giving them purpose. It does not describe all parameters in detail, but the schema handles that; the added context about how inputs drive the calculation is beneficial.

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 'Calculate' and clearly identifies the resource ('cost of purchasing TRON Energy or Bandwidth'). It states the required inputs ('transaction count and type') and the expected output ('energy needed and cost in TRX'). This distinguishes it from sibling tools like buy_energy (actual purchase) and get_swap_quote (swap pricing).

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 is for cost estimation, but it does not explicitly state when to use it versus alternatives such as buy_energy, nor does it provide exclusions or preconditions. The sibling context helps, but the description lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the disclosure burden. It reveals important behavioral traits: automatic energy delegation before broadcast, and two payment methods (API key balance deduction or x402 USDC). It doesn't cover failure modes, but the disclosed behaviors are meaningful and contextual.

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 with high information density. The first sentence states the core purpose; the second covers workflow and payment. No filler 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 covers the key context: what to provide, where to get it, and payment mechanism. It doesn't describe return values or errors, but for an execution tool with a clear parameter schema and workflow, this is adequate. Sibling distinction could be stronger, but overall it's complete enough.

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 ('Pre-signed swap transaction from get_swap_quote') is helpful. The main description reinforces this by instructing to sign and submit the tx, adding practical meaning 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's function: 'Execute a pre-signed swap transaction with automatic energy delegation.' It uses a specific verb (execute), a specific resource (pre-signed swap transaction), and distinguishes itself from sibling broadcast tools by focusing on swaps and energy delegation.

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?

Provides a clear workflow: 'Get the unsigned TX from get_swap_quote, sign it, and submit here.' This tells the agent when to use this tool (after getting a quote) and implies the process. It also mentions payment options, but doesn't explicitly contrast with alternatives like broadcast_transaction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the transparency burden. It discloses that the tool returns statuses, amounts, transaction hashes, timestamps, and requires an API key. This goes beyond the schema by indicating the read-only nature and auth requirement, though it omits potential edge cases like empty results or rate limits.

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-load the core purpose, then list key output fields and the auth requirement. Every sentence contributes value, with no redundant or fluff content.

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 read-only history tool with three optional parameters and no output schema, the description adequately covers purpose, main return fields, and auth. It does not describe ordering or pagination, but these are minor omissions given the schema documents limit/default.

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 mentions action types (stake, vote, claim) which mirrors the actionType enum, but adds no new parameter semantics. The poolAddress behavior is already fully documented in 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 'View execution history of automatic actions' with a specific verb and resource. It narrows the scope to stake, vote, and claim actions for the user's pool, distinguishing it from siblings like get_auto_selling_config and get_orders.

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 (to review automatic action history) but offers no explicit comparison to alternatives or exclusions. 'Requires API key' hints at prerequisites but does not clarify when this tool is preferred over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns current config details (resources, duration, reserves), but does not explicitly state it is read-only or mention any side effects, permissions, or edge cases. The 'Get' verb implies non-destructive behavior, but more transparency would be needed for a higher score.

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-load the purpose and effectively summarize the returned data. Every word earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, parameterless getter with no output schema, the description adequately explains what the tool returns. It does not over-explain or omit critical information, though it could mention whether the config applies to all pools or a selected one.

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. There is no parameter documentation needed, and the description adds no parameter-specific meaning, which is acceptable.

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 identifies the resource 'auto-selling configuration' with scope 'for your pools.' It clearly distinguishes from sibling 'configure_auto_selling' (which presumably sets the config) and other 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 usage as a getter for auto-selling config but does not explicitly explain when to choose this over alternatives like configure_auto_selling. No exclusions or alternatives are mentioned, leaving guidance implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the burden. The verbs 'Get' and 'Shows' imply a read-only operation, but it does not disclose data freshness, aggregation methodology, or potential error conditions. This is basic but not rich behavioral context.

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

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

Two concise sentences with no filler. Every word adds value: the first defines scope, the second provides practical interpretation.

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?

No output schema exists, but the description conveys both the output (total available amounts) and its meaning (purchasable now). It could include units or response structure, but for a simple read tool with no required params, this is 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?

Schema description coverage is 100%, so parameters are already well-documented. The tool description mentions 'Energy and Bandwidth' which echoes the resourceType enum but adds no additional semantics beyond the schema's own descriptions. 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 the action ('Get total available Energy and Bandwidth across all active pools') with a specific resource. It distinguishes from buy/pool tools by focusing on aggregate availability, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence 'Shows how much resource can be purchased right now' provides clear context for when to use the tool (checking purchase availability). It does not explicitly exclude alternatives or state when not to use, but the context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the burden of behavioral disclosure. It states the authentication requirement ('Requires API key authentication'), which is a useful behavioral trait, and the verb 'Get' implies a read-only, non-destructive operation.

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 with two short sentences, each earning its place. The primary action is front-loaded, and the authentication requirement is stated briefly. 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 simple 0-parameter tool with no output schema, the description provides the essential purpose and auth requirement. It is slightly vague about what 'deposit information' includes, but this is a minor gap given the tool's simplicity.

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, and the schema description coverage is 100%. Per the rubric, the baseline for 0 parameters is 4. The description adds no parameter details (none needed) but appropriately conveys the tool's purpose.

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 your current TRX balance') and resource ('TRX balance and deposit information'). It distinguishes from siblings by focusing on the combined balance and deposit info, which is unique among the listed 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 usage for checking balance and deposit info, but does not explicitly state when to use this tool versus alternatives like get_deposit_info or get_earnings. No exclusions or alternatives are mentioned, so usage context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the burden of disclosing behavior. It clearly implies a read-only operation via 'get', but does not mention any prerequisites (e.g., registration) or behavioral nuances such as whether the address is static or dynamic. It does not contradict annotations (none 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, focused sentence that front-loads the action and includes the purpose. No unnecessary words or restatements.

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 zero-parameter informational tool with no output schema, the description sufficiently states what the tool does and why. It could optionally mention whether an account or registration is required, but this is not essential for basic usage.

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 needs to add no parameter meanings. The schema coverage is trivially 100%, and the description appropriately omits parameter 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 the tool's function: retrieving a deposit address for topping up with TRX. It uses a specific verb ('get') and resource ('deposit address'), distinguishing it from sibling tools like get_balance or buy_energy.

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 this tool—when the user needs to top up their account balance with TRX. It does not explicitly list alternatives or exclusions, but the purpose is unambiguous and does not conflict with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description must carry the full burden of disclosure. It adds the breakdown categories and optional date filtering, but does not clarify that the tool returns all pools without pool-specific filtering (no pool parameter exists), nor does it specify the output shape. The verb 'Get' implies read-only, but there is no explicit statement about side effects.

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

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

The description is two sentences, concise and front-loaded with the primary purpose, followed by the optional filter. 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?

For a simple read tool with no output schema, the description sufficiently explains the returned breakdown categories. However, it doesn't specify the exact output format (e.g., array of pools) or how the date range affects the values, leaving some ambiguity.

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 parameters with basic format descriptions. The description adds meaningful context by stating that startDate and endDate are for optional date range filtering, which goes beyond the raw schema descriptions. This is a valuable addition.

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 an earnings breakdown by pool, enumerating the three components (total earned, pending payout, paid out). This distinguishes it from siblings like get_balance (overall balance) and get_pool_stats (pool performance) by focusing specifically on earnings breakdown.

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 it: whenever you need earnings breakdown by pool. It also notes the optional date range filtering. However, it doesn't explicitly mention alternatives or scenarios where this tool is not appropriate, so it's clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden of conveying behavioral traits. It states what data is included but never explicitly says it is a read-only, side-effect-free operation, nor does it mention any limitations like data freshness or scope constraints. The term 'overview' implies a read action but does not explicitly disclose the behavioral 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 two sentences, with the first sentence front-loading the tool's purpose and contents, and the second sentence adding a concise use-case. Every word adds value, with no repetition of the tool name or title.

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 no parameters and no output schema, the description provides a surprisingly complete overview of what the agent will learn: prices, availability, allowed durations, order constraints, and transaction types. It lacks details on response format, but that is largely implied by 'overview' and the list of data points.

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 input schema provides no semantic information. The baseline for 0 params is 4, and the description reinforces what the caller can expect from the tool, compensating for the lack of 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 identifies the tool as a 'comprehensive market overview' and enumerates the specific data it provides (prices, availability, allowed durations, order constraints, transaction types). This distinguishes it from narrower sibling tools like get_prices and get_available_resources, making the 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 statement 'Useful for agents to understand what they can purchase' provides a clear context for when to use the tool. While it doesn't explicitly name alternatives or exclusions, the context is unambiguous and helps the agent decide to call this tool for market-level discovery rather than individual data endpoints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the disclosure burden. It adds auth needs ('Requires API key') and data source ('fetched directly from TRON blockchain'), which are valuable behavioral traits. It does not explicitly state that the operation is read-only, but the verb 'Get' strongly implies 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 sentences, front-loaded with the core purpose, followed by essential operational details. No redundant or vague language.

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 one optional parameter and no output schema, the description's list of included data serves as an implicit return value breakdown. It covers the key operational requirement (API key) and data source, though it could mention the read-only nature explicitly.

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 the single poolAddress parameter, including default behavior if omitted (100% schema coverage). The description adds no additional parameter semantics, meeting the baseline 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 uses the specific verb 'Get' and names the resource 'live blockchain state for your pool', enumerating the included data (TRX balance, frozen resources, voting status, etc.). This clearly differentiates it from sibling tools like get_balance or get_pool_stats.

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: it's for on-chain pool status, directly from TRON. However, it doesn't explicitly state when not to use it or name alternatives, so it falls short of the highest tier.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries full burden. It discloses that the tool is read-only ('Get') and that results are sorted by creation time, but it does not describe response format, pagination, or potential limitations such as what 'recent' means.

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 concise sentences, front-loading the purpose and avoiding unnecessary details. Every word adds value.

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 adequately covers the core purpose, sorting behavior, and optional filter. However, since there is no output schema, it does not describe the structure of the returned orders, which is a minor gap for a simple read-only list 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?

Both parameters are fully described in the schema (limit with default and maximum, status with enum values). The description only repeats 'optional status filter', adding no extra semantic value 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 'Get your order history' with an optional status filter and specifies that it returns recent orders sorted by creation time. This distinguishes it from sibling 'get_order_status', which likely targets a single order's status.

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 order history and mentions the optional filter, but it does not explicitly mention alternatives or when not to use this tool. It provides clear context without exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions 'delegation progress' as an included detail, which is useful, but it does not explicitly state this is a read-only operation, nor does it describe the return format, potential errors, or any side effects. For a simple getter, this is adequate but not rich.

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

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

The description is a single concise sentence that front-loads the primary purpose and adds a relevant detail ('including delegation progress'). No extraneous 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?

Given the tool has one parameter and no output schema, the description is functional but does not fully clarify what 'detailed status' entails or how delegation progress is presented. It lacks guidance on response structure or coverage, making it adequate but not complete for an agent without prior 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 input schema has 100% coverage with a clear description for orderId ('Order ID (UUID format)'). The tool description adds no extra meaning beyond the schema, 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 function: 'Get detailed status of a specific order including delegation progress.' It uses a specific verb ('get') and resource ('specific order'), and the qualifier 'specific' differentiates it from the sibling tool 'get_orders' which likely lists orders.

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 you have a specific orderId and need its status, but it does not explicitly state when to use this tool versus alternatives like 'get_orders' or 'get_pool_delegations'. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description must convey behavioral traits. The verb 'Get' implies a read-only operation, and the description clarifies the data returned, but it does not explicitly state that there are no side effects or mention permissions, rate limits, or other operational caveats. This is acceptable for a simple read tool but could be more explicit.

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 purpose, and contains no redundant information. Every word adds value.

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 one optional parameter and no output schema, the description adequately conveys what the tool does and what it returns (active delegations, recipients, expiration). It is complete for its complexity.

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 in the schema fully explains the optional poolAddress filter. The tool description adds no additional parameter-level details, so it stays at the baseline for high schema coverage.

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

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

The description uses the specific verb 'Get' with a clear resource ('active delegations from your pools') and adds detail about what is shown (who received energy/bandwidth and expiration). This distinguishes it from sibling tools like get_available_resources or get_pool_stats.

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 contexts when to use it (for viewing active delegations from your pools), but it does not explicitly mention exclusions or alternatives. The context is evident from the wording, though no sibling comparison is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full burden. It discloses the API key requirement and hints at the response content by listing the statistics covered, but it does not explicitly confirm the operation is read-only or mention potential limitations such as rate limits or the scope (all pools vs a specific pool). This is adequate but not rich.

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

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

The description is a single, front-loaded sentence that efficiently captures the tool's purpose and lists the key statistics returned. There is no redundancy or unnecessary detail, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-argument stats endpoint, the description covers the main purpose and the categories of output data. However, without an output schema or additional behavioral detail, the agent may not know the exact response shape or whether the stats are aggregate across all pools or filtered. Still, it is largely sufficient for a straightforward read operation.

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, and the schema is empty. According to the rubric, a zero-parameter tool receives a baseline score of 4, as there are no parameter semantics to explain. The description adds no parameter-specific meaning, which is appropriate given there are none.

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 that the tool retrieves comprehensive statistics for energy/bandwidth pools, enumerating delegations, revenue, utilization, and APY. This distinguishes it from sibling tools like get_pool_delegations and get_earnings, which are single-purpose, making the purpose explicit and specific.

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 is used to obtain an all-in-one view of pool statistics, but it does not explicitly state when to use it instead of more specific sibling tools like get_pool_delegations or get_earnings. There is no explicit when/when-not guidance or mention of alternatives, only the inferred 'comprehensive' nature.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations present, the description carries the transparency burden. It discloses the return format (price per unit in SUN) and implies a read-only operation by using 'Get'. However, it omits details about potential response size, authentication requirements, or real-time vs. delayed data, leaving some behavioral aspects unstated.

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—two sentences, front-loaded with the action, and every word adds meaningful detail. No fluff or redundancy in the text.

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 with one optional parameter and no output schema, and the description explains both the purpose and the return format. It does not mention default behavior for resourceType, but that is covered in the schema. Overall, it is sufficiently complete for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage for the sole parameter resourceType, including its enum values and default behavior. The description adds no extra semantic 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 the tool retrieves current TRON Energy and Bandwidth minimum prices across all duration tiers, specifying the output unit (SUN). The verb 'Get' and specific resources distinguish it from sibling tools like get_market_overview or estimate_cost.

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 explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It simply states what the tool does without contextualizing its role among related tools like get_market_overview or get_available_resources.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns an unsigned transaction for client-side signing and that signing precedes submission via execute_swap. It also notes the API key requirement. It does not cover edge cases like no liquidity or fee structures, but for a quote tool the core behavior is well described.

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, immediately states what the tool does, and provides the necessary workflow hints without any filler. It is front-loaded with the key action and resource, making it 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?

For a tool with no output schema and no annotations, the description adequately conveys the full flow: quote generation, unsigned TX, client signing, and follow-up via execute_swap. It also covers the API key requirement. It does not detail return values, but that is expected for a simple quote 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%, so the schema already documents each parameter. The description does not add any additional parameter-specific meaning about formatting (e.g., base units) or default slippage, but those are already in the schema. The addition of 'Requires API key' is a prerequisite rather than a parameter semantic.

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 a price quote and unsigned transaction for a token swap on SunSwap DEX. It uses the specific verb 'Get' with a concrete resource and distinguishes itself from execute_swap by explicitly noting the next step is to sign and submit via that sibling tool.

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: use this to get a quote/unsigned TX, sign it client-side, then submit via execute_swap. It also mentions the API key requirement. It does not explicitly state when not to use this tool, but the workflow is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns a challenge string, requires signing with the private key, and is the first step before verify_registration. It also states that no authentication is needed. This is good behavioral disclosure, though it doesn't cover edge cases like expired challenges or duplicate registrations.

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 sentences, front-loaded with the primary action. Every sentence contributes: what it does, what it returns, and what to do next. No fluff or redundancy. It is 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 one-parameter tool with no output schema, the description adequately covers the essential flow: returns a challenge, how to sign it, and the next step (verify_registration). It doesn't mention error cases or formatting details, but those are covered by the schema and the guidance given. It is complete enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for the address parameter with a clear description ('TRON wallet address, 34 characters'). The tool description adds minimal extra semantic value beyond reiterating that the address is used to start registration. Per the baseline for high schema coverage, a 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: 'Start agent registration by providing your TRON address.' It uses a specific verb ('start') and resource ('agent registration'), and the flow described distinguishes it from sibling tools like verify_registration. The title 'Register Agent' reinforces the action.

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: it instructs the user to call verify_registration after signing the challenge, and notes 'No authentication required.' It doesn't explicitly list exclusions or alternatives, but the step-by-step flow makes the intended usage obvious. This is clear guidance without being overly verbose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the burden of disclosure. It explicitly states that registration creates a pool and auto-selling configuration, implies a mutation, and importantly discloses the post-registration permission grant requirement and a verification step. It does not describe reversibility or return values, but the provided context is valuable.

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

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

The description is three sentences, all of which carry meaningful information. It is front-loaded with the core purpose, followed by critical operational details and a verification pointer. 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?

Given the tool's complexity (4 params, no output schema, no annotations), the description covers the main aspects: what it does, the required follow-up actions, and an auth requirement. Missing return value description or idempotency details slightly reduce completeness, but the essential context for safe usage 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 coverage is 100%, so the description is not required to explain each parameter. It adds meaningful context for the key paymentAddress parameter ('This is the address where you hold/stake TRX'), which enriches the schema's description. The boolean parameters are already clearly described in the schema, so this is above the baseline.

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 ('Register') and resource ('TRON address as an energy/bandwidth selling pool on PowerSun'), clearly distinguishing it from siblings like check_pool_permissions and configure_auto_selling. It also mentions the creation of pool and auto-selling configuration, which uniquely identifies 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?

The description provides clear next-step guidance: after registration, the user must grant active permissions and should verify using check_pool_permissions. It also notes the API key requirement. However, it does not explicitly state when not to use this tool or mention alternatives, so it stops just 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.

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

No annotations provided, so description carries the burden. It discloses permission requirements, auto-selection behavior, and auto-claim of rewards, but does not mention whether the operation is irreversible, replaces previous votes, or incurs transaction costs.

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?

Three sentences with no fluff, though slightly redundant ('Vote' and 'automatically selects' overlap). Front-loaded purpose and concise overall.

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?

Covers prerequisites, outcome, and auto-claim behavior, but lacks expected return value or post-voting state. Without an output schema, a more explicit description of what the tool returns would improve 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%, so the parameter is already described in the schema. The tool description adds no additional parameter meaning, relying on the schema's explanation of poolAddress and its default behavior.

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?

Clearly states it votes for the best Super Representative with highest APY to earn rewards. The verb 'Vote' and resource 'SR' are specific, and this tool is distinct from all siblings (no other voting tool exists).

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?

Implied usage when you want to vote for an SR, but no explicit when-not-to-use or alternative recommendations. It does provide prerequisites (VoteWitness permission, API key), which gives some contextual guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool returns an API key, upgrades the current session to authenticated, and requires no authentication. It could add failure behavior or side effects, but the key behavioral traits are clearly stated.

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 sentences, front-loaded with the core purpose, then outcomes, then session behavior. Every sentence earns its place, with no filler or repetition of schema details.

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 no output schema, the description adequately explains the return value (API key) and post-condition (authenticated session). It also correctly notes the tool is unauthenticated. It lacks error-case details, but for a simple verification tool, the description is sufficiently complete for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description adds minimal parameter context beyond mentioning the 'signed challenge' concept, which aligns with the schema's signature description but does not materially enhance it.

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 ('Complete agent registration') plus resource ('signed challenge') and clearly distinguishes from the sibling 'register' tool, which presumably initiates registration. It also states concrete outcomes: returns an API key and upgrades the session to authenticated.

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 this is the follow-up to registration ('Complete agent registration') and explains that it should be used before authenticated tools like buy_energy and get_balance will work. It does not explicitly name when not to use it, but the context is strong enough for an agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the transparency burden. It discloses the minimum withdrawal, that processing is on-chain, and that it may take minutes. This goes beyond the schema to explain the operational behavior, though it omits details like fees or reversibility.

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, immediately states the action, then provides essential constraints. There is no redundant or vague wording; 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?

For a simple single-parameter tool with no output schema, this description covers the essential context: what it does, the minimum amount, and the expected processing behavior. It could add a note about balance sufficiency or transaction hash feedback, but the current level is sufficient for safe invocation.

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 'amount' is already fully described in the schema (with minimum 100 TRX). The description repeats this minimum, adding no new semantic detail beyond what the schema provides. Since schema coverage is 100%, 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 ('Withdraw') and clearly identifies the resource ('TRX from your account balance to your wallet'). This unambiguously distinguishes it from sibling tools like buy_energy or execute_swap, 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 clearly implies when to use this tool: when you want to move TRX out of your account to your wallet. It also provides a key constraint (minimum 100 TRX) and a time expectation. However, it does not explicitly state when to avoid this tool or name alternative tools, so it stops short of being fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.