MERX - TRON Resource Exchange

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

Annotations already declare read-only/idempotent safety properties. The description adds value by disclosing what status information is returned ('active receives, watches, invoices'), compensating partially for the missing output schema. However, it doesn't explain what 'active' means or failure modes.

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

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

Extremely concise at nine words with information front-loaded. The single sentence efficiently conveys purpose and return content. Minor deduction for slight grammatical ambiguity in 'active receives' parsing.

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

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

For a zero-parameter tool, the description adequately indicates return content (receives, watches, invoices) to compensate for missing output schema. However, it lacks context on response structure, caching behavior, or what constitutes 'active' status.

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

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

The input schema has zero parameters, establishing a baseline of 4 per scoring rules. The description correctly implies no configuration is needed to retrieve the general status.

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

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

The description clearly identifies the action ('Get') and resource ('agent payment service status'), and distinguishes this from sibling tools like get_account_info or get_balance by specifying the domain (agent payment service). The colon-separated list clarifies scope, though slightly telegraphic.

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

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

No guidance provided on when to use this versus alternatives like get_account_info or check_address_resources. No prerequisites or conditions mentioned despite the tool likely requiring authentication context.

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

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

While annotations already establish the operation is read-only and idempotent, the description adds valuable behavioral context: the 'No auth required' note clarifies authentication needs, and 'trends and recommendations' discloses the nature of the returned analysis (going beyond raw price data). No contradictions with annotations.

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

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

Two sentences efficiently deliver purpose, output characteristics, and authentication requirements with zero redundancy. Information is front-loaded with the core function first, followed by operational constraints.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is adequately complete. It hints at return values via 'recommendations,' and annotations cover the safety profile. Could benefit from mentioning the resource filter (ENERGY/BANDWIDTH), though this is documented in the schema.

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

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

With 100% schema description coverage ('Filter by resource type. Omit for all.'), the schema fully documents the single optional parameter. The description adds no parameter-specific semantics, meeting the baseline expectation for high-coverage schemas.

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

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

The description clearly states the tool performs 'Market price analysis' and produces 'trends and recommendations,' adding specificity beyond the tool name. However, it does not explicitly differentiate from siblings like 'get_prices' or 'get_price_history' which suggests this tool provides analytical insights rather than raw data retrieval.

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

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

The description provides one usage constraint ('No auth required'), which is helpful for invocation planning. However, it lacks explicit guidance on when to use this analytical tool versus simpler retrieval alternatives like 'get_prices' or 'get_price_history' in the sibling list.

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

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

While annotations declare destructiveHint=true, the description adds critical behavioral details: the requirement for a private key and the fact that it signs and broadcasts transactions on-chain. It does not contradict annotations, though it could further clarify gas/energy costs or 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.

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

The description consists of three sentences, each earning its place: purpose declaration, behavioral mechanism, and authentication requirement. It is appropriately front-loaded and free of fluff.

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

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

Given this is a destructive financial operation with no output schema, the description is minimally viable but incomplete. It omits what the tool returns (e.g., transaction hash), error conditions, and cost implications (energy/bandwidth usage), which are important for blockchain transaction tools.

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

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

The input schema has 100% description coverage (token, spender, amount are fully documented). The tool description adds no additional parameter-specific semantics, meeting the baseline expectation for well-schematized tools.

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

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

The description uses a specific verb ('Approve') and resource ('TRC-20 spending allowance'), clearly distinguishing it from sibling tools like 'transfer_trc20' or 'execute_swap'. It precisely identifies the ERC-20/TRC-20 approval pattern.

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

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

The description provides clear prerequisites ('Requires TRON_PRIVATE_KEY') and behavioral context ('Signs and broadcasts on-chain'), which help determine when the tool is applicable. However, it lacks explicit guidance on when to use this versus alternatives or specific scenarios (e.g., 'use before executing a swap').

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

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

While annotations confirm the operation is read-only, idempotent, and non-destructive, the description adds valuable behavioral context regarding authentication requirements ('No authentication required'). This disclosure is crucial for agent planning and is not captured in the structured annotations.

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

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

The description consists of two efficient sentences with zero redundancy. It front-loads the core purpose and follows with the authentication note, making every word earn its place.

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

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

For a calculation utility with 2 parameters and strong annotations, the description is sufficiently complete. It could be improved by briefly describing what the calculation returns (e.g., estimated TRX savings), but given the tool's focused scope and the absence of an output schema to reference, the current description adequately supports agent decision-making.

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

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

With 100% schema description coverage, the input parameters ('operation' and 'transaction_count') are fully documented in the JSON schema. The description does not add parameter-specific semantics, but given the high schema coverage, it meets the baseline expectation without penalty.

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

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

The description provides a specific verb ('Calculate') and a precise resource/context ('savings from renting energy vs burning TRX'). It clearly distinguishes this tool from siblings like 'estimate_transaction_cost' (which estimates transaction fees) and 'analyze_prices' (which analyzes market prices) by focusing specifically on the cost comparison between renting energy and burning TRX on the TRON network.

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

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

The description includes one usage constraint ('No authentication required'), which helps the agent understand prerequisites. However, it lacks explicit guidance on when to use this tool versus similar estimation or analysis tools like 'estimate_transaction_cost' or 'compare_providers', leaving the agent to infer the specific use case.

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

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

The description adds valuable behavioral context beyond annotations: it discloses automatic resource estimation ('Estimates resources'), automatic resource acquisition ('buys via Merx if needed'), and authentication requirements. Annotations already mark this as destructive/non-readonly, so the description's value lies in explaining the resource-management side effects and auth prerequisites.

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

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

Three sentences, each serving a distinct purpose: (1) core action, (2) side effects/resource handling, (3) prerequisites. No redundant words or tautologies. Information is front-loaded with the critical 'state-changing' distinction in the first phrase.

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

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

Given the complexity of blockchain contract interactions, the description adequately covers the execution behavior, resource management, and authentication needs. However, it omits what the tool returns (e.g., transaction hash or receipt) despite having no output schema, which would be helpful for an agent determining how to handle the response.

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

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

With 100% schema description coverage, the input parameters (contract_address, function_selector, parameter, call_value_trx) are fully documented in the schema itself. The description does not add semantic details beyond the schema, meeting the baseline expectation for high-coverage schemas.

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

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

The description explicitly states 'Execute a state-changing smart contract function' — providing a specific verb (execute), resource (smart contract function), and critical distinguishing attribute (state-changing). This clearly differentiates it from the sibling tool 'read_contract' and signals that this performs writes, not reads.

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

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

The description implies usage through the 'state-changing' qualifier and mentions prerequisites (TRON_PRIVATE_KEY, TRON_ADDRESS), but lacks explicit guidance on when to use alternatives like 'read_contract' for view functions or 'estimate_contract_call' for dry runs. The agent must infer the appropriate use case from the 'state-changing' keyword alone.

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

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

With no annotations provided, the description carries full disclosure burden. It successfully discloses the authentication requirement and the behavioral effect ('stops firing notifications'). However, it omits whether the cancellation is permanent/destructive or reversible, and doesn't mention error conditions if the monitor is already inactive.

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

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

Three sentences with zero waste: purpose declaration, behavioral effect, and auth requirement. Information is front-loaded and each sentence earns its place without redundancy.

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

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

For a single-parameter mutation tool with no output schema and no annotations, the description is sufficiently complete. It covers the action, immediate consequence (notification cessation), and security requirement. It could optionally clarify the relationship to 'list_monitors' for lookup or note irreversibility, but covers essential ground.

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

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

Input schema has 100% coverage (monitor_id described as 'Monitor UUID to cancel'), establishing a baseline of 3. The description reinforces this by mentioning 'by its UUID', adding contextual alignment but no additional syntax details, constraints, or format guidance beyond the schema.

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

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

The description clearly states the specific action (Cancel), the target resource (active monitor), and the identifying mechanism (by its UUID). It effectively distinguishes itself from sibling 'create_monitor' and read-only tools like 'list_monitors' through the explicit 'Cancel' verb.

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

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

The description implies usage constraints by specifying 'active monitor' (suggesting not to use on inactive monitors) and states the auth prerequisite (API key). However, it lacks explicit guidance on when to prefer this over other termination methods or prerequisites beyond authentication.

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

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

With no annotations provided, the description carries full disclosure burden. It explicitly states the state change (moved to CANCELLED), future scheduling prevention, irreversible nature of past actions, and authentication requirements (API key). Excellent coverage of mutation side effects and prerequisites.

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

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

Four sentences logically ordered: purpose (cancel by UUID), effect (status change/triggering), limitation (past actions not reversed), and requirement (auth). Every sentence delivers critical information with zero redundancy or waste.

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

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

For a single-parameter mutation tool without output schema or annotations, the description is complete. It covers purpose, side effects, irreversibility constraints, and auth prerequisites. No gaps remain that would impede correct invocation.

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

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

Input schema has 100% coverage (order_id described as 'Standing order UUID to cancel'). The description mentions 'by its UUID' but does not add semantic meaning, syntax details, or format constraints beyond what the schema already provides. Baseline 3 is appropriate when schema documentation is complete.

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

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

Description uses specific verb 'Cancel' with resource 'standing order' and identifies the key (UUID). Clearly distinguishes from siblings like create_standing_order, get_standing_order, and cancel_monitor by specifying the order resource and cancellation action.

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

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

Provides clear behavioral context stating the order 'will not trigger again' and crucially warns that 'Already-executed actions are NOT reversed,' which guides appropriate use. Lacks explicit naming of sibling alternatives (e.g., vs update_standing_order), but the irreversibility warning effectively guides 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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond these annotations by stating 'No auth required', which is critical for public blockchain queries. It does not disclose rate limits or error handling behavior.

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

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

The description consists of two efficient sentences. The first establishes purpose and scope; the second provides the critical usage constraint about authentication. Every word earns its place with zero redundancy.

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

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

For a simple single-parameter read operation, the description is sufficient. It implicitly describes the return values by listing what is checked (energy, bandwidth, TRX), which compensates for the lack of an output schema. The combination of clear description and comprehensive annotations provides adequate context.

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

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

With 100% schema description coverage (the 'address' parameter is fully documented in the schema as 'TRON address (starts with T)'), the baseline score applies. The description does not add additional parameter semantics, but none are needed given the complete schema.

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

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

The description explicitly states the action ('Check') and the specific resources queried ('energy, bandwidth, and TRX balance') for a 'TRON address'. This distinguishes it from siblings like get_trx_balance (likely TRX-only) or get_account_info (broader account data) by specifying the exact resource types.

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

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

The description provides one usage constraint ('No auth required'), indicating it can be used for public queries without credentials. However, it lacks explicit guidance on when to use this versus similar balance-checking siblings like get_balance or get_account_info.

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

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

Adds authentication requirement ('No auth required') not covered in annotations. However, annotations already declare readOnly/idempotent/destructive hints, and the description omits return format, caching behavior, or rate limits.

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

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

Two sentences with zero waste. Front-loaded with core purpose (comparison), followed by operational note (auth). Perfect information density for a simple tool.

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

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

Adequate for a single-parameter read tool, mentioning key output fields (prices, availability). However, lacks output structure description (no output schema exists) and doesn't reference the ENERGY/BANDWIDTH resource types from the enum.

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

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

Schema has 100% description coverage (resource filter with enum values), establishing baseline 3. Description adds no parameter-specific context, but none is needed given complete schema documentation.

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

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

States specific action (side-by-side comparison) and resource (providers) with key outputs (prices, availability). Distinguishes from list_providers by emphasizing comparative data, though could explicitly contrast with siblings like analyze_prices.

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

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

Mentions 'No auth required' which is a prerequisite, but provides no guidance on when to use this versus alternatives like list_providers or analyze_prices. No filtering guidance beyond the schema.

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

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

Adds critical two-phase behavior (preview default vs execute with apply=true) and discloses what resources are created, both beyond annotations.

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

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

Perfectly front-loaded with action statement, followed by concrete examples demonstrating natural language capabilities, ending with execution instructions; no wasted words.

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

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

Excellent for complexity (NL parsing to automation); explains return behavior despite missing output schema, though could note idempotency implications of repeated calls.

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

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

Schema has 100% description coverage; description reinforces the apply parameter's execution behavior but adds no new semantic information beyond schema.

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

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

Specific verb 'Convert' with clear resource (natural language → MERX automation), explicitly names created resources (standing orders/monitors) distinguishing it from sibling create_order/create_monitor tools.

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

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

Examples clearly indicate when to use (natural language policies), and explicitly documents the apply=true requirement for execution, though lacks explicit contrast with manual creation alternatives.

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

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

While annotations cover safety (readOnly, idempotent), the description adds crucial behavioral context that authentication is not required—a key distinction for blockchain tools. It also clarifies the bidirectional conversion capability.

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

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

Two sentences with zero waste. The first sentence front-loads the core function with format examples; the second provides essential auth context. No redundancy.

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

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

Adequate for a simple utility with single input and no output schema. Describes the transformation and auth requirements. Minor gap: does not mention return format or error behavior for invalid inputs.

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

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

With 100% schema coverage, the parameter is already well-documented. The description reinforces the format examples but does not add semantic details beyond the schema (e.g., validation rules, auto-detection behavior).

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

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

The description clearly states the specific action (convert), resource (TRON address), and exact format variants (base58 T... vs hex 41...), distinguishing it from validation or transfer siblings.

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

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

The 'No auth required' note provides implicit guidance distinguishing it from key-requiring siblings like transfer_trx, but lacks explicit when-to-use comparisons or alternative recommendations (e.g., vs validate_address).

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

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

While annotations declare idempotency and non-destructive behavior, the description adds critical behavioral context not found in structured fields: the no-authentication requirement and the specific side effects (API key generation and deposit info retrieval). It does not contradict annotations.

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

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

Two sentences with zero waste. The first sentence front-loads the three primary actions; the second delivers the critical auth constraint. Every word earns its place.

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

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

Despite lacking an output schema, the description adequately compensates by specifying what the tool returns (API key, deposit info). Given the 2-parameter input with complete schema coverage and clear annotations, the description provides sufficient context for invocation.

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

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

With 100% schema description coverage, the schema fully documents both parameters (email and password constraints). The description does not add additional parameter semantics beyond what the schema provides, meeting the baseline expectation for high-coverage schemas.

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

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

The description uses specific verbs (Create, generate, get) and clearly identifies the resource (Merx account). It distinguishes itself from siblings like `login`, `set_api_key`, and `get_deposit_info` by explicitly stating it handles new account creation plus initial setup in one call.

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

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

The 'No auth needed' note provides crucial guidance contrasting with `login` (which presumably requires authentication). However, it lacks explicit 'when to use' framing (e.g., 'use this for new users before calling `login`') or prerequisites like email uniqueness requirements.

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

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

Adds critical behavioral details absent from annotations: return values (payment URL, address, QR code) since no output schema exists, and detection mechanism/timing (ZeroMQ, <3 seconds). Does not address idempotency semantics from annotations.

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

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

Two high-density sentences with zero redundancy. First sentence establishes purpose and audience; second covers return values and detection behavior. Perfectly front-loaded with no filler.

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

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

Comprehensive for a payment tool lacking output schema—description compensates by detailing return format and automatic detection. Minor gap regarding error states or expired invoice behavior, but annotations and schema cover safety and input constraints adequately.

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

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

With 100% schema description coverage, the schema fully documents all three parameters (amount_usdt, expires_in, description). The description adds no supplementary parameter semantics, meeting the baseline expectation.

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

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

Specific verb (Create) + resource (invoice) + audience (another agent or human to pay) clearly distinguishes this from sibling pay_invoice and create_order. Explicitly identifies the payment directionality.

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

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

Implies usage context by specifying invoices are created 'for another agent or human to pay,' clarifying this is for receiving payments. Lacks explicit contrast with pay_invoice or request_payment siblings, but directionality provides clear implicit guidance.

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

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

Annotations already disclose idempotency (true) and non-destructive nature (false), so the description's burden is reduced. It adds valuable context beyond annotations by noting 'persistent' (implying long-running background operation) and 'Auth required' (security prerequisite), but omits details about trigger behavior, webhook delivery guarantees, or lifecycle management.

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

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

The description consists of two highly efficient sentences with zero redundancy. The primary action ('Create a persistent monitor') is front-loaded, with parenthetical type enumeration and auth requirements following as essential modifiers. Every word serves a distinct communicative purpose.

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

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

Given the tool's moderate complexity (4 parameters with nested objects) and rich schema coverage, the description provides sufficient high-level context through the auth requirement and persistence mention. However, with no output schema provided, the description could have briefly characterized the creation result (e.g., returning a monitor ID) to be fully complete.

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

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

With 100% schema description coverage, the structured fields already document all four parameters comprehensively. The description mirrors the enum values for monitor_type in prose but adds no additional semantic depth regarding parameter relationships (e.g., that target_address is conditional on monitor_type) or format constraints beyond the schema.

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

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

The description clearly states the core action ('Create a persistent monitor') and enumerates the three specific monitor types supported (delegation expiry, balance, price alert). This effectively distinguishes the tool from sibling 'list_monitors' and other creation tools like 'create_order' by specifying the resource type.

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

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

While the description lists the available monitor types, it provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or conditions for usage. The phrase 'Auth required' hints at setup needs but doesn't clarify selection criteria among the three monitor types or versus other alerting mechanisms.

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

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

The description adds 'Routed to cheapest provider' and 'Auth required' beyond the annotations, which helps clarify the selection logic and security model. However, it misses important behavioral context like the idempotency guarantee (already in annotations), failure modes when no provider meets price constraints, or what the tool returns upon success.

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

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

The description consists of three short, front-loaded sentences with zero redundancy. Every phrase earns its place: the action (Buy), the domain (on Merx), the routing logic, and the auth requirement are all efficiently packed.

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

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

For a 5-parameter purchasing tool with no output schema, the description provides the essential operational context (routing behavior, auth). However, given the financial nature of the operation and available siblings, it could benefit from mentioning order lifecycle or return value structure to be fully complete.

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

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

With 100% schema description coverage, the schema fully documents all parameters including min values and optional fields. The description mentions 'energy or bandwidth' but adds no semantic depth beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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

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

The description clearly states the tool 'Buy[s] energy or bandwidth on Merx' with specific verbs and resources. However, it does not explicitly differentiate from siblings like 'create_paid_order' or 'create_standing_order', leaving ambiguity about which ordering mechanism to choose.

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

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

The description only notes 'Auth required' as a prerequisite. It provides no guidance on when to use this tool versus alternatives like 'create_paid_order' or 'ensure_resources', nor does it mention prerequisites like wallet balance or address validation.

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

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

Annotations declare the mutation nature (destructiveHint=true, readOnlyHint=false). The description adds crucial behavioral context: the authentication requirement (TRON_PRIVATE_KEY), the specific protocol (x402), and the registration model (zero-registration) that isn't captured in structured fields.

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

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

Extremely efficient at 11 words. Front-loaded with the verb 'Create', every token earns its place: mechanism (x402), model (zero-registration), and critical prerequisite (TRON_PRIVATE_KEY) are all included with zero waste.

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

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

Adequate given the 100% schema coverage and presence of annotations. For a destructive financial operation, it appropriately highlights the private key requirement. However, without an output schema, it could benefit from mentioning what the tool returns (e.g., order ID, transaction hash) to be fully complete.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description does not redundantly explain the parameters (amount, duration_sec, etc.) but implies their purpose through the 'pay-per-use' context without adding specific syntax or format details beyond the schema.

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

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

The description clearly states the action (Create), resource (order), and mechanism (x402 pay-per-use, zero-registration). The 'zero-registration' and 'x402' specifics help distinguish it from sibling `create_order`, though it doesn't explicitly contrast the two.

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

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

States a critical prerequisite ('Requires TRON_PRIVATE_KEY'), implying when the tool is usable. However, it lacks explicit guidance on when to use this 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.

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

Adds 'server-side' (persistence location) and 'Auth required' beyond annotations. However, given idempotentHint=true and readOnlyHint=false in annotations, the description misses opportunity to explain execution lifecycle, trigger polling behavior, or what happens 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.

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

Two sentences with zero waste. Front-loaded with action and mechanism; prerequisite stated clearly at end. Every word earns its place.

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

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

Severely underspecified for a complex 7-parameter automation tool with nested trigger/action configurations. Fails to explain the trigger-action relationship, execution semantics, or how the standing order lifecycle works. No output schema compounds the gap.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add parameter syntax details, examples for the nested trigger_params/action_params objects, or clarify relationships between budget_trx and max_executions.

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

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

States specific verb (Create), resource (standing order), and mechanism (trigger-based automation). The 'trigger-based automation' phrase distinguishes it from sibling tools like create_order and create_paid_order, 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.

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 versus create_order/create_paid_order, or when trigger-based automation is appropriate versus single execution.

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

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

Adds critical authentication requirements not present in annotations. However, despite the destructiveHint=true annotation, the description fails to disclose what 'destructive' means here (irreversible blockchain transaction, permanent fund movement) or mention confirmation times, failure modes, or side effects.

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

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

Extremely efficient two-sentence structure. First sentence establishes the core action; second provides critical auth requirements. No redundant words or misplaced information.

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

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

Adequate for the simple single-parameter schema, but incomplete given the high-stakes destructive nature of the operation. Should mention irreversibility or blockchain broadcast behavior to complement the destructiveHint annotation. No output schema exists, but the description doesn't need to explain return values.

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

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

With 100% schema description coverage for the single 'amount_trx' parameter, the schema fully documents the input. The description adds no additional parameter semantics (format examples, precision constraints), warranting the baseline score of 3.

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

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

Clearly states the specific action (Deposit), resource (TRX), and destination (Merx account). Implicitly distinguishes from 'transfer_trx' (external transfer) by specifying the Merx account context, though it could be more explicit about the distinction from sibling tools.

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

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

Provides necessary prerequisites (MERX_API_KEY + TRON_PRIVATE_KEY) which helps the agent know when it can use the tool. However, it lacks explicit guidance on when to choose this over 'transfer_trx' or 'get_deposit_info', and doesn't mention any preconditions like address validation.

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

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

The 'Session-only' disclosure is critical behavioral context not present in annotations, indicating the configuration does not persist beyond the current session. Annotations cover idempotency and safety (destructiveHint: false), so the description appropriately focuses on persistence scope rather than repeating safety profiles.

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

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

Two sentences total. The first sentence front-loads the core function (configure automatic top-up), and the second delivers a critical constraint (Session-only). No wasted words or redundant information.

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

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

Adequate for a configuration tool with well-documented schema. Lacks explanation of funding source (where the TRX comes from) and immediate execution behavior (whether it checks balance immediately), but given the absence of an output schema and the presence of clear annotations, the description covers the essential configuration scope.

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

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

With 100% schema description coverage, the baseline is 3. The description mentions 'threshold' and 'top-up' which align with the parameter purposes, but adds no additional semantic context about valid formats, constraints, or dependencies between threshold and deposit amounts beyond what the schema already provides.

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

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

Clearly states the tool configures automatic top-up triggered by balance thresholds. Mentions 'automatic' distinguishing it from manual deposit siblings like deposit_trx. However, it does not explicitly differentiate from create_standing_order or explain why to choose this temporary configuration over persistent alternatives.

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

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

Provides no explicit guidance on when to use this tool versus manual deposits (deposit_trx) or standing orders (create_standing_order). The 'Session-only' constraint hints at temporary use cases but does not constitute explicit selection criteria or prerequisites.

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

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

The description adds valuable context beyond annotations: it explicitly states 'Auth required' (not in annotations) and explains the idempotent algorithm (check current → purchase missing), which aligns with and clarifies the `idempotentHint: true`. It correctly implies non-destructive mutation consistent with `destructiveHint: false`.

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

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

Three sentences with zero waste: sentence 1 defines the pattern (declarative provisioning), sentence 2 explains the implementation logic (check-then-purchase), sentence 3 states the auth requirement. Information is front-loaded and dense.

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

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

While the annotations cover safety properties and the schema documents inputs, the description omits what specific resources are provisioned (energy/bandwidth), requiring the agent to infer this from the schema parameter names. Without an output schema, the description also doesn't indicate what success/failure looks like.

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

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

With 100% schema description coverage, the schema fully documents all four parameters (target_address, duration_sec, energy_minimum, bandwidth_minimum). The description references 'target address' and implies the minimum thresholds, meeting the baseline expectation when the schema is self-documenting. No additional parameter syntax or format details are provided.

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

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

The description clearly states the tool performs 'Declarative resource provisioning' and explains the specific mechanism ('Checks current resources... purchases only what is missing'), distinguishing it from simple purchasing or checking tools. However, it doesn't explicitly name the resource types (energy/bandwidth) that the schema reveals, slightly limiting immediate comprehension.

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

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

The description implies usage context through 'declarative' and 'purchases only what is missing,' suggesting it's for idempotent provisioning. However, it lacks explicit guidance on when to choose this over siblings like `check_address_resources` (read-only check) or `create_order` (explicit purchase), or prerequisites beyond the auth mention.

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

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

Annotations declare readOnly/idempotent/safety properties. The description adds valuable behavioral context beyond annotations: the economic comparison logic ('rental vs burn cost') and operational constraint ('No auth required'). No contradictions with annotations.

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

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

Three sentences, zero waste. Front-loaded with core purpose (estimation), followed by specific behavioral detail (comparison logic), ending with operational requirement (no auth). Every sentence provides distinct value not redundant with structured fields.

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

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

Given 100% schema coverage and comprehensive annotations, the description efficiently covers purpose, behavioral specifics, and auth requirements. Lacks explicit return value description, but 'Estimate... cost' and 'Compares' sufficiently imply the output structure for an estimation utility.

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

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

Schema description coverage is 100%, with clear descriptions for all 4 parameters including examples (e.g., 'transfer(address,uint256)'). The description mentions 'smart contract call' which contextualizes the parameters but does not add syntax or format details beyond the schema. Baseline 3 appropriate given schema completeness.

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

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

Specific verb 'Estimate' paired with exact resources (energy/bandwidth cost) and scope (smart contract call). The phrase 'Compares rental vs burn cost' distinguishes this from generic estimation tools, clearly positioning it within TRON's resource model.

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

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

'No auth required' provides clear operational context for when to use this (pre-flight checks without credentials), implicitly distinguishing from execution tools like call_contract. However, it does not explicitly contrast with sibling estimate_transaction_cost or state when to prefer burning vs renting.

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

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

While annotations declare readOnly/idempotent/destructive hints, the description adds valuable behavioral context: 'No auth required' (security/prerequisite info) and 'Compares rental vs burn cost' (explains the specific calculation logic performed beyond generic estimation).

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

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

Three sentences, each earning its place: purpose declaration, behavioral specificity (rental/burn comparison), and usage constraint (no auth). Front-loaded with the core action and zero redundancy.

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

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

Given the rich schema (100% coverage) and complete annotations, the description provides adequate context for an estimation tool. Minor gap: no mention of return value structure, though this is somewhat mitigated by the intuitive 'estimate' purpose.

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

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

With 100% schema description coverage, the baseline is 3. The description does not add parameter-specific guidance (e.g., when to use 'custom' vs specific operations), but the comprehensive schema makes this unnecessary rather than deficient.

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

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

The description uses specific verb 'Estimate' with clear resource 'energy and bandwidth cost for a TRON transaction'. The addition of 'Compares rental vs burn cost' distinguishes this from generic estimation tools like sibling estimate_contract_call by specifying the unique comparison logic performed.

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

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

Provides one useful guideline ('No auth required') indicating it can be used pre-authentication. However, it fails to explicitly differentiate from sibling tool estimate_contract_call or clarify when to use this estimation versus executing the actual transaction.

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

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

The description adds valuable behavioral context beyond the annotations: it discloses the validation/simulation behavior, mentions resource cost estimates, and explicitly states 'Auth required' which is critical for a destructive operation. This supplements the destructiveHint annotation with practical pre-execution safety details.

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

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

The description is efficiently structured in two sentences: the first establishes the core function and scope, while the second adds critical behavioral qualifiers (validation, auth). There is no redundant or extraneous information; every clause earns its place.

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

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

For a destructive multi-step tool without an output schema, the description covers essential safety aspects (validation, auth, cost estimates) but omits execution guarantees (e.g., atomicity, partial failure behavior, rollback capabilities) that would help an agent understand failure modes and recovery. The annotations cover basic destructiveness, leaving the description adequate but not comprehensive for the complexity level.

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

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

With 100% schema description coverage, the structured fields already document all parameters clearly. The description mentions 'multi-step' and 'resource cost estimates' which loosely map to the 'steps' and 'resource_strategy' parameters, but adds no concrete syntax, format details, or usage guidance beyond the schema definitions.

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

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

The description clearly states the tool executes 'multi-step operations' and provides concrete examples (transfer, swap, buy resources) that distinguish it from single-step siblings like execute_swap or transfer_trx. However, the term 'intent' remains somewhat abstract without explicit contrast to the more specific atomic operation tools.

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

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

While the 'multi-step' phrasing implies this is for complex workflows rather than single operations, there is no explicit guidance on when to choose this over simpler alternatives like execute_swap, or prerequisites for use. The sibling differentiation relies on inference rather than explicit direction.

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

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

Adds authentication requirement (TRON_PRIVATE_KEY) not present in annotations. However, fails to elaborate on destructiveHint=true implications (irreversible blockchain transaction, fees consumed, permanent state change) or explain failure modes.

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

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

Extremely efficient two-sentence structure. First sentence defines purpose, second states critical prerequisite. Zero redundant words or generic filler.

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

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

Despite being a destructive financial operation with no output schema, description omits what the tool returns (transaction hash, status object), fee implications, and confirmation behavior. The private key mention alone is insufficient for safe invocation.

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

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

Input schema has 100% description coverage, documenting all parameters including slippage defaults. Description adds no parameter-specific semantics beyond schema, which is acceptable given high coverage, meeting baseline expectations.

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

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

States specific action (Execute) and resource (token swap on SunSwap V2) clearly. Implicitly distinguishes from sibling 'get_swap_quote' (execution vs. quoting) and 'transfer_trc20' (swapping vs. transferring), though explicit differentiation is absent.

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

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

Provides one critical prerequisite (TRON_PRIVATE_KEY requirement). However, lacks workflow guidance such as when to use 'get_swap_quote' first for price checking, or that 'approve_trc20' may be required for non-TRX tokens before swapping.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context that authentication is not required, which is not indicated in annotations. However, it omits what the explanation looks like (text length, format, structure) or error handling for invalid topics.

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

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

Two sentences, zero waste. First sentence establishes purpose; second provides critical auth information. Every word earns its place.

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

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

Given the tool's simplicity (single parameter, clear educational purpose) and presence of annotations, the description covers essential context. Minor gap: lacks description of return value format since no output schema exists, but this is a small omission for a straightforward explanation tool.

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

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

Schema coverage is 100%, so the schema fully documents the 'topic' parameter including valid values (energy, bandwidth, etc.). The description does not mention parameters at all, so it earns the baseline score of 3 for high schema coverage without adding supplementary semantic context.

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

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

States specific verb (Explain) and resource (TRON or Merx concept). Clearly distinguishes from operational siblings like transfer_trx or execute_swap by indicating this is informational/educational rather than transactional. Could be elevated to 5 by specifying the output format (e.g., 'returns educational text').

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

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

Provides one usage constraint ('No authentication required') which helps agents know when they can invoke this without credentials. However, lacks explicit guidance on when to prefer this over similar informational tools like analyze_prices or calculate_savings, or 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.

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

While annotations declare readOnly/idempotent/non-destructive properties, the description adds valuable operational context ('No auth required') and crucially lists the specific output fields, compensating for the absence of an output schema. This helps the agent understand exactly what data structure/content to expect.

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

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

Extremely concise two-sentence structure. First sentence front-loads the value proposition (what data is returned), second sentence provides critical operational constraint (no auth). Zero redundancy or filler.

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

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

For a simple single-parameter read operation with good safety annotations, the description is appropriately complete. It compensates for the missing output schema by enumerating return fields and covers authentication requirements. Minor gap: no mention of error cases (e.g., invalid address format).

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

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

With 100% schema description coverage for the single 'address' parameter, the schema fully documents the input. The description adds no additional parameter context, meeting the baseline expectation for well-documented schemas.

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

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

Clearly states it retrieves 'Full on-chain account state' and specifically enumerates the data returned (TRX balance, energy, bandwidth, creation date), which distinguishes it from sibling tools like get_balance or get_trx_balance that likely return partial data. However, it doesn't explicitly contrast with check_address_resources which may overlap in functionality.

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

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

Provides implied usage guidance through the specific list of returned fields (use this when you need energy, bandwidth, or creation date) and notes 'No auth required' which informs operational context. However, it lacks explicit when-to-use guidance comparing it to similar query tools like check_address_resources or get_balance.

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

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

Beyond annotations (readOnly/idempotent), the description adds essential behavioral context: the MERX_API_KEY authentication requirement and the composition of returned data (TRX, USDT, locked). This clarifies both the authorization boundary and the specific balance categories retrieved.

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

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

Two sentences total with zero waste: the first establishes functionality and return values, the second states the auth requirement. Information is front-loaded and every word earns its place.

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

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

For a zero-parameter read operation with annotations covering safety properties, the description is complete. It compensates for the missing output schema by describing the three balance categories returned (TRX, USDT, locked) and the authentication requirement.

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

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

The input schema contains zero parameters. Per rubric guidelines, this establishes a baseline score of 4. The description appropriately requires no parameter clarification.

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

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

The description uses a specific verb ('Get') with clear resource ('Merx account balance') and enumerates exact return components ('TRX, USDT, locked'). It distinguishes from siblings like get_trx_balance and get_trc20_balance by specifying 'Merx account' and 'locked' funds, indicating platform-specific balances versus on-chain balances.

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

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

The description states 'Requires MERX_API_KEY', providing a critical usage prerequisite, but fails to clarify when to select this tool over siblings such as get_account_info (which may also return balance data) or the specific asset balance tools (get_trx_balance, get_trc20_balance).

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

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

Annotations already establish the operation is read-only, idempotent, and non-destructive. The description adds valuable behavioral context not present in annotations: authentication is not required. It does not, however, disclose rate limits, caching behavior, or what constitutes a 'provider' in this context.

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

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

The description consists of exactly two sentences with zero redundancy: the first establishes purpose, the second states the auth requirement. Every word earns its place; no restructuring would improve information density.

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

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

Given the simple input schema (2 primitive parameters) and absence of an output schema, the description adequately covers the core functionality but leaves gaps regarding the return value structure (e.g., what provider details are returned, price format). For a lookup tool with strong annotations, this is minimally complete but could specify output expectations.

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

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

With 100% schema description coverage, the baseline is 3. The description mentions 'resource and amount' in the context of the search operation, which aligns with the schema parameters, but does not add semantic details beyond what the schema already provides (e.g., valid ranges, format constraints, or business logic for how 'amount' affects pricing).

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

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

The description states a specific verb ('Find') and resource ('cheapest provider'), clearly indicating this is a price optimization lookup. It implicitly distinguishes from siblings like 'compare_providers' or 'get_prices' by emphasizing 'cheapest' rather than general comparison or raw data retrieval, though it doesn't explicitly reference sibling tools.

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

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

The description provides one usage constraint ('No auth required'), indicating a prerequisite for invocation. However, it lacks explicit guidance on when to use this versus similar tools like 'compare_providers' or 'get_prices', leaving the agent to infer based on the 'cheapest' qualifier alone.

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

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

Annotations already declare read-only and idempotent safety properties. The description adds valuable behavioral context not in annotations: authentication requirements and default behavior when the parameter is omitted. Does not contradict annotations.

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

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

Two sentences with zero waste. Front-loaded with the core action, followed by parameter behavior and authentication requirements. Every clause earns its place in guiding tool selection and invocation.

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

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

Given the tool's simplicity (single optional parameter), presence of safety annotations, and lack of output schema, the description is complete. It covers purpose, parameter handling, and access requirements sufficiently for correct agent invocation.

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

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

Input schema has 100% description coverage ('Block number. Omit for latest.'). The description reinforces this usage pattern ('by number (or latest if omitted)') but does not add semantic meaning, format 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.

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

States specific verb 'Get' and resource 'TRON block info', clearly distinguishing from siblings like get_transaction or get_account_info. The parenthetical '(or latest if omitted)' further clarifies the retrieval scope.

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

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

Provides clear usage context for the parameter (omit for latest block) and explicitly states 'No auth required', establishing prerequisites. However, it does not explicitly contrast with sibling tools like get_transaction to guide selection.

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

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

Adds valuable behavioral context beyond annotations: 'No auth required' discloses authentication needs not captured in readOnlyHint/idempotentHint, and 'Merx price comparison' reveals the data source/comparison logic in the response. Does not contradict annotations (readOnlyHint=true aligns with 'Get').

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

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

Two sentences, zero waste. First sentence front-loads purpose with specific examples; second sentence states the auth constraint. Every word earns its place.

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

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

Adequate for a simple read-only tool with no parameters. Mentions specific return content (energy fee, bandwidth cost, Merx comparison) compensating partially for missing output schema. Could improve by noting return format, but sufficient for complexity level.

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

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

Input schema contains 0 parameters, establishing baseline score of 4 per rubric. Description appropriately focuses on behavior and return value rather than non-existent parameters.

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

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

Specific verb 'Get' with clear resource 'TRON network parameters' and concrete examples (energy fee, bandwidth cost). The mention of 'Merx price comparison' effectively distinguishes it from sibling price tools like get_token_price or analyze_prices by clarifying this retrieves network cost parameters rather than asset prices.

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

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

Provides clear context with 'No auth required', signaling appropriate use cases for unauthenticated scenarios. While it doesn't explicitly name alternatives (e.g., when to use this vs. get_best_price), the auth prerequisite offers concrete usage guidance.

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

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

With no annotations provided, the description carries the full disclosure burden. It successfully states 'No auth required' and enumerates the returned metadata fields to compensate. However, it omits explicit rate limit warnings or detailed error behavior when an invalid address is provided (though 'existence check' implies validation handling).

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

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

Three tightly constructed sentences: (1) capability and return values, (2) usage context with sibling references, (3) alternative tool and auth status. Zero redundancy, information-dense, well-structured.

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

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

Despite lacking an output schema and annotations, the description achieves completeness by enumerating all returned metadata fields (existence check, owner, energy origin, code hash, name, ABI count) and disclosing auth requirements. Sufficient for a single-parameter read operation.

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

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

Schema description coverage is 100% ('Contract TRON address'), establishing a baseline of 3. The description adds minimal semantic detail beyond the schema, though the surrounding context ('check whether an address is a contract') reinforces that the parameter expects a contract address.

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

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

The description opens with a specific verb+resource ('Get on-chain metadata for a TRON smart contract') and immediately enumerates the exact fields returned (existence check, owner address, energy origin, code hash, contract name, ABI entries count). It explicitly distinguishes from sibling 'get_token_info' by stating the latter is for TRC20-specific metadata.

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

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

Explicitly states when to use ('check whether an address is a contract before calling read_contract or estimate_contract_call') and provides a clear alternative workflow ('For TRC20-specific metadata... use get_token_info instead'). This creates a decision tree for the agent.

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

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

While annotations already indicate the operation is read-only and idempotent, the description adds the critical authentication requirement (MERX_API_KEY) not present in structured fields. However, it misses additional behavioral context such as what the 'memo' is used for, address format details, 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.

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

The description consists of two efficient sentences with zero redundancy. The first sentence front-loads the core purpose, while the second provides the critical prerequisite, making optimal use of limited space.

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

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

Given the tool's simplicity (no parameters, read-only operation) and the absence of an output schema, the description adequately indicates the return values ('address and memo'). It could be improved by specifying the blockchain/network context (implied by siblings to be TRON/TRC20) or return format details.

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

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

With zero parameters in the input schema, the baseline score applies. The description meets expectations by not inventing parameter documentation where none is needed, though it could have clarified that the API key is passed via configuration rather than parameters.

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

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

The description clearly states the specific action ('Get') and resource ('your Merx deposit address and memo'), distinguishing it from sibling tools like 'deposit_trx' (which likely executes a deposit) and 'get_balance' (which retrieves funds rather than deposit credentials).

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

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

The description provides the authentication prerequisite ('Requires MERX_API_KEY'), but lacks explicit guidance on when to use this tool versus alternatives like 'deposit_trx' or 'enable_auto_deposit', and doesn't mention that this should typically be called before initiating a deposit.

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

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

Adds critical behavioral context not present in annotations: 'Auth required' discloses authentication needs, and 'fill status' specifies unique data content retrieved beyond generic 'details'.

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

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

Two sentences with zero waste: first covers purpose and scope, second states auth requirement. Front-loaded with verb, no filler words.

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

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

For a simple single-parameter read operation, it adequately covers the return value concept ('details and fill status') and auth constraints despite lacking an output schema. Minor gap: no mention of 'not found' behavior.

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

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

Schema coverage is 100% ('The order UUID'), so baseline applies. Description references 'ID' aligning with the parameter but adds no additional semantic detail (format examples, constraints) beyond the schema.

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

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

States specific action ('Get'), resource ('order details and fill status'), and scope ('by ID'), clearly distinguishing it from sibling tools like 'list_orders', 'create_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.

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

Implies usage pattern through 'by ID' (suggesting specific lookup vs. enumeration), but lacks explicit when-to-use guidance contrasting it with 'list_orders' or error handling for invalid IDs.

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

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

The annotations already establish that this is a safe, read-only, idempotent operation. The description adds value by disclosing that no authentication is required, which is a practical behavioral trait not captured in the annotations. However, it omits other useful behavioral details such as data granularity, the number of snapshots returned, or rate limiting concerns.

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

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

The description consists of two brief sentences with no redundant or wasted words, efficiently conveying the core concept and auth requirements. However, it is arguably too concise for the tool's complexity and sibling context, failing to address the specific resource types or differentiate from the extensive list of price-related tools.

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

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

Given the presence of numerous price-related siblings (get_prices, get_token_price, get_trx_price, etc.), the description inadequately specifies that this tool retrieves historical data for ENERGY and BANDWIDTH resources specifically. Without an output schema, the description should also indicate the return format or structure, which it fails to do, leaving significant gaps in contextual understanding.

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

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

With 100% schema description coverage, the input parameters (period, provider, resource) are fully documented in the structured schema itself. The description does not add supplementary parameter guidance such as default value behavior or valid provider name formats, but this is acceptable given the comprehensive schema documentation.

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

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

"Historical price snapshots" identifies the core function of retrieving past pricing data, distinguishing it temporally from siblings like get_prices and get_trx_price. However, it fails to specify that this tool covers resource markets (ENERGY/BANDWIDTH) rather than token or TRX prices, leaving ambiguity given the numerous price-related tools available.

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

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

The description provides one usage constraint by stating "No auth required," which informs the agent about authentication requirements. However, it offers no guidance on when to select this tool versus alternatives like get_prices (likely current prices) or compare_providers, leaving the agent without selection criteria among the many price-related functions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the authentication requirement ('No auth required'), which is valuable behavioral context. However, it fails to disclose other relevant behaviors such as the return format, pagination, or whether prices are 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.

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

The description consists of two efficient sentences with the core purpose front-loaded in the first sentence and the authentication note in the second. Every word earns its place with no redundancy.

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

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

Given the tool's simplicity (2 optional parameters) and helpful annotations, the description covers essential invocation context. However, it lacks description of the return value despite having no output schema, which would help distinguish its payload from similar pricing tools.

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

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

With 100% schema description coverage, the schema already documents both parameters ('Filter by duration in seconds' and 'Filter by resource type'). The description mentions 'energy and bandwidth' but does not add semantic meaning beyond what the schema provides, meeting the baseline for high-coverage schemas.

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

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

The description states 'Get current energy and bandwidth prices from all Merx providers,' which clearly identifies the action (Get), resource (prices), domain (energy/bandwidth), and scope (all providers). This effectively distinguishes it from siblings like get_best_price (single result) and get_price_history (historical data), though it does not explicitly contrast with analyze_prices.

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

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

The description notes 'No auth required,' which provides a useful prerequisite for invocation. However, it lacks explicit guidance on when to use this tool versus similar siblings like analyze_prices or compare_providers, leaving selection criteria implicit.

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

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

No annotations provided, so description carries full burden. Discloses auth requirement ('Auth required (API key)') and documents return payload structure ('trigger config, action params, budget, executions count, status') despite lack of output schema. Could explicitly state read-only nature.

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

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

Three sentences, each high-value: purpose statement, return value disclosure, and auth prerequisite. Front-loaded with action. No redundancy or waste.

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

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

Appropriate for a single-resource retrieval tool. Compensates for missing output schema by listing return fields. Mentions auth prerequisite. Lacks explicit behavioral hints (read-only, idempotency) but sufficient given straightforward nature.

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

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

Schema coverage is 100% (parameter fully described as 'Standing order UUID'). Description mentions 'by its UUID' which reinforces the parameter meaning but adds minimal semantic value beyond the well-documented schema. Baseline 3 appropriate for high-coverage schemas.

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

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

Clear specific verb ('Get') + resource ('standing order') + scoping ('single'/'by UUID'). Distinguishes from siblings like list_standing_orders (list vs single) and get_order (standing orders have triggers/execution counts vs regular orders).

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

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

Implies specific lookup via 'single' and 'by its UUID', and the schema parameter description references list_standing_orders for workflow context. However, lacks explicit 'when to use vs alternatives' guidance in the description text itself regarding when to choose this over get_order.

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

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

Adds valuable context beyond annotations: 'No auth required' discloses authentication needs, 'SunSwap V2' identifies the specific DEX source, and 'real' implies live data fetching. Does not contradict annotations (readOnlyHint=true aligns with 'Get'). Could improve by mentioning caching or rate limits.

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

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

Optimal length: two sentences with zero waste. Front-loaded with the core action ('Get a real swap quote'), followed by critical operational note ('No auth required'). Every word earns its place.

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

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

Appropriately complete given rich annotations and 100% input schema coverage. Identifies the specific DEX protocol (SunSwap V2) which is crucial context. Lacks description of return values due to missing output schema, but 'quote' is sufficiently descriptive for this domain.

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

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

Schema coverage is 100%, so the schema fully documents all 4 parameters (from_token, to_token, amount, slippage). The description adds no parameter-specific semantics, meeting the baseline expectation for high-coverage schemas.

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

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

Excellent specificity: 'Get' (verb) + 'real swap quote' (resource) + 'from SunSwap V2' (source). Distinguishes from sibling 'execute_swap' by emphasizing 'quote' (price check) vs execution, and from 'get_best_price' via the SunSwap V2 specificity.

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

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

Provides one usage constraint ('No auth required') indicating prerequisites, but lacks explicit guidance on when to use versus siblings like 'execute_swap' (execution) or 'get_best_price' (price comparison). Usage relative to alternatives is implied but not stated.

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

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

Annotations cover safety profile (readOnly/idempotent), but description adds valuable behavioral context: 'No auth required' discloses authentication requirements not present in annotations. No contradictions with structured hints.

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

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

Two sentences, zero waste. Front-loaded with specific return values, ends with critical auth constraint. Every word earns its place; appropriate density for a simple metadata retrieval tool.

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

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

For a single-parameter read operation with strong annotations, description is complete. Critically, it compensates for missing output schema by enumerating return fields (name, symbol, decimals, total supply), eliminating ambiguity about what 'metadata' means.

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

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

Schema has 100% description coverage ('Token symbol or contract address'), so baseline applies. Description does not elaborate on parameter semantics, but schema is fully self-documenting. No additional parameter guidance needed.

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

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

Excellent specificity: verb 'Get' + resource 'TRC-20 token metadata' + exact fields returned (name, symbol, decimals, total supply). Clearly distinguishes from sibling tools like transfer_trc20 or get_trc20_balance by focusing on static metadata rather than balances or transfers.

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

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

Provides important usage constraint 'No auth required' which helps determine when this tool is appropriate (unauthenticated scenarios). However, lacks explicit comparison to similar tools like get_token_price or get_trc20_balance to guide selection between metadata vs. price vs. balance retrieval.

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

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

Annotations indicate read-only/idempotent safety. The description adds valuable behavioral context not in annotations: specific data sources (SunSwap + CoinGecko) and authentication requirements ('No auth required'). No contradictions with annotations.

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

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

Two sentences, zero waste. Front-loaded with the core purpose (Get token price...) followed by implementation detail and prerequisite. Every word earns its place.

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

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

For a simple read-only tool with one parameter and good annotations, the description is sufficiently complete. It covers purpose, data sources, and auth requirements. Minor gap: doesn't hint at return value format (e.g., USD price), though this is somewhat inferable from the name.

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

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

Schema has 100% description coverage for the single 'token' parameter. The description text does not mention the parameter or add semantic details beyond the schema, warranting 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.

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

States specific action (Get token price) and identifies unique data sources (SunSwap quote + CoinGecko USD rate) that distinguish it from siblings like get_trx_price or get_best_price. However, it lacks explicit differentiation from similar price tools (get_prices, get_swap_quote) regarding when to use each.

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

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

Provides one usage constraint ('No auth required') which helps agents understand prerequisites. However, it lacks explicit guidance on when to use this versus siblings like get_best_price or get_swap_quote, or 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.

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

Annotations already cover read-only, idempotent, and non-destructive traits. The description adds valuable behavioral context that 'No auth required', which annotations don't specify. However, it omits what happens if the transaction ID is not found or rate limiting behavior.

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

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

Two sentences total, front-loaded with the core action. 'No auth required' earns its place as critical prerequisite information for a blockchain tool. No redundancy or waste.

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

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

Given the tool's simplicity (single required parameter, read-only lookup) and good annotations, the description is nearly complete. Minor gap: could mention error behavior for invalid IDs or the nature of returned data since no output schema exists.

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

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

Schema coverage is 100% with tx_id already described as 'Transaction ID (hash)'. The description mentions 'by ID' which aligns with the parameter but doesn't add syntax details, format examples, or constraints beyond what the schema already provides. Baseline 3 is appropriate for high schema coverage.

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

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

The description uses specific verb 'Look up' with resource 'transaction' and scope 'by ID on TRON', clearly distinguishing it from sibling tools like get_transaction_history or search_transaction_history which imply bulk/filtered retrieval rather than specific ID lookup.

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

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

States 'No auth required' which provides prerequisite context useful for selection, but does not explicitly contrast with sibling alternatives (e.g., when to use search_transaction_history instead) or provide exclusion criteria.

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

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

Annotations already establish the read-only, idempotent, non-destructive nature. The description adds value by disclosing the MERX_API_KEY authentication requirement, which is not present in annotations or parameters. However, it omits details about pagination, result limits, or output format.

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

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

The two-sentence structure is efficient and front-loaded with the core purpose. The second sentence addresses authentication requirements. No redundancy exists, though extreme brevity limits contextual richness.

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

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

For a simple read-only retrieval with one optional parameter, the description covers the essentials (purpose + auth). However, it lacks sibling differentiation and output structure details that would help an agent handle the response correctly, especially given the existence of related transaction tools.

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

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

With 100% schema description coverage for the 'period' parameter (including enum values and default), the description appropriately relies on the schema. It neither repeats nor augments the parameter documentation, meeting the baseline for high-coverage schemas.

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

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

The description clearly states the tool retrieves 'Merx account transaction history' with a specific verb and resource. However, it fails to differentiate from the sibling tool 'search_transaction_history', leaving ambiguity about when to use retrieval versus search.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'search_transaction_history' or 'get_transaction' (singular). It mentions the MERX_API_KEY requirement but lacks prerequisites or exclusion criteria.

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

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

Annotations cover safety profile (readOnly/idempotent), but description adds valuable auth context ('No auth required') that annotations don't provide. Does not contradict annotations.

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

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

Three sentences, front-loaded with purpose. Every sentence provides distinct value (purpose, parameter format, auth requirements). No redundancy or waste.

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

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

Appropriate for a simple 2-parameter query tool with full schema coverage and annotations. Minor gap: doesn't describe return value format, though this is somewhat implied by the tool name.

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

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

Schema has 100% coverage with clear descriptions. Description reinforces the token parameter flexibility with concrete examples (USDT, USDC) but adds minimal semantic meaning beyond the schema.

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

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

Specific verb 'Get' + resource 'TRC-20 token balance' + target 'address'. The TRC-20 specificity clearly distinguishes it from siblings like get_balance and get_trx_balance.

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

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

Provides operational guidance ('No auth required') and parameter usage hints, but lacks explicit comparison to sibling balance tools (get_balance, get_trx_balance) for when to use each.

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

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

Annotations already establish read-only, idempotent, non-destructive safety. The description adds valuable behavioral context by stating 'No auth required,' which addresses authentication needs not covered in annotations. No contradictions with annotations exist.

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

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

The two-sentence structure is perfectly front-loaded: first sentence states purpose, second states the auth constraint. Zero redundancy—every word earns its place. Appropriate length for a simple single-parameter tool.

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

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

Given the low complexity (one required parameter, simple read operation) and strong annotations, the description is sufficiently complete. The auth disclosure covers a critical gap. Minor gap: does not describe return value format, though this is acceptable without an output schema for a straightforward balance query.

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

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

With 100% schema description coverage ('TRON address (T...)'), the baseline is 3. The description mentions 'TRON address' but does not add semantic details beyond the schema, such as address validation rules, format constraints, or examples that would elevate the score.

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

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

The description clearly states it retrieves 'TRX balance for a TRON address' with specific resource (TRX) and target (TRON address). However, it does not explicitly distinguish from siblings like get_trc20_balance (token balances) or get_account_info (broader account data), though the TRX specificity provides implicit differentiation.

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

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

The description provides one usage constraint ('No auth required') indicating it can be called without credentials, which is valuable for a blockchain tool. However, it lacks explicit guidance on when to choose this over get_trc20_balance or get_balance alternatives.

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

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

Adds valuable context beyond annotations: explicitly states 'No auth required' (contrasting with siblings like set_api_key) and discloses the external data source 'CoinGecko', which helps agents assess data reliability. Does not mention rate limits or caching, but annotations already cover the safety profile.

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

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

Two sentences with zero waste. Front-loaded with the core purpose (TRX price), followed by the critical usage note (auth). No redundant or filler text.

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

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

Adequate for a simple read-only data fetch. Annotations cover safety properties, schema covers input, and the description covers data source. Minor gap: does not describe return value format, though this is less critical for a single-value price endpoint.

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

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

Schema coverage is 100% with the currency parameter fully documented in the schema. The description adds no additional parameter semantics, which is acceptable given the schema's completeness, meeting the baseline for high-coverage schemas.

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

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

Specific verb 'Get' + resource 'TRX price' + data source 'CoinGecko' provides exact scope. The TRX specificity naturally distinguishes it from sibling tools like get_token_price (generic) or get_prices (plural/bulk).

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

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

Provides one usage constraint ('No auth required'), but lacks explicit guidance on when to use this versus siblings like get_token_price or get_best_price. Usage is implied by the TRX specificity rather than explicitly stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds the 'Auth required' constraint not present in annotations. However, it fails to describe return values, pagination behavior, or what constitutes a 'monitor' in this context.

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

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

The description consists of two efficient sentences with zero waste. It front-loads the primary action ('List all monitors') before stating the constraint ('Auth required'), making it easy to parse quickly.

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

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

Given the low complexity (single optional parameter, simple enum, read-only operation) and 100% schema coverage, the description is minimally adequate. However, the absence of an output schema means the description should ideally describe what monitor data is returned, which it omits.

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

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

With 100% schema description coverage (the 'status' parameter is fully documented in the schema with enum values and description), the baseline score is 3. The description mentions 'optional status filter,' which aligns with the schema but adds no additional semantic detail about filter syntax or behavior.

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

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

The description clearly states the tool 'List[s] all monitors' (specific verb + resource) and mentions the 'optional status filter' scope. While it implicitly distinguishes from sibling 'create_monitor' via the verb 'List', it does not explicitly clarify when to list versus create monitors.

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

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

The description states 'Auth required,' indicating a prerequisite, but provides no guidance on when to use this tool versus alternatives like 'create_monitor' or what conditions warrant listing monitors. No 'when-not-to-use' or selection criteria are present.

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

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

The annotations already establish the safety profile (read-only, idempotent, non-destructive). The description adds the authentication requirement and the 'recent' qualifier (implying temporal ordering), but fails to disclose pagination behavior, the default limit implication, or what the return structure looks like given the absence of an output schema.

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

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

The description consists of two efficient sentences with zero redundancy. The primary action is front-loaded ('List recent orders'), followed by the filtering capability and prerequisites, making it immediately scannable.

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

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

For a read-only listing tool with complete input schema coverage, the description covers the essentials (action, filter, auth), but gaps remain regarding the output format (critical given no output schema exists) and differentiation from the numerous sibling listing tools available on this server.

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

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

With 100% schema description coverage, the baseline is appropriately met. The description mentions 'optional status filter' which aligns with the schema, and the 'recent' framing implicitly supports the 'limit' parameter, but adds no additional semantic detail about parameter interaction or data formats beyond the schema.

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

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

The description clearly states the verb ('List') and resource ('orders'), and specifies the key capability ('optional status filter'). However, it does not explicitly differentiate from siblings like 'get_order' (which retrieves a specific order) or 'list_standing_orders', leaving potential ambiguity about which list tool to use.

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

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

While the description notes 'Auth required'—a necessary prerequisite—it provides no guidance on when to use this tool versus alternatives like 'get_order' or 'search_transaction_history', nor does it mention the default behavior when no parameters are provided.

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

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

Adds crucial behavioral information not present in annotations: the authentication requirement (or lack thereof). While annotations cover safety profile (readOnly, idempotent, non-destructive), the description adds operational context. No contradictions with annotations.

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

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

Two sentences, zero waste. First sentence establishes function and return payload; second provides critical operational constraint (no auth required). Front-loaded with the most important information.

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

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

Despite lacking an output schema, the description hints at return structure by listing specific fields (types, durations, availability). For a zero-parameter, read-only listing tool, this provides sufficient context for invocation, though pagination details would elevate it to 5.

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

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

Input schema has 0 parameters, triggering the baseline score of 4. With no parameters to document, the description appropriately focuses on return value semantics (types, durations, availability) instead.

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

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

Clear specific verb (List) + resource (Merx providers) + scope (all). The phrase 'with types, durations, and availability' specifies what data is returned, distinguishing it from sibling compare_providers (which likely analyzes differences) and price-focused tools like get_best_price.

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

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

Provides operational context with 'No authentication required,' indicating it can be used without credentials. However, lacks explicit guidance on when to use this versus compare_providers or other provider-related tools, and doesn't state prerequisites or exclusions beyond auth.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the 'Auth required' constraint not present in annotations, but omits details about return format, pagination, or what distinguishes standing order statuses (ACTIVE vs TRIGGERED, etc.).

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

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

Two sentences with zero redundancy. The first sentence combines purpose and parameter information; the second states authentication requirements. Every word earns its place.

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

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

Given the simple single-parameter schema and clear annotations, the description covers minimum viable context. However, lacking an output schema, it could benefit from describing what fields are returned or what constitutes a 'standing order' in this domain.

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

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

Schema has 100% description coverage with the status parameter fully documented. The description notes the filter is 'optional', which aligns with the schema (0 required parameters), but adds no additional semantic context about status values or query behavior beyond the schema definition.

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

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

The description clearly states the tool 'List[s] all standing orders' with specific verb and resource. It distinguishes from sibling 'list_orders' by specifying 'standing orders', though it could further clarify the distinction between standing orders and regular orders.

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

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

Only mentions 'Auth required' as a prerequisite. Provides no guidance on when to use this versus similar listing tools like 'list_orders' or 'get_order', nor when to apply the status filter versus retrieving all records.

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

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

Beyond the annotations (which indicate idempotent, non-destructive mutation), the description adds valuable authentication context: specifically that this method bypasses the API key requirement. This is critical behavioral information not present in structured fields.

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

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

Two sentences total: the first states purpose, the second states a critical constraint. Both sentences earn their place with zero redundancy or filler.

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

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

For a simple 2-parameter authentication tool with no output schema, the description covers essential context: purpose, existing account requirement, and authentication method. Missing only minor details like session duration or return value format.

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

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

With 100% schema description coverage ('Email address', 'Password'), the schema adequately documents the parameters. The description adds no additional parameter semantics, which is acceptable given the high schema coverage.

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

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

The description uses a specific verb ('Log in') and resource ('existing Merx account'), clearly distinguishing this from the sibling 'create_account' tool through the word 'existing'.

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

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

The phrase 'No MERX_API_KEY needed' provides crucial guidance on when to use this tool versus API-key-based authentication methods (like set_api_key). However, it doesn't explicitly contrast with create_account for new account registration.

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

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

Discloses return values ('Shows amount, recipient, token, and status') beyond what annotations provide, and clarifies the non-custodial operational model that annotations don't capture.

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

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

Three sentences with zero waste: purpose, return values, and operational constraints are front-loaded with no filler text.

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

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

Compensates well for missing output schema by enumerating the specific fields returned (amount, recipient, token, status) and explaining the critical non-custodial workflow context for this financial operation.

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

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

With 100% schema coverage describing the invoice_id format ('inv_xxx' or URL), the description appropriately relies on the schema, adding only the 'MERX' domain context without redundant parameter explanation.

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

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

States specific verb ('Look up') and resource ('MERX invoice'), and distinguishes from payment execution tools by clarifying it only retrieves data rather than processing transfers.

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

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

Explicitly states the non-custodial workflow constraint ('Agent must sign and broadcast the transfer separately'), implying this is for inquiry only, though it doesn't explicitly name the sibling tool (pay_invoice) to use for actual payment.

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

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

The description adds some behavioral context beyond the annotations by specifying the currency (TRX) and the verification step involved in the process. However, given the destructiveHint=true annotation indicating irreversible financial mutation, the description could disclose more about failure modes, confirmation requirements, or gas fees.

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

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

The single sentence is efficiently front-loaded with no wasted words. It packs the action verb, resource specificity (x402), currency (TRX), and completion behavior (verifying) into nine words, making it immediately scannable.

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

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

For a single-parameter financial operation, the description combined with the 100% schema coverage and safety annotations provides adequate context for tool selection. However, given the lack of output schema and the irreversible nature of the transaction, the description could be strengthened by mentioning success indicators or error conditions.

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

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

With schema description coverage at 100%, the input schema fully documents the invoice_id parameter. The description does not add additional semantic detail about the parameter format (e.g., UUID vs numeric) or where to obtain it, meeting the baseline expectation for well-documented schemas.

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

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

The description clearly states the action ('Pay'), the specific resource type ('x402 invoice'), and the mechanism ('sending TRX and verifying payment'). However, it does not explicitly differentiate this tool from sibling payment tools like 'transfer_trx' or 'create_paid_order', which also involve sending cryptocurrency.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives (e.g., when to pay an invoice vs. making a direct transfer). It also omits prerequisites such as requiring sufficient TRX balance or having a valid invoice ID ready, offering only the implied context of the resource type.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context not present in annotations: explicitly stating 'No auth or private key required,' which clarifies network interaction requirements.

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

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

Two sentences, zero waste. First sentence establishes purpose; second sentence front-loads the critical constraint (no auth needed). Every word serves a specific function.

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

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

Given the tool's focused scope and comprehensive annotations, the description is sufficient. However, lacking an output schema, it could briefly indicate the return format (e.g., hex-encoded result) to be fully complete.

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

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

Schema description coverage is 100%, with all parameters fully documented (contract_address, function_selector with example, parameter). The description adds no parameter-specific details, but at this coverage level, none are required.

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

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

States specific action (Call) on specific resource (view/pure function on TRON smart contract). The 'view/pure' qualifier clearly distinguishes this from state-changing contract interactions, and 'No auth or private key required' differentiates it from tools requiring authentication.

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

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

Implies usage context through 'view/pure' (read-only) and 'no auth required' constraints, signaling when to use versus state-changing operations. However, it does not explicitly name the sibling alternative (e.g., call_contract) for write operations.

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

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

With no annotations provided, description carries full burden. Discloses idempotency ('calling twice with the same key returns the existing registration') and auth requirements ('Auth required (API key)'). Lacks error scenarios or rate limit details, but covers key behavioral traits.

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

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

Four tightly constructed sentences with zero waste. Front-loaded with purpose, followed by prerequisite dependencies, parameter guidance, and behavioral properties. Every sentence earns its place.

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

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

Sufficient for a registration tool without output schema. Covers identity creation, prerequisites for payment ecosystem, auth requirements, and idempotency. Could strengthen with explanation of what 'agent' status enables or failure modes for invalid addresses.

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

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

Schema has 100% coverage (baseline 3). Description adds semantic value beyond schema by clarifying the TRON address serves as 'on-chain identity for this API key' and implies receiving payments functionality, helping agent understand the address's purpose.

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

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

Excellent clarity with specific verb 'Register', resource 'TRON address as an agent', platform 'agent.merx.exchange', and scope 'on-chain identity'. Clearly distinguishes from siblings by establishing it as the prerequisite identity-setup step.

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

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

Explicitly states 'Required ONCE before using' and names five specific sibling tools (request_payment, create_invoice, watch_address, agent_status) plus category 'any other agent payment tool'. Also notes idempotency behavior which guides retry logic.

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

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

Adds valuable behavioral details beyond annotations: specifies the return value ('Returns a payment address'), webhook behavior ('Fires webhook'), and latency ('<3 seconds'). Annotations already indicate idempotent/non-destructive nature, so description wisely focuses on operational characteristics instead of repeating safety flags.

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

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

Three tightly constructed sentences: purpose declaration, behavioral/output disclosure, and usage context. No filler words. Information is front-loaded with the core action ('Create...'), making it easy to scan. Every sentence earns its place.

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

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

Given the 5 parameters with 100% schema coverage and presence of annotations, the description provides adequate completeness. It compensates for the missing output schema by stating what gets returned ('payment address'). Minor gap: does not mention error handling, timeout behavior details, or idempotency semantics (though covered by annotation).

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

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

Schema description coverage is 100%, providing detailed descriptions for all 5 parameters (amount_usdt, description, webhook_url, tolerance_pct, timeout_seconds). The description mentions supported token types which loosely contextualizes amount_usdt, but does not add syntax, format details, or semantic constraints beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Create') with a clear resource ('TRC20 payment request on TRON') and enumerates supported token standards (USDT, USDC, USDD, any TRC20). It clearly distinguishes from sibling tools like transfer_trc20 or pay_invoice by focusing on 'receiving payments' rather than sending.

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

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

Provides clear context on when to use ('for receiving payments from other agents or humans'), implicitly distinguishing from outbound payment tools. However, it does not explicitly name sibling alternatives like create_invoice or clarify when to prefer this over other receipt mechanisms.

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

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

Adds critical behavioral context beyond annotations: multi-step internal flow (estimate, buy, wait, broadcast), financial side effects (purchases energy at market price), and timeout/refund behavior.

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

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

Perfectly structured with front-loaded purpose, followed by mechanism, requirements, and returns; every sentence conveys distinct operational information without redundancy.

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

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

Comprehensively covers the complex multi-step operation (energy market interaction, delegation waiting), prerequisites, and return values despite absence of output schema.

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

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

Schema has 100% description coverage; description mentions parameters in context ('pre-signed transaction', 'target address') but adds minimal semantic value beyond the structured schema definitions.

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

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

Clearly states the specific action (broadcast signed TRON transaction) and unique differentiator (automatic energy optimization/MERX purchasing), distinguishing it from siblings like ensure_resources or transfer_trx.

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

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

States prerequisites (MERX_API_KEY, pre-signed transaction) but lacks explicit comparison to alternatives like ensure_resources or standard broadcast tools.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the 'No auth required' constraint which is useful behavioral context not present in annotations, but lacks details on pagination, data freshness, or rate limits.

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

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

Two sentences with zero waste. The first establishes function and domain; the second states a critical prerequisite. Every word earns its place with no redundancy.

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

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

While adequate for a simple lookup tool with good schema coverage and annotations, the description has clear gaps regarding the distinction from 'get_transaction_history' and lacks any return value documentation (though no output schema exists to guide this).

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

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

Schema description coverage is 100% (all three parameters have descriptions), establishing baseline 3. The description adds no explicit parameter guidance, but the schema adequately documents the address, type filter, and limit parameters.

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

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

The description clearly states the action ('Get') and resource ('on-chain transaction history') with specific scope ('TRON address'). However, it fails to differentiate from the sibling tool 'get_transaction_history', leaving ambiguity about which tool to use for transaction retrieval.

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

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

Only provides the prerequisite 'No auth required' but offers no guidance on when to use this tool versus the similar 'get_transaction_history' sibling, nor any exclusion criteria or workflow context.

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

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

Annotations declare idempotency and non-destructive nature. Description adds critical behavioral context not in annotations: session-scoped persistence ('for this session') and authorization side effects ('Unlocks all authenticated tools'). Does not contradict annotations.

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

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

Three sentences total, each earning its place: (1) core action, (2) authorization impact, (3) usage prerequisite. No filler words, appropriate length for a single-parameter authentication tool.

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

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

Complete for a simple session configuration tool. Covers authentication purpose, side effects on tool availability, and prerequisites. No output schema exists to document. Could enhance by mentioning validation behavior or overwrite semantics, but adequate given low complexity.

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

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

Input schema has 100% description coverage (including 'starts with sk_live_' hint). With schema fully documented, baseline is 3. Description implies the parameter through context but does not add syntax, format, 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.

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

States specific verb 'Set' with resource 'Merx API key' and scope 'for this session'. Explicitly distinguishes from siblings like 'set_private_key' and 'login' by specifying 'API key' and mentioning it unlocks authenticated trading/balance tools.

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

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

Provides clear prerequisite condition 'Use this if you already have an API key', implicitly distinguishing from 'login' or account creation flows. Lacks explicit 'when not to use' or direct comparison to 'set_private_key', but the prerequisite guidance is specific and actionable.

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

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

While annotations indicate idempotent/non-destructive hints, the description adds critical behavioral context: the address derivation is automatic, the key has session-scoped lifecycle ('for this session'), and crucial security guarantees ('Key stays local - never sent to Merx servers'). It does not mention rate limits or detailed state mutation mechanics, preventing a perfect score.

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

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

Four sentences with zero redundancy: action definition, side effect (address derivation), prerequisite relationship (enables write tools), and security guarantee (local storage). Information is front-loaded and every clause earns its place.

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

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

Given this is a session configuration tool with one parameter and no output schema, the description adequately covers the security model, lifecycle, and downstream effects. It could explicitly mention the idempotent nature (though present in annotations) or error conditions, but it is sufficiently complete for safe invocation.

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

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

With 100% schema description coverage (the private_key parameter is fully documented as '64 hex characters'), the description appropriately relies on the schema. It references the 'TRON private key' but does not add syntax details, format examples, or validation rules beyond the schema definition, meeting the baseline for high-coverage schemas.

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

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

The description opens with a specific verb and resource ('Set your TRON private key') and clarifies scope ('for this session'). It effectively distinguishes this setup tool from its sibling write tools by listing the specific operations it enables (transfer_trx, etc.).

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

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

Explicitly states when to use the tool by enumerating the write tools it enables ('transfer_trx, transfer_trc20...'). This implicitly defines when NOT to use it (for read-only operations like get_balance) and establishes the prerequisite relationship to the listed siblings.

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

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

Annotations confirm read-only/idempotent safety; the description adds valuable behavioral context about return values ('Returns resource estimates and costs') and reinforces the non-destructive nature, without contradicting annotations.

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

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

Two sentences with zero waste: first defines the action and dry-run nature, second specifies return values. Perfectly front-loaded and appropriately sized for the tool complexity.

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

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

For a 2-parameter tool with full schema coverage and no output schema, the description adequately compensates by specifying return values. Missing only minor details like error handling behavior for invalid steps.

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

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

Schema coverage is 100%, establishing baseline 3. The description provides semantic context mapping 'multi-step operation' to the steps parameter and 'resource estimates' to resource_strategy, but doesn't add syntax details beyond the schema.

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

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

The description uses specific verb 'Simulate' with clear resource 'multi-step operation' and explicitly states 'without executing,' which sharply distinguishes it from execution siblings like execute_intent, execute_swap, and create_order.

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

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

The phrase 'without executing' provides clear implicit guidance to use this for dry-run validation before actual execution, though it doesn't explicitly name specific alternatives like 'use before execute_intent'.

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

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

The description adds authentication requirements ('No authentication required') not covered by annotations. However, with annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds minimal additional behavioral context regarding rate limits, return format, or recommendation logic.

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

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

The description consists of two efficient sentences with zero waste. The first states purpose, the second states a key behavioral constraint. Every word earns its place.

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

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

Given the tool's simplicity (2 parameters, read-only) and good annotation coverage, the description is minimally adequate. However, it lacks mention of what the tool returns (duration format/timeframe) and omits the specific domain (TRON resources), leaving minor gaps in contextual completeness.

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

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

With 100% schema description coverage, the baseline score is 3. The description references 'your use case' which aligns with the required parameter, but does not add semantic clarification beyond the schema's existing descriptions for use_case or transaction_count.

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

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

The description uses a specific verb ('Recommend') and resource ('rental duration') to explain the tool's function. While it could explicitly specify 'resource rental' to distinguish from other rental domains, the context of sibling tools (ensure_resources, resource_broadcast) makes the intent reasonably clear.

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

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

The description notes 'No authentication required,' which provides useful prerequisite guidance for when the tool can be invoked. However, it lacks comparative guidance distinguishing this from sibling recommendation tools like calculate_savings or analyze_prices, or when to prefer specific use_case values.

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

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

Adds valuable behavioral context beyond annotations: 'Signs and broadcasts on-chain' confirms the write operation matches destructiveHint=true, and 'automatic energy optimization' discloses TRON-specific resource management behavior not captured in annotations. No contradictions with annotation flags.

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

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

Three sentences with zero waste: action/capability first, behavioral mechanism second, requirement third. Every word earns its place. Perfectly 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.

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

Adequate for a three-parameter tool but missing return value documentation (transaction hash? receipt?) given no output schema exists. Destructive financial operation would benefit from mentioning success indicators or failure modes, though annotations cover the safety profile.

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

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

With 100% schema description coverage, the schema adequately documents all three parameters (token, amount, to_address). The description adds no additional parameter guidance (e.g., address format validation, amount precision), earning 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.

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

States specific action ('Transfer TRC-20 tokens') plus distinguishing capability ('automatic energy optimization'). Clearly differentiates from sibling transfer_trx (native token) and approve_trc20 (allowance setting) by specifying the token standard and direct transfer behavior.

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

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

States prerequisite ('Requires TRON_PRIVATE_KEY') but lacks guidance on when to use vs alternatives. Missing critical workflow context: doesn't mention that approve_trc20 may be needed first for some token transfers, nor distinguishes from execute_swap for trading scenarios.

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

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

Excellent disclosure beyond annotations: explains automatic bandwidth checking, conditional resource acquisition ('buys via Merx'), full execution flow ('Signs and broadcasts on-chain'), and authentication requirements. Aligns perfectly with destructiveHint=true.

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

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

Four short sentences with zero waste. Front-loaded with core purpose, followed by behavioral details, execution method, and prerequisites. Every sentence earns its place.

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

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

Comprehensive for a 2-parameter transaction tool. Covers prerequisites, side effects (resource purchasing), and execution method. Missing only return value documentation, but acceptable given no output schema exists.

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

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

Schema coverage is 100% with clear parameter descriptions ('Recipient TRON address', 'Amount of TRX'). Description references these concepts ('Send TRX to an address') but does not add syntax details, format constraints, or examples beyond the schema. Baseline 3 is appropriate given complete schema coverage.

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

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

Clear specific verb ('Send') + resource ('TRX') + target ('address'). Explicitly names the cryptocurrency (TRX) distinguishing it from sibling transfer_trc20 and other financial operations like deposit_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.

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

States prerequisite ('Requires TRON_PRIVATE_KEY') and hints at automated resource management behavior. However, lacks explicit when-to-use guidance versus sibling transfer_trc20 (native currency vs tokens) or deposit/withdraw operations.

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

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

While annotations already declare read-only, idempotent, and non-destructive properties, the description adds valuable behavioral context: it explicitly states 'No auth required' (not in annotations) and clarifies that validation includes checking 'on-chain status' (implying a live blockchain query rather than just regex validation).

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

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

The description consists of two efficient sentences with zero waste. It is front-loaded with the core action ('Validate...') and follows with the secondary constraint ('No auth required'). Every word earns its place.

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

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

For a single-parameter validation tool with no output schema, the description adequately covers the essential behavioral traits (validation scope, auth requirements). It could be improved by briefly indicating what constitutes a valid result (e.g., format correctness + existence), but it is sufficiently complete for tool selection.

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

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

With 100% schema description coverage ('TRON address to validate'), the schema already fully documents the parameter. The description mentions 'TRON address' but does not add syntax details, format examples (base58 vs hex), or validation constraints beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses specific verbs ('Validate', 'check') and clearly identifies the resource (TRON address format and on-chain status). It effectively distinguishes from siblings like 'convert_address' (which converts formats) and 'check_address_resources' (which checks bandwidth/energy) by focusing on format validation and existence status.

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

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

The description provides one usage constraint ('No auth required'), which helps select this tool for unauthenticated scenarios. However, it lacks explicit guidance on when to use this versus similar address-related siblings like 'check_address_resources' or 'convert_address', leaving some ambiguity for the agent.

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