TRON infrastructure for AI agents.

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation3/5
While descriptions clarify specific behaviors, multiple tools overlap in purpose: four distinct price-discovery functions (analyze_prices, get_prices, get_best_price, compare_providers) and two transaction history lookups (get_transaction_history for Merx vs search_transaction_history for on-chain) create ambiguity that requires careful reading to distinguish.
Naming Consistency4/5
Nearly all tools follow a consistent verb_noun snake_case pattern. Minor deviations like 'withdraw' (lacks resource suffix), 'simulate' (incomplete object), and 'login' (noun rather than verb form) break the otherwise predictable convention.
Tool Count2/5
At 53 tools, the surface significantly exceeds the 25+ threshold for 'too many', even given the broad scope spanning TRON blockchain operations, Merx exchange, and swaps. The granularity fragments simple workflows (e.g., price checking into four separate tools) making agent navigation cumbersome.
Completeness3/5
Core creation and retrieval operations are present, but notable lifecycle gaps exist: no cancel_order, delete_monitor, or delete_standing_order despite having creation tools for these resources. Deposit functionality also appears limited to TRX despite the platform handling TRC-20 tokens.
Average 3.6/5 across 46 of 53 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full behavioral disclosure. It only conveys authorization requirements ('No auth required'), but omits read-only safety confirmation, rate limits, data granularity, or how far back the history extends.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely terse at two fragments; while lacking fluff, the brevity compromises clarity. 'Price snapshots' is vague and wastes the opportunity to specify the resource domain (ENERGY/BANDWIDTH) upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 3-parameter read tool, but lacks expected context for a history-focused endpoint: no mention of data format, pagination, or the specific resource types being priced, leaving functional gaps despite the minimal surface area.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage ('Filter by resource type', etc.), so the baseline is 3. The description adds no parameter syntax details, constraints, or examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States it retrieves historical price data, but fails to specify that this applies to ENERGY/BANDWIDTH resources (per schema enum), leaving ambiguity amid sibling tools like get_trx_price and get_token_price. The temporal aspect ('Historical') provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'No auth required' which establishes a prerequisite, but provides no guidance on when to prefer this over get_prices or get_token_price, nor when the historical view is appropriate versus current pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It adds valuable operational context ('No auth required') and output characteristics ('trends and recommendations'), but omits whether the operation is read-only, rate limits, or how recommendations are generated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with the primary purpose front-loaded. Every word earns its place, though the extreme brevity leaves gaps in sibling differentiation and parameter context that a slightly longer description could address.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without output schema, the description adequately hints at return values ('trends and recommendations'). However, given the presence of numerous sibling price tools and lack of annotations, the description should specify the analysis scope (ENERGY/BANDWIDTH) and ideal use cases to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the resource parameter is fully documented as 'Filter by resource type. Omit for all.'), establishing a baseline of 3. The description adds no explicit mention of the resource parameter or its ENERGY/BANDWIDTH enum values, but the schema sufficiency prevents a lower score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs 'Market price analysis with trends and recommendations' which uses a specific verb and suggests output format. However, it fails to mention the critical constraint that this only analyzes ENERGY and BANDWIDTH resources (as revealed in the schema), leaving the scope ambiguous regarding whether it supports tokens, commodities, or other assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'No auth required' provides one usage constraint, but there is no guidance on when to use this tool versus siblings like get_price_history, get_best_price, or get_prices. Given the crowded namespace of price-related tools, explicit differentiation is needed but absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full disclosure burden. It mentions the authentication requirement but omits critical behavioral traits: that the operation is irreversible, consumes gas fees, requires sufficient TRX for bandwidth, may fail due to slippage or liquidity, and returns transaction details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy. The first identifies the operation and platform; the second states the critical prerequisite. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-stakes DeFi mutation with no output schema and no annotations, the description is insufficient. It lacks warnings about financial risk, irreversibility, gas costs, expected return values (transaction hash?), and failure modes essential for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds minimal parameter-related context—primarily noting the external TRON_PRIVATE_KEY requirement (not in schema)—but does not clarify parameter formats (e.g., whether amount is in base units or decimal) or slippage calculation specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (execute), resource (token swap), and platform (SunSwap V2). However, it does not explicitly differentiate from the sibling tool `get_swap_quote`, which agents might confuse as the execution step versus the quoting step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it notes the prerequisite 'Requires TRON_PRIVATE_KEY', it fails to provide workflow guidance such as when to use this versus `get_swap_quote` (get price first) or `approve_trc20` (required approval before swapping TRC20 tokens). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only reveals the authentication requirement ('No auth required'). It fails to disclose whether this is a read-only operation, what data structure the quote returns, rate limits, or quote expiration behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. The core purpose ('Get a real swap quote from SunSwap V2') is front-loaded, while the constraint ('No auth required') follows as essential secondary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a DeFi quoting tool with 4 parameters and no output schema or annotations, the description is inadequate. It fails to describe what the quote contains (price, route, minimum output, deadline) or its relationship to 'execute_swap,' which is critical for agent workflow completion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting all four parameters including token symbols and slippage tolerance. The description adds no additional parameter semantics (such as valid token formats or amount precision), but the comprehensive schema makes this acceptable at baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Get'), resource ('swap quote'), and source system ('SunSwap V2'), distinguishing it from generic price tools. However, it does not explicitly differentiate from siblings like 'get_best_price' or 'analyze_prices' that may also provide pricing information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'No auth required,' which indicates a usage constraint, but provides no guidance on when to use this versus 'execute_swap' (which performs the actual swap) or versus 'simulate.' It lacks prerequisites or workflow context for the quoting process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully notes authentication requirements but fails to indicate read-only safety, return value structure, pagination behavior, or what constitutes a 'monitor' in this domain (e.g., price monitors, transaction monitors).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at two sentences. Information is front-loaded with the core action first, followed by the auth constraint. No redundant or wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low parameter complexity, the absence of both annotations and an output schema creates significant gaps. The description fails to explain what data structure is returned, what 'monitors' represent in this TRON/crypto toolset context, or behavioral constraints beyond authentication.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description confirms the status filter is 'optional' (aligning with zero required parameters) but adds no semantic detail about the enum values (ACTIVE/CANCELLED) or query syntax beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (List) and resource (monitors) with explicit mention of the optional status filter. Distinguishes from sibling 'create_monitor' through the action verb, though it could explicitly reference the creation tool to strengthen differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Auth required' which is a necessary constraint, but provides no guidance on when to use this versus alternatives (e.g., when to filter by ACTIVE vs CANCELLED) or its relationship to 'create_monitor'. Lacks explicit prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only discloses that authentication is required ('Auth required'), but omits critical behavioral traits: whether the operation is read-only (implied but not confirmed), pagination behavior, the time window defining 'recent', rate limits, or the structure of returned order objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two short sentences and no redundant content. It is front-loaded with the primary action. However, 'Auth required' is telegraphic rather than smoothly integrated (e.g., 'Requires authentication'), slightly detracting from the flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (two primitive parameters, no output schema), the description provides minimum viable coverage by stating the core operation and authentication requirement. However, it lacks completeness regarding return value structure, the definition of 'recent', and the presence of the 'limit' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions the 'optional status filter' which adds context about the 'status' parameter's purpose and optionality, but completely omits any reference to the 'limit' parameter, relying entirely on the schema for that parameter's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('List') and resource ('orders') plus a scope constraint ('recent'). However, it does not explicitly differentiate from the sibling tool 'get_order' (singular), though 'recent' and plural 'orders' imply a multiple-record retrieval pattern versus single-record retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description fails to provide explicit usage guidelines, when-not-to-use conditions, or alternative tool recommendations. It does not clarify when to use 'list_orders' versus 'get_order' for specific order lookups, nor does it mention prerequisites beyond the terse 'Auth required'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses automatic routing logic ('Routed to cheapest provider') and authentication requirement. However, with no annotations and no output schema, it omits crucial purchasing behavior: payment method, failure modes beyond price limits, atomicity, and return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely terse at three short sentences. No redundancy, but arguably underspecified given the complexity of blockchain resource procurement—front-loaded action is good, but length is insufficient for the domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Financial transaction tool with no annotations and no output schema requires extensive behavioral documentation. Missing: return structure, error handling, payment flow, and side effects on the target_address balance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in struct fields. Description adds no parameter-specific guidance beyond implying the resource types through the first sentence, warranting baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Buy') identifies the transaction type and resources ('energy or bandwidth') with platform context ('Merx'). However, it fails to distinguish from sibling order tools like 'create_paid_order' and 'create_standing_order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only mentions 'Auth required' as a prerequisite. Provides no guidance on when to use this generic order creation versus siblings (create_paid_order, create_standing_order) or other resource acquisition methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully indicates the server-side persistence and authentication requirement, but lacks critical behavioral details: execution semantics (synchronous vs queued), cancellation mechanisms, idempotency guarantees, or budget enforcement behavior when 'max_executions' is reached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with zero waste. Two sentences deliver the core value proposition and authentication requirement. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Grossly insufficient for a complex 7-parameter automation tool with financial implications (budget_trx). No output schema is provided, yet the description does not explain what the tool returns (e.g., order ID) or how to manage created orders (via list_standing_orders). Missing lifecycle documentation for a persistent server-side resource.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, establishing a baseline of 3. The description adds semantic context by mentioning 'trigger-based automation,' which helps frame the relationship between trigger_type/trigger_params and action_type/action_params, but does not elaborate on parameter formats (e.g., valid cron syntax) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Create) and resource (standing order) with key characteristics (server-side, trigger-based automation). However, it fails to distinguish from siblings like 'create_order' or 'create_paid_order', leaving ambiguity about when to choose this over immediate execution orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance provided is 'Auth required,' which is a prerequisite rather than usage context. There is no indication of when to use this automated approach versus immediate execution tools like 'create_order' or 'ensure_resources', nor any mention of prerequisites like existing account balances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations provided, the description carries the full disclosure burden. It successfully notes the authentication requirement but omits error handling (e.g., missing ID behavior), rate limits, and detailed return structure. It barely meets minimum viable disclosure for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero fluff. The core purpose ('Get order details...') is front-loaded, with prerequisites ('Auth required') following. Appropriately sized for the tool's simplicity, though the second sentence could specify return structure instead of just auth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input and lack of output schema, the description adequately covers the basic contract by mentioning returned data types ('details', 'fill status'). However, with numerous order-related siblings present, the absence of selection guidance creates a completeness gap for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage ('The order UUID'), establishing a baseline of 3. The description adds minimal semantic value beyond the schema—only implying the 'order_id' parameter via 'by ID' without adding format constraints, requirements, or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get'), resource ('order details'), and scope ('fill status by ID'), identifying the unique lookup capability. However, it lacks explicit differentiation from sibling tools like 'list_orders' or 'create_order', which could cause selection ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While 'Auth required' establishes a prerequisite, the description provides no guidance on when to use this specific tool versus siblings (e.g., 'list_orders' for searching, 'get_order' for specific ID retrieval). No alternatives or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Absent annotations, the description carries the full disclosure burden. It successfully communicates the authentication requirement (none), but omits other behavioral traits: read-only/idempotent nature, error handling for invalid addresses, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. The first sentence states the function; the second states the auth policy. No wasted words, front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool without output schema, the description should ideally describe return value structure (object with three fields? individual values?). Currently omits this, leaving the agent blind to expected response format despite adequately covering inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter ('TRON address (starts with T.)'), so the baseline applies. The description adds no incremental parameter guidance (examples, validation rules, or format constraints) beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Check) and resources (energy, bandwidth, TRX balance) for TRON addresses. Implicitly distinguishes from sibling tools like get_trx_balance (which likely omits resource metrics) by explicitly naming energy/bandwidth, though lacks explicit comparative guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus siblings like get_account_info, get_balance, or ensure_resources. The only contextual hint is 'No auth required' which is a constraint, not a usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses authentication requirements (none) and implies read-only nature via 'Get'. However, with no annotations provided, the description carries full burden and omits other behavioral traits like caching, rate limits, error handling, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two lean sentences with zero waste. First sentence front-loads purpose (what it gets, from where), second sentence adds critical behavioral constraint (no auth). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 2-parameter query tool with complete schema coverage. Covers core purpose and auth, but lacks output description (no output schema exists) and sibling differentiation critical for the crowded price-tool namespace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with clear descriptions for both parameters ('Filter by resource type', 'Filter by duration'). Description mentions 'energy and bandwidth' which maps to enum values but doesn't add syntax details or usage examples beyond what the schema provides. Baseline 3 appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Get), resource (energy and bandwidth prices), and scope (from all Merx providers). Implicitly distinguishes from siblings like get_best_price (all vs best) and get_price_history (current vs historical), though explicit guidance would strengthen this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'No auth required' which is useful usage information, but fails to clarify when to use this versus similar tools like get_best_price, compare_providers, or get_price_history. No explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully identifies the external data sources (SunSwap, CoinGecko) and authentication requirements, but omits operational details like caching behavior, rate limits, error handling for unsupported tokens, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient at 9 words. The description front-loads the action, specifies the mechanism, and states the auth requirement without redundancy. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool, covering the essential function and data provenance. However, given the high sibling complexity (numerous price tools) and lack of output schema, it should provide more differentiation or behavioral context to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (token parameter fully documented), establishing a baseline of 3. The description adds no additional parameter-specific context (e.g., case sensitivity, supported token standards, or validation rules) beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get token price') and the specific data sources ('SunSwap quote + CoinGecko USD rate'), which implicitly distinguishes its methodology from siblings like get_best_price or get_swap_quote. However, it does not explicitly clarify when to prefer this over the five other price-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it notes 'No auth required' (a prerequisite), it provides no guidance on when to select this tool versus alternatives like get_best_price, get_prices, or get_swap_quote. Given the crowded namespace of price tools, this omission creates selection ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the authentication requirement (MERX_API_KEY) but omits other critical behavioral traits such as pagination behavior, default/maximum result limits, data freshness, or whether the operation is read-only and safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states purpose, second states auth requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the minimum (purpose + auth) but leaves gaps. For a transaction history tool likely returning variable-length datasets, omitting pagination details, result limits, or output payload expectations makes this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage ('Time period to query. Default: 30D.'), so the baseline score is 3. The description adds no parameter-specific semantics (e.g., it does not mention the 'period' parameter, valid formats, or the default), but it does not need to compensate given complete schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Get...transaction history') and scope ('Merx account'). Deducted one point because it fails to distinguish from sibling 'search_transaction_history'—it is unclear when to use this time-bounded list versus the search variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions the prerequisite 'Requires MERX_API_KEY', which is relevant to usage. However, provides no guidance on when to use this tool versus 'search_transaction_history' or 'get_transaction' (singular), or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses 'Auth required' which is critical behavioral context, but omits other key traits like read-only status, pagination behavior, or what the response structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences with no waste: the first establishes purpose and scope, the second states the auth constraint. Information is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one simple parameter with complete schema coverage and no output schema, the description is minimally adequate. However, it should ideally clarify the relationship to 'list_orders' and confirm the read-only nature given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'status' param is documented as 'Filter by status.'). The description adds that the filter is 'optional', confirming the zero required parameters, but this is largely redundant with the structured schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (List) and resource (standing orders), distinguishing the scope from 'list_orders' by specifying 'standing orders'. However, it does not explicitly differentiate when to use this versus its sibling 'list_orders' or 'get_order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the 'optional status filter' which implies usage, but provides no explicit guidance on when to use this tool versus alternatives like 'list_orders' or 'get_order', nor any prerequisites beyond the auth note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reveals executes on-chain TRX transfer and includes verification logic, hinting at async/blockchain behavior. However, missing critical mutation details: transaction fees, irreversibility, required confirmations, failure modes, or idempotency—especially important given zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, nine words, zero redundancy. Action verb front-loaded. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal parameter complexity (1 param) and no output schema reduce burden, but as a financial mutation tool, the description omits essential operational context like cost implications, authorization scope, or balance requirements that would aid agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (invoice_id described as 'Invoice ID to pay'), establishing baseline 3. Description adds no additional semantic context about ID format, source, or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Pay), resource type (x402 invoice), and mechanism (sending TRX and verifying payment). Distinguishes from generic transfer tools via 'x402' specificity and verification step. Minor gap: assumes familiarity with 'x402' protocol without brief context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to select this versus sibling tools like 'create_order', 'deposit_trx', or 'transfer_trx'. Does not indicate prerequisites (e.g., TRX balance requirements) or when payment workflows should use this specific endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It discloses the session-scoped nature ('Session-only'), which is essential. However, it omits mutation details such as whether this creates immediate transactions, overwrites previous auto-deposit settings, or what happens on trigger failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy. Front-loaded action ('Configure automatic top-up') followed by constraint ('Session-only'). Minor ambiguity in whether 'Session-only' refers to the configuration duration or deposit timing prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-parameter schema and lack of annotations/output schema, the description covers the essential purpose and session constraint. However, it omits expected return values, side effects (e.g., interaction with existing monitors), and disable/cancellation procedures, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (threshold_trx, deposit_amount_trx, max_daily_deposits fully documented). The description mentions 'threshold' generally but does not add semantic value beyond the schema—such as explaining why amounts are strings not numbers, or the relationship between threshold and deposit amount.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Configure' and clear resource 'automatic top-up' identify the tool's function. The phrase 'when balance drops below a threshold' defines the trigger condition, and 'Session-only' distinguishes this from persistent automation siblings like create_standing_order. However, it does not explicitly contrast with manual deposit_trx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Session-only' constraint provides critical usage context (configuration expires with session). However, it lacks explicit guidance on when to choose this over manual deposits (deposit_trx) or persistent standing orders, and does not state prerequisites like minimum balance requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses validation, simulation behavior, and cost estimation features. Also notes auth requirement. Lacks critical details for a financial execution tool: atomicity guarantees (all-or-nothing execution?), error handling, and side effects on partial failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: purpose first, behavioral features second, requirements third. No redundancy. Front-loaded with action verb. Minor quibble: 'etc.' is vague, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimum viable for a complex financial orchestration tool. With 100% schema coverage and no output schema, description covers essentials (purpose, validation, auth). However, given complexity of multi-step blockchain operations, gaps remain regarding return value structure, step failure behavior, and interaction with sibling transaction tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with clear parameter definitions. Description adds value by connecting 'simulates' to dry_run behavior and 'resource cost estimates' to resource_strategy, but primarily reinforces what the schema already documents. Baseline 3 appropriate given comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Execute' and resource 'multi-step operation' with concrete examples (transfer, swap, buy resources) that distinguish it from single-step siblings like transfer_trx or execute_swap. The 'multi-step' qualifier effectively differentiates its orchestration role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisite ('Auth required') and implies usage through 'multi-step' capability, suggesting when to use it (complex workflows). However, lacks explicit guidance on when to prefer specific tools (execute_swap, transfer_trc20) versus this orchestration tool, or when to use dry_run mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully reveals the authentication requirement (MERX_API_KEY), but omits other behavioral traits such as what happens if the key is missing, whether the result is cached, or the specific structure of the returned address/memo data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, efficient sentences with zero redundancy. The purpose is front-loaded in the first sentence, and the prerequisite is clearly stated in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description identifies what is retrieved (address and memo) and the auth requirement, it lacks description of the return format (critical given no output schema exists) and does not explain the 'memo' concept for users unfamiliar with tagged deposits. For a financial operation tool, this leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. Per the rubric guidelines for zero-parameter tools, this warrants a baseline score of 4, as there are no parameter semantics to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the exact resource ('Merx deposit address and memo'), clearly indicating this is a retrieval operation. However, it does not explicitly distinguish this from the sibling tool `deposit_trx`, which could confuse whether this tool performs the deposit or merely retrieves the address for future use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states a prerequisite ('Requires MERX_API_KEY') but provides no guidance on when to use this tool versus alternatives like `deposit_trx` or `create_order`, nor does it explain the workflow context (e.g., 'use this before depositing funds').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds valuable auth context ('No MERX_API_KEY needed'). However, fails to disclose what successful login returns (session token, cookie, temporary access?), side effects, or security considerations (rate limits, lockout behavior) critical for authentication tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely compact two-sentence structure with no filler. Front-loaded with action. Secondary sentence provides useful authentication context. However, brevity comes at cost of missing behavioral details (output format) that would require third sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic invocation but incomplete for an authentication tool with no output schema. Missing critical information about return values (auth tokens, session identifiers) and state changes resulting from login.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for both email and password parameters. Description adds minimal semantic value beyond schema, only clarifying these are for a 'Merx account'. Baseline 3 appropriate when schema does heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Log in' and resource 'existing Merx account'. The phrase 'existing' effectively distinguishes from sibling 'create_account', and 'No MERX_API_KEY needed' distinguishes from 'set_api_key' and other authenticated tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit guidance via 'existing' (requires pre-registered account) and 'No MERX_API_KEY needed' (credential-based vs token-based). However, lacks explicit when-to-use (e.g., 'use when you have email/password but no API key configured') and mentions no prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It adds valuable context about the declarative/idempotent pattern and differential purchasing (only missing amounts), but omits crucial mutation details like failure modes, transaction confirmation timing, cost attribution, or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences with zero redundancy. Front-loaded with pattern ('Declarative'), followed by mechanism ('Checks... purchases'), and prerequisite ('Auth required'). Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter blockchain mutation tool with no output schema, the description adequately explains the provisioning logic but lacks disclosure around return values, error states, or asynchronous completion behavior that would help an agent handle the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (target_address, energy_minimum, bandwidth_minimum, duration_sec), establishing baseline 3. The description mentions 'target address' and implies the minimums are thresholds, but adds no additional syntax guidance, format details, or examples beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Declarative resource provisioning' and clarifies the mechanism ('Checks current resources... purchases only what is missing'), distinguishing it from simple check or buy operations. It identifies the resource type (energy/bandwidth implied by parameters) and action, though it doesn't explicitly name sibling contrasts like check_address_resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Auth required' indicating a prerequisite, but lacks explicit when-to-use guidance relative to siblings (e.g., when to use check_address_resources vs this tool) or when not to use (e.g., insufficient TRX balance scenarios).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully notes the auth requirement but does not confirm the read-only nature of the operation, disclose rate limits, or describe what data structure is returned (e.g., single provider vs list with prices).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two efficient sentences. The primary purpose appears first, followed by the auth note. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple 2-parameter tool, but lacks description of the return value (critical given no output schema exists) and does not mention the default behavior when optional 'amount' is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema adequately documents 'resource' and 'amount'. The description references both parameters ('resource and amount') but adds minimal semantic meaning beyond the schema's existing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Find') and scope ('cheapest provider for a given resource and amount'). Identifies specific commodities (ENERGY, BANDWIDTH). However, does not explicitly differentiate from siblings like 'compare_providers' or 'get_prices', which also involve price analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one usage constraint ('No auth required') which is helpful context. However, lacks explicit guidance on when to use this versus alternatives like 'compare_providers' or 'list_providers', or when the optional 'amount' parameter should be included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It successfully communicates the auth-less nature of the call and implies speed ('Quick'), but fails to disclose error behaviors, rate limits, or what happens with invalid addresses. Missing return value description given no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-sentence structure. Front-loads the core purpose ('Quick TRX balance') and follows with the critical behavioral note ('No auth required'). Zero redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool with complete schema coverage, but falls short of full completeness due to missing description of return values (critical for a balance query) and lack of error handling context. The 'No auth required' partially compensates for missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% ('TRON address (T...)'), establishing a baseline of 3. The description mentions 'TRON address' but adds no semantic detail beyond the schema regarding format, validation rules, or example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the resource (TRX balance) and target (TRON address). Specifies 'TRX' which distinguishes it from sibling get_trc20_balance, though it could explicitly mention this retrieves native TRX (not tokens) to strengthen differentiation from get_trc20_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one explicit usage constraint ('No auth required'), which is valuable for a blockchain tool. However, lacks explicit when-to-use guidance versus siblings like get_balance or get_account_info, and doesn't mention what format the balance is returned in.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully communicates the authentication model (no auth required) but omits other behavioral traits like rate limits, return format, error handling for invalid addresses, or pagination behavior beyond the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste: the first establishes purpose and scope, the second provides the authentication note. It is appropriately front-loaded and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter query tool without output schema, the description covers the essentials (purpose, auth). However, given the critical sibling naming collision with 'get_transaction_history', the description is incomplete without clarifying the distinction between these tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (address, type, limit all documented), establishing a baseline score of 3. The description mentions 'TRON address' aligning with the required parameter but does not add semantic context beyond what the schema already provides for the type filter or limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'on-chain transaction history for a TRON address' with a specific verb and resource. However, it fails to distinguish from the sibling tool 'get_transaction_history', leaving ambiguity about when to choose this variant over the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'No auth required,' providing a usage constraint. However, it lacks explicit guidance on when to use this tool versus the similar 'get_transaction_history' sibling, or any prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It mentions the 'MERX_API_KEY' requirement, but critically omits that this is a destructive, irreversible financial operation with potential for permanent loss if the address is incorrect, lacks fee disclosure, and does not mention confirmation times or async behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. The first sentence front-loads the core action and entities, while the second states the critical auth requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a high-stakes financial mutation tool with no annotations or output schema, the description covers the essential what, where, and auth requirements. However, it exhibits clear gaps regarding operational risks, failure modes, and financial safety considerations that would be necessary for an agent to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The main description mentions both currency options ('TRX or USDT'), which helps clarify the intent despite the parameter being named amount_trx, but does not add syntax details, validation rules, or format examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Withdraw'), resources ('TRX or USDT'), and scope ('from your Merx account to an external TRON address'). This effectively distinguishes the tool from siblings like deposit_trx (incoming) and transfer_trx (likely on-chain or internal transfers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit context by specifying the direction (Merx account to external address), which helps identify when to use it. However, it lacks explicit guidance on when to choose this over transfer_trc20/transfer_trx, prerequisites beyond the API key, or warnings about irreversible operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It successfully indicates persistence (distinguishing from ephemeral operations) and authentication requirements, but omits lifecycle details (how to delete/disable), trigger behavior specifics, or reversibility notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-sentence structure. Every element is high-signal: the verb+resource, the parenthetical type enumeration, and the auth prerequisite. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (4 params, nested objects) and lack of annotations/output schema, the description covers the core creation purpose but has gaps around expected return values (e.g., monitor ID), error conditions, and lifecycle management (how monitors are stopped or expire).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by translating the enum values of monitor_type (delegation_expiry, balance_threshold, price_alert) into readable business terms (delegation expiry, balance, price alert) and implying the alert nature of the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Create) and resource (persistent monitor), and specifically enumerates the three supported monitor types (delegation expiry, balance, price alert) in parentheses, which distinguishes this from generic monitoring or analysis tools in the sibling list like analyze_prices or get_price_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a critical prerequisite ('Auth required'), but lacks explicit guidance on when to choose this over one-time checks (like get_balance) or how it relates to sibling list_monitors. The listing of monitor types offers implied usage context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully indicates the payment model ('x402 pay-per-use') and authentication requirements ('TRON_PRIVATE_KEY'), but omits critical operational details such as whether the operation spends funds immediately, error handling, idempotency, or return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first front-loads purpose and mechanism, while the second states prerequisites. Every word earns its place with no redundancy or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the existence of similar sibling tools (create_order, create_standing_order), the description should explicitly differentiate usage scenarios. It mentions the 'zero-registration' characteristic but does not explain the trade-offs or outcomes compared to alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by documenting an implicit requirement ('TRON_PRIVATE_KEY') not present in the input schema, alerting the agent to necessary environment configuration. However, it does not elaborate on parameter formats or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('zero-registration order') with specific protocol context ('x402 pay-per-use'). However, while 'zero-registration' implicitly distinguishes this from sibling 'create_order', it does not explicitly name the alternative or clarify when to choose between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies a critical prerequisite ('Requires TRON_PRIVATE_KEY'), which helps the agent understand setup requirements. However, it fails to provide explicit guidance on when to use this tool versus siblings like 'create_order' or 'create_standing_order'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates the authentication requirement (a key behavioral trait), but omits other behavioral details such as whether the explanation is static or dynamic, output length/format, or idempotency characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two highly efficient sentences. The first establishes core purpose (explain concepts); the second provides critical operational context (no auth required). Every word earns its place with zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, no nested objects), full schema coverage, and lack of output schema, the description is sufficiently complete. The mention of authentication requirements covers the essential safety context, though explicitly stating 'read-only' would further improve completeness given the absence of destructiveHint annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the 'topic' parameter includes a detailed description enumerating valid values like 'energy, bandwidth, staking'). The description adds no supplementary parameter guidance beyond what the schema provides, warranting the baseline score of 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Explain') and resource ('TRON or Merx concept') that clearly identifies this as an educational tool. While it implicitly distinguishes itself from operational siblings like 'transfer_trx' or 'execute_swap' by nature of being informational rather than transactional, it lacks explicit differentiation language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes valuable usage guidance via 'No authentication required,' which is critical context in a blockchain toolset where most operations require keys. However, it lacks explicit when-to-use guidance versus analytical tools like 'analyze_prices' or 'get_account_info' that might also provide explanatory context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It successfully discloses the auth requirement (none needed), which is critical behavioral context. However, it omits other behavioral details such as rate limits, caching behavior, or what happens when an invalid address 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver high information density. The first sentence front-loads the return value specifics (account state components), and the second states the auth requirement. Zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (1 string parameter) and lack of output schema, the description appropriately compensates by enumerating the specific data fields returned (energy, bandwidth, etc.). It meets the minimum viable standard for completeness, though error handling documentation would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the address parameter is fully documented in the schema as 'TRON address (T...)'). Therefore, per the scoring rules, the baseline score is 3. The description adds no additional parameter semantics, but none are required given the complete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns (TRX balance, energy, bandwidth, creation date) and the scope (full on-chain account state), providing specific resource detail. However, it does not explicitly differentiate from siblings like `get_balance` or `get_trx_balance` despite those being available alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'No auth required' provides a usage prerequisite, indicating when the tool can be safely called. However, it lacks explicit guidance on when to choose this over sibling tools like `get_balance` or `get_trx_balance` that return partial data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully notes the MERX_API_KEY requirement (auth behavior) and implies read access via 'Get', but omits output format details, rate limits, and explicit safety confirmation that would be necessary for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence establishes action and scope (including specific currencies); second states prerequisites. Information is front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read operation but has clear gaps: no output schema exists (common for this tool type), and with numerous sibling balance-related tools (get_trx_balance, get_trc20_balance, get_account_info), the description should clarify the specific use case or return structure differences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters justifies the baseline score of 4. The description adds value by noting the MERX_API_KEY requirement, which indicates external configuration is needed despite no input parameters being defined in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and resource 'Merx account balance' with specific assets (TRX, USDT, locked) mentioned. The 'Merx account' and 'locked' status implicitly distinguish it from siblings like get_trx_balance and get_trc20_balance, though explicit contrast would strengthen this to a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the prerequisite 'Requires MERX_API_KEY' which is critical usage context given the empty parameter schema. However, lacks explicit guidance on when to use this versus sibling tools like get_trx_balance, get_trc20_balance, or get_account_info which appear to serve similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully communicates the authentication requirement (none needed) and implies a read-only operation through 'look up,' but omits details about return format, error handling for invalid IDs, or rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two information-dense sentences. The purpose is front-loaded in the first sentence, and the second sentence provides a critical behavioral note. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple, single-parameter lookup tool with full schema coverage. While it lacks an output schema or return value description (which would be ideal), the 'No auth required' note adds necessary context for blockchain operations, making it sufficiently complete for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (tx_id described as 'Transaction ID (hash)'), the baseline score is 3. The description references 'by ID' which aligns with the schema but adds no additional semantic context about the parameter format or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (look up), resource (transaction), and scope (by ID on TRON). The 'by ID' phrasing implicitly distinguishes it from sibling tools like get_transaction_history and search_transaction_history, though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one usage constraint ('No auth required'), which is valuable for blockchain tooling. However, it lacks explicit guidance on when to use this specific tool versus get_transaction_history or search_transaction_history, leaving the agent to infer based on the 'by ID' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully identifies the external data source (CoinGecko) and authentication requirements (none), but omits operational details like rate limiting, caching behavior, error modes, or whether the operation is idempotent/read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-sentence structure. Information is front-loaded with the core action, followed by critical operational metadata (auth). Zero extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read operation without an output schema, the description adequately covers the essential context: what it returns (TRX price), from where (CoinGecko), and access requirements. Slight gap in not describing the return value format or numeric precision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'currency' parameter is fully documented in the schema with default value noted). The description adds no additional parameter semantics, meeting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides specific verb ('Get'), resource ('current TRX price'), and data source ('from CoinGecko'). The specificity of 'TRX' distinguishes it from generic sibling 'get_token_price', while 'current' distinguishes it from 'get_price_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'No auth required', which provides one usage constraint, but fails to explicitly state when to use this tool versus siblings like 'get_token_price' (which could also fetch TRX) or 'get_prices'. No prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully conveys the authentication requirements (none), but omits other behavioral details such as whether this performs external API calls, has rate limits, or what format the recommendation takes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two sentences with no redundancy. The primary purpose appears in the first sentence, while the second sentence provides critical operational context (authentication), making it appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, one optional, no output schema), the description adequately covers the essential information needed for invocation. It successfully identifies the tool's advisory nature and security requirements, though specifying the return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, establishing a baseline of 3. The description adds minimal semantic context beyond the schema, merely referencing 'your use case' which aligns with the use_case parameter but doesn't explain the optional transaction_count parameter's role in the calculation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (recommend) and resource (rental duration), and the context of sibling tools (ensure_resources, calculate_savings) clarifies this relates to blockchain resource rental. However, it could explicitly specify 'energy/bandwidth rental duration' to remove any ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'No authentication required,' which provides useful context about when the tool can be called. However, it lacks explicit guidance on when to use this advisory tool versus execution alternatives like ensure_resources or create_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses 'No authentication required' (a key behavioral trait), but omits other critical behavioral context like whether the calculation is deterministic, rate limits, or what the return value contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient: two declarative statements with zero redundancy. The purpose is front-loaded and the auth note provides essential context without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage for 2 simple parameters, the input side is well-covered. However, lacking an output schema and annotations, the description should ideally disclose what the calculation returns (amount, percentage, breakdown) and whether the operation has any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds no explicit parameter semantics, though the schema already fully documents the 'operation' enum values and 'transaction_count' defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Calculate') and clearly defines the resource ('savings from renting energy vs burning TRX'), distinguishing it from siblings like 'estimate_transaction_cost' (which estimates cost) and 'compare_providers' (which compares providers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (comparing energy rental vs TRX burning costs) but provides no explicit guidance on when to choose this over 'estimate_transaction_cost' or prerequisites for the calculation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses 'No auth required' which is critical behavioral context. However, lacks disclosure of error handling (what happens with invalid addresses), return format structure, or rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with zero waste. Front-loaded with action verb, immediately followed by format specifics and auth status. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for input explanation given single-parameter simplicity. However, lacking output schema, the description omits what the tool returns (converted string? object with both formats?), which would be necessary for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with format examples (T..., 41...). Description reinforces these format patterns but does not add syntax details, validation rules, or semantic constraints beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (convert), resource (TRON address), and scope (base58 T... vs hex 41... formats). Distinguishes from siblings like validate_address (which only checks validity) and get_account_info (which retrieves data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'No auth required' which provides prerequisite guidance, but lacks explicit when-to-use distinctions from similar tools like validate_address or guidance on bidirectional conversion preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses authentication requirements. However, it lacks details on irreversibility, confirmation times, or return values for this financial operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no redundancy. Information is front-loaded with the action first, followed by prerequisites. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter operation, covering core intent and auth. However, gaps remain regarding the return structure, synchronous/asynchronous behavior, and amount formatting specifics given this is a financial transaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter already described as 'Amount of TRX to deposit'. The tool description adds no additional parameter-specific semantics (e.g., unit format, decimal precision), warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Deposit), resource (TRX), and destination (Merx account), distinguishing it from sibling tools like transfer_trx or withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states authentication prerequisites (MERX_API_KEY + TRON_PRIVATE_KEY), but lacks guidance on when to use this tool versus alternatives like transfer_trx or enable_auto_deposit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates the authentication requirement (none needed), but omits details about return format, pagination, rate limiting, or whether the comparison is real-time versus cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence front-loads the core function; second sentence provides critical prerequisite info. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with complete schema coverage, the description adequately covers the essential context. Mentions key output data (prices, availability) despite lack of output schema, though explicit return structure would strengthen completeness further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for the single 'resource' parameter. The description does not add parameter-specific semantics, which is acceptable given the high schema coverage establishes the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb phrase 'Side-by-side provider comparison' that clearly identifies the operation and resource. Distinguishes from sibling list_providers by emphasizing comparative analysis and specific data points (prices and availability).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides useful prerequisite guidance ('No auth required') indicating when the tool is accessible, but lacks explicit differentiation from siblings like list_providers or analyze_prices regarding when to choose this comparison approach over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It successfully adds the rental vs burn comparison behavior and the no-auth requirement. However, it omits critical safety context: it doesn't explicitly state whether this executes the call or is purely simulative, and provides no hint about return value structure or rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose declaration, behavioral detail (rental/burn comparison), and usage constraint (no auth). Perfectly front-loaded with the core action in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a 4-parameter estimation tool with full schema coverage. Addresses the core value proposition (cost estimation with comparison) and prerequisites. Minor deduction for lacking return value description given no output schema exists, though 'Estimate... cost' provides reasonable expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with clear type hints (e.g., 'ABI-encoded parameter hex'). The description adds no additional parameter semantics, but the baseline 3 is appropriate when the schema already fully documents all 4 parameters including optional/required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Estimate' with clear resource targets (energy and bandwidth cost) and scope (smart contract call). The mention of 'rental vs burn cost' distinguishes this from generic estimation tools like estimate_transaction_cost or simulate, clearly positioning it within the TRON resource model context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one explicit usage constraint ('No auth required'), which helps determine prerequisites. However, lacks explicit guidance on when to use this versus siblings like call_contract (execution vs estimation) or simulate, though the 'Estimate' verb partially implies read-only simulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full behavioral burden. It successfully discloses 'No auth required' but fails to confirm read-only safety, describe what specific block data is returned, or mention rate limits/idempotency for this blockchain operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Main action 'Get TRON block info by number' is front-loaded, followed by parameter optionality and auth requirements. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-parameter tool without output schema. Covers core function, optional parameter behavior, and auth requirements. Could be improved by briefly characterizing what 'block info' includes or confirming the read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (parameter fully described as 'Block number. Omit for latest'), establishing baseline 3. Description adds domain context 'TRON' but largely restates the optional parameter behavior already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with resource 'TRON block info' and parameter context 'by number', clearly distinguishing it from sibling tools like get_transaction, get_account_info, or get_balance which handle transactions, accounts, and balances respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides parameter usage guidance '(or latest if omitted)' and prerequisite 'No auth required', but lacks explicit guidance on when to use this tool vs. alternatives like get_transaction or get_transaction_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully communicates the authentication requirement ('No auth required') and implicitly suggests read-only behavior via 'Get' and the field list. However, it omits explicit safety confirmation (e.g., 'read-only'), error handling behavior, or rate limit warnings that would fully compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero waste. First sentence front-loads the action and scope, followed by the specific metadata fields returned. Second sentence provides critical operational context (auth requirements). Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple single-parameter lookup tool. The description compensates for the missing output schema by listing the four return fields. Could be improved by explicitly stating the tool is read-only/safe and noting error cases (e.g., invalid token), but adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter fully documented in the schema ('Token symbol or contract address'). The description adds no additional parameter guidance, but meets the baseline expectation when the schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Get' is a precise verb, 'TRC-20 token metadata' identifies the exact resource type, and listing the four fields (name, symbol, decimals, total supply) clearly distinguishes this from sibling tools like get_token_price (which returns prices) and get_trc20_balance (which returns wallet balances).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides the usage condition 'No auth required,' which helps determine when the tool is accessible (vs. authenticated alternatives). However, it lacks explicit comparison to siblings like get_token_price or get_trc20_balance to clarify when to use metadata retrieval versus price or balance queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries disclosure burden. Adds 'No auth required' (access constraint) and 'check on-chain status' (indicates blockchain query), though could clarify what specific on-chain status means (exists, activated, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundant content; first establishes purpose, second provides auth context. Efficiently structured with critical information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter validation tool without output schema, description adequately covers primary function and operational constraints. Mention of 'on-chain status' hints at return value meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the single 'address' parameter. Description does not add semantic details, syntax examples, or format specifications beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Validate a TRON address format' provides specific verb and resource, while 'check on-chain status' distinguishes from simple format validation or conversion tools like convert_address. The scope is clearly defined against sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'No auth required' indicating it can be used without credentials, but lacks explicit comparison to siblings like check_address_resources or convert_address. No 'when-not-to-use' or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds critical safety context: 'Signs and broadcasts on-chain' indicates permanent state change, and 'Requires TRON_PRIVATE_KEY' warns of credential need. Lacks details on return values, gas costs, or reversibility (can be overridden by subsequent approvals).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste. Front-loaded with action ('Approve...'), followed by behavioral trait ('Signs...'), then prerequisite ('Requires...'). Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic invocation but incomplete for a financial mutation tool: missing return value description (transaction hash?), gas fee implications, and reversibility notes. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description term 'spending allowance' conceptually maps to the parameters (token, spender, amount) but adds no syntax, format, or example details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Approve' with clear resource 'TRC-20 spending allowance'. Distinct from sibling 'transfer_trc20' (which moves tokens) and 'get_trc20_balance' (read-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides critical prerequisite ('Requires TRON_PRIVATE_KEY') but lacks explicit when-to-use guidance vs alternatives (e.g., when to approve vs immediate transfer, or that this is typically needed before execute_swap). Usage is implied by 'spending allowance' terminology.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Successfully discloses key behaviors: comparison logic ('rental vs burn cost') and auth requirements. Missing return value format and rate limit information, but covers the critical domain-specific behavior (TRON's dual resource model).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste. Front-loaded with core purpose (estimation), followed by distinguishing behavioral detail (rental/burn comparison), ending with operational constraint (auth). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 8 parameters with conditional requirements (custom operation needs contract_address/function_selector) and no output schema. Description omits conditional parameter logic and return structure. Adequate for basic usage but gaps remain for complex 'custom' operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (all 8 params documented). Description does not add parameter semantics beyond schema, which is acceptable given the high coverage. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Estimate' plus clear resource 'energy and bandwidth cost for a TRON transaction'. Distinguishes from execution siblings (transfer_trx, transfer_trc20) by being estimation-focused, and differentiates from estimate_contract_call by targeting general transactions rather than specific contract calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit auth guidance ('No auth required'), which helps determine when it can be called safely. However, lacks explicit differentiation from similar estimation sibling estimate_contract_call or guidance on when to use 'custom' vs predefined operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries the burden. It discloses the public/unauthenticated nature ('No auth required') but omits other behavioral traits like rate limits, error handling for invalid addresses, or return value format. Adequate but minimal for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. Front-loaded with purpose ('Get TRC-20...'), followed by input flexibility, then authentication status. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple 2-parameter tool with no output schema. Description lacks return value specification (e.g., whether it returns raw or formatted amounts, decimals), which is a notable gap given the absence of an output schema. Otherwise covers the essential invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline applies. Description repeats the schema's content about supporting symbols (USDT, USDC) or contract addresses, adding no new semantic meaning or format guidance beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' with specific resource 'TRC-20 token balance' and scope 'for an address'. Explicitly names the token standard, distinguishing it from siblings like get_trx_balance (native TRX) and get_balance (likely general/native).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'No auth required', which is a critical usage constraint distinguishing it from mutation tools (transfer_trc20, approve_trc20) that likely require authentication. Lacks explicit 'when to use vs get_token_info' comparison, but resource specificity makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behaviors: on-chain commitment ('broadcasts on-chain'), authorization requirement ('Requires TRON_PRIVATE_KEY'), and implementation detail ('automatic energy optimization'). Missing failure modes, idempotency, or return value description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste. Front-loaded with primary action, followed by behavioral disclosure, then authorization requirement. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and description omits return value format (transaction hash, receipt status). While authorization and on-chain effects are disclosed, a blockchain transaction tool should ideally indicate successful completion indicators or returned identifiers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (all 3 parameters documented). Description adds no additional parameter semantics beyond schema (e.g., no format examples for 'human-readable' amounts or address validation rules), meeting baseline expectations for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Transfer' + resource 'TRC-20 tokens' clearly identifies the operation. Distinguishes from sibling 'transfer_trx' by explicitly naming the TRC-20 token standard, and from 'approve_trc20' by specifying the transfer action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States prerequisite 'Requires TRON_PRIVATE_KEY' but lacks explicit when-to-use guidance versus alternatives (e.g., distinguishing when to use this vs 'transfer_trx' for native currency or vs 'approve_trc20' for allowances). Usage constraints are implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It reveals the operation generates an API key and retrieves deposit info (side effects/outputs), and the 'No auth needed' disclosure is crucial behavioral context. However, it omits error handling (e.g., duplicate email), idempotency, or rate limit details expected for an account creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with the primary action (account creation), followed by secondary outputs (API key, deposit info), and closes with the critical constraint (no auth needed). Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially compensates by disclosing that the operation returns/generates an API key and deposit info. With 100% schema coverage and simple parameter structure, this is sufficient context, though error scenarios remain undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing baseline 3. The description implies email/password are for the new account but does not add parameter-specific semantics beyond the schema (e.g., password requirements, email validation rules) or explain the parameter relationship to the generated API key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Create' with resource 'Merx account' and distinguishes from siblings like 'login' (existing auth) and 'set_api_key' (configuring existing credentials). The additional clauses about generating an API key and getting deposit info clarify the full scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'No auth needed' clause provides critical contextual guidance distinguishing this from most sibling tools that likely require authentication. However, it lacks explicit guidance on when to use this versus 'login' (e.g., 'for new users only').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full disclosure burden. It successfully communicates the authentication requirement (none needed), which is critical behavioral context. However, it omits other potentially relevant behaviors such as data freshness (cached vs. live), rate limits, or the specific structure of the Merx comparison in the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-sentence structure. First sentence establishes purpose with examples; second sentence states the auth policy. No redundant words or tautologies. Information is front-loaded with the core action before qualifying details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a zero-parameter read-only tool. Covers the essential what (network parameters), context (Merx comparison), and operational requirement (no auth). Lacks output description, but for a simple getter without an output schema defined, the description provides sufficient orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters, triggering the baseline score of 4 per evaluation rules. No parameters exist requiring semantic clarification beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Get' is a clear verb, 'TRON network parameters' identifies the resource, and concrete examples (energy fee, bandwidth cost) clarify scope. The 'Merx price comparison' clause distinguishes it from sibling tools like get_prices or compare_providers which focus on token trading rather than network resource costs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one key usage constraint ('No auth required'), which helps identify when this tool is appropriate versus authenticated siblings like transfer_trx or execute_swap. However, lacks explicit guidance on when to prefer this over similar analytical tools like estimate_transaction_cost or compare_providers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully communicates authentication requirements and return data structure (types, durations, availability). However, it omits other behavioral traits like pagination behavior, rate limiting, or whether the data is cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two highly efficient sentences. The first covers purpose and return value; the second covers authentication requirements. There is no redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without an output schema, the description adequately covers the essential context: what the tool does, what data it returns, and its security requirements. It could be improved by mentioning pagination behavior or explicit differentiation from the compare_providers sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, establishing a baseline score of 4 per the rubric. The description appropriately does not invent parameter semantics where none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (List), resource (Merx providers), scope (all), and the specific data returned (types, durations, availability). This distinguishes it from siblings like compare_providers which would focus on analysis rather than enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'No authentication required,' which provides prerequisite guidance. However, it lacks explicit guidance on when to use this versus siblings like compare_providers or get_best_price, and does not specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It successfully communicates the non-mutative nature ('without executing') and output type ('resource estimates and costs'), but lacks details on validation depth (does it check step syntax?), error handling for invalid steps, or whether simulation consumes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two high-value sentences with zero redundancy. The first sentence front-loads the core mechanism (simulation without execution), and the second specifies the return value. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage and lack of output schema, the description adequately covers the tool's purpose and return type ('resource estimates and costs'). It appropriately omits low-level parameter details already covered by the schema. A minor gap is the lack of detail on output structure or validation behavior, but this is sufficient for a 2-parameter preview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage ('Array of { action, params }', 'Resource acquisition strategy'), establishing a baseline of 3. The description mentions 'multi-step operation' and 'resource estimates' which loosely map to the 'steps' and 'resource_strategy' parameters but adds no syntax details, format examples, or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Simulate') with a clear resource ('multi-step operation') and explicitly distinguishes itself from execution-focused siblings like 'execute_swap' and 'execute_intent' via 'without executing.' It also previews the return value ('resource estimates and costs'), clearly positioning the tool in the validation/dry-run category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without executing' provides clear context for when to use this tool (dry-run/pre-validation) versus the many execution-oriented siblings (create_order, transfer_trx, execute_intent). However, it does not explicitly map to specific alternatives or state prerequisites (e.g., 'use this before execute_swap').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description effectively covers behavioral traits: declares state-changing nature, discloses automatic resource estimation/acquisition via Merx, and specifies auth requirements ('Requires TRON_PRIVATE_KEY and TRON_ADDRESS'). Missing explicit failure modes or confirmation waiting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with zero waste: 1) Core purpose, 2) Automatic resource behavior, 3) Prerequisites. Each sentence earns its place and builds necessary context without redundancy. Excellent front-loading of primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers execution behavior and auth well, but lacks description of return values or transaction confirmation semantics. For a state-changing blockchain tool without output schema, description should indicate whether it returns tx hashes, receipts, or confirmation status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline applies. Description does not add parameter semantics beyond schema (e.g., no examples of ABI-encoding format or guidance on optional vs required context), but schema adequately documents the four parameters including hex encoding note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states specific action ('Execute a state-changing smart contract function') that distinguishes it from sibling tool 'read_contract'. The 'state-changing' modifier explicitly signals this is a write operation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context by specifying 'state-changing' (use when modifying state vs reading), and mentions automatic resource handling ('Estimates resources, buys via Merx if needed'). Could be improved by explicitly contrasting with 'read_contract' or stating when NOT to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the critical behavioral trait that no authentication is required. It implies read-only behavior via 'view/pure', though it could add context about return formats or node query behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with the action ('Call a view/pure function'), followed by scope ('on a TRON smart contract'), then critical behavioral constraint ('No auth or private key required'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema exists, the description should ideally specify what gets returned (raw hex vs decoded values). While 'view/pure' implies a return value, the format remains ambiguous. The auth clarification compensates partially for missing annotations, but return value documentation is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions including examples (e.g., 'balanceOf(address)'). The description adds no parameter-specific semantics beyond the schema, which is appropriate when schema coverage is complete. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'Call a view/pure function on a TRON smart contract' - clear verb, specific resource, and distinguishes from sibling 'call_contract' by specifying 'view/pure' functions only. The 'No auth' clause further clarifies this is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'No auth or private key required' provides implicit guidance to use this for read-only operations versus state-changing alternatives. However, it doesn't explicitly reference sibling 'call_contract' or state when to prefer this over other query tools like 'get_balance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behavioral traits: session-scoped storage ('for this session') and side effects ('Unlocks all authenticated tools'). Missing details on whether this overwrites existing keys or security/storage guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: action (sentence 1), effect (sentence 2), prerequisite (sentence 3). Front-loaded with purpose. No redundancy with structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for an authentication setup tool with many dependent siblings. Explains unlocking capability sufficiently. No output schema present but unnecessary for a setter; however, lacks mention of validation errors or overwrite behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage ('Your Merx API key (starts with sk_live_)'). Description adds prerequisite context ('if you already have an API key') but doesn't add format guidance beyond schema's sk_live_ prefix. Baseline 3 appropriate when schema does heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity with 'Set your Merx API key' (verb + resource) plus session scope 'for this session'. Clearly distinguishes from sibling 'set_private_key' by specifying 'Merx API key' and listing unlocked categories (trading, balance, orders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite 'Use this if you already have an API key' implying when to use. Lacks explicit contrast with sibling 'set_private_key' (wallet key vs API key) which would prevent confusion given both set credentials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses critical behaviors: session-scoped storage, automatic address derivation, and the security guarantee that the key stays local and is never sent to Merx servers. It could improve by mentioning validation behavior or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences covering purpose, side effects (address derivation), enabled capabilities, and security guarantees. Every sentence earns its place with zero redundancy. Information is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (cryptographic key handling) and lack of annotations/output schema, the description provides adequate behavioral context and security disclosures. Minor gap: does not describe return values or confirmation behavior, though the side effects are well-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage ('Your TRON private key (64 hex characters)'). The description adds no additional parameter-specific guidance beyond what the schema already provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Set), resource (TRON private key), and scope (for this session). It distinguishes from sibling 'set_api_key' by specifying 'TRON private key' and distinguishes from read operations by listing specific write tools it enables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly lists the write tools this enables (transfer_trx, transfer_trc20, etc.), providing clear context for when to use it. However, it lacks explicit 'when not to use' guidance or comparison to alternatives like set_api_key for authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and effectively reveals the on-chain nature ('Signs and broadcasts on-chain'), side effects (bandwidth checks, potential Merx purchases), and authentication requirements. Missing only failure modes and rate limit disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four declarative sentences, front-loaded with the primary action. Every clause adds unique behavioral or prerequisite information without repetition, making it information-dense yet readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema and annotations, the description adequately covers the execution flow, preconditions, and on-chain effects for a blockchain transfer operation. Would benefit from mentioning the return value (e.g., transaction hash) but sufficiently complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for both parameters (to_address, amount_trx), meeting the baseline expectation. However, the description fails to clarify critical semantics like whether amount_trx expects TRX units or smallest decimal units (sun), which is vital for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately specifies the exact action (Send), resource (TRX), and target (address), distinguishing it clearly from sibling tools like transfer_trc20 (which handles TRC20 tokens) and deposit_trx (which implies receiving funds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the critical prerequisite 'Requires TRON_PRIVATE_KEY' and describes the automatic resource management behavior ('Checks bandwidth, buys via Merx if needed'). However, it lacks explicit differentiation from transfer_trc20 for users deciding between native TRX and token transfers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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