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

The description adds meaningful behavior beyond the annotations: it spends paymentAmount SUN from the internal balance, is not idempotent because a repeat buys again, returns one order id per receiver, and requires a wallet signature identity. It stops short of explaining batch atomicity or partial-failure behavior, which matters for a multi-receiver financial mutation.

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 definition is compact and front-loaded: what it buys, who pays, return shape, side effect, idempotency warning, estimation prerequisite, and signature requirement. Every sentence carries operational value.

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

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

Given the presence of an output schema and detailed parameter schema, the description supplies the remaining critical context: internal-balance spending, non-idempotency, wallet signature requirement, and a pre-call estimate/confirmation workflow. An agent has enough information to call it safely.

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 high at 86%, so the schema already does most parameter documentation. The description adds that resourceAmount is the SAME amount for every receiver and that paymentAmount is total cost, but it does not add much 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 names a specific verb and resource: buy the same amount of ENERGY or BANDWIDTH for several receiver addresses. It distinguishes this bulk operation from single-order siblings like tronsave_create_order and internal order creation 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?

It explicitly instructs the agent to estimate one receiver with tronsave_estimate_buy_resource first and to show the user receivers, amount and total cost before calling. That gives a clear prerequisite and confirmation step, not just implied usage.

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?

Goes well beyond the annotations, which already declare destructiveHint/idempotentHint: it explains that the order becomes non-matchable, locked balance is refunded per backend rules, cancelling twice is a no-op success, and that a wallet-signature identity of the order's owner is required. Nothing about side effects or preconditions is left implicit.

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 core action is front-loaded and each sentence carries actionable information (return shape, side effects, idempotency, failure modes, alternatives). It is dense and semicolon-packed but not padded; minor loss for the run-on density over a tighter list format.

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 one-parameter destructive mutation with an output schema present, the description covers preconditions, side effects, idempotency, auth requirements, and alternate tools. An agent has everything needed to call it correctly and safely.

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

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

Schema coverage is 100% and the schema already documents `orderId` as an MObjectId that must be an active, authorized order. The description restates 'open order by `orderId`' without adding format, sourcing, or validation detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Cancel an open order by `orderId`') and implicitly scopes it to active orders, which separates it from `tronsave_update_order` and `tronsave_get_order`. An agent can identify the operation without opening the schema.

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 names prerequisites ('Verify state with `tronsave_get_order` first') and the alternative ('prefer `tronsave_update_order` when only price/receiver should change'), plus the failure cases (fulfilled orders, unauthorized callers). Routing guidance is complete.

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 non-read-only and non-idempotent, but the description adds the material facts an agent needs: it SPENDS internal TRX on every fire, stops at a budget/order limit or endActiveAt, requires a wallet signature identity, and demands user confirmation before calling. That is well beyond the annotation surface.

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?

Front-loaded with the core behavior in the first sentence, followed by side effects and prerequisites. It is dense with parenthetical clauses but nearly every clause carries decision-relevant information.

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

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

For a 10-parameter, non-idempotent, spending tool, the description covers trigger semantics, side effects, termination conditions, auth requirement, and pre-call confirmation. An output schema exists, so return values need not be described.

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 baseline is 3, but the description adds real meaning: `unitPrice` is a per-unit cap rather than a fixed price, `endActiveAt` is the stopping condition, and `limitBudgetInSun` is the recommended safety parameter. Minor gaps remain (no discussion of startActiveAt or resourceType trade-offs).

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 a specific verb and resource ('Create a rule that automatically buys...') plus the exact trigger condition (remaining resource below threshold) and payer source (TronSave internal balance). This clearly distinguishes it from the sibling update/delete/list auto-buy 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?

Gives explicit pre-call guidance: confirm receiver, amounts, price cap and limits with the user, and prefer setting `limitBudgetInSun`. It does not name the alternative (e.g. update_auto_buy_setting vs create) explicitly, but the 'each call adds a rule' note implies when a different tool is needed.

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, the description discloses that the tool spends funds, requires user confirmation, has different authentication requirements per payment method, returns a success flag with `orderId`, and is not idempotent. It also warns that a timeout should be verified before retrying to avoid duplicate orders, adding substantial safety 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 is dense but front-loaded with purpose and the critical funds-spending warning. Every sentence carries operational value, with no filler, despite covering a complex mutation with multiple payment paths.

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

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

The tool is a complex, non-idempotent mutation with nested payment transaction requirements, and the description covers authentication modes, estimate dependency, return checking, and retry safety. An output schema exists, and the description still usefully highlights the `success` field and verification path.

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 already 100%, so the baseline is 3. The description adds useful cross-parameter semantics: price and amount are in SUN, not TRX; values should come from the latest estimate; and `paymentMethod` changes whether login or a wallet-signed transaction is 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?

The description states a specific verb and resource: create a buy order for ENERGY/BANDWIDTH delegated to `orderReceiver`. It clearly distinguishes the operation from read-only estimation and order inspection siblings, but does not explicitly contrast it with `tronsave_internal_order_create` or `tronsave_bulk_create_internal_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?

It gives strong operational guidance: confirm with the user before spending funds, take values from the latest `tronsave_estimate_buy_resource`, and choose `internal` vs `onchain` based on login and signed-transaction requirements. It also explains the timeout retry procedure, though it does not explicitly name when to prefer the internal or bulk order-creation 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 already declare destructiveHint and idempotentHint, but the description adds real value beyond them: what destruction means in the domain ('stops all future executions matching that rule'), irreversibility, the exact idempotency behavior (success on a non-existent id), and an auth requirement ('Requires a wallet signature identity'). No contradiction with the annotation 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?

Four tight clauses, each doing distinct work (action, consequence, idempotency, auth), with the destructive verb front-loaded before any secondary guidance. No filler or restatement of the title.

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

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

For a single-parameter destructive tool with full annotation coverage and an output schema, nothing an agent needs is missing: safety profile, irreversibility, idempotency, auth, and a sequencing recommendation are all present.

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

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

Schema coverage is 100% and the single parameter is already documented as an auto-buy setting id of type `MObjectId`. The description repeats that identifier and type but adds no new constraints, format, or edge-case semantics, so the baseline 3 is appropriate.

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

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

States a specific verb ('Permanently delete'), a precisely scoped resource ('one auto-buy rule by `id`'), and the domain type (`MObjectId`). It is clearly distinguishable from `tronsave_update_auto_buy_setting` and the list/get siblings without opening a schema.

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 routes the agent: list rules first with `tronsave_get_user_auto_setting`, and prefer disabling/updating when reversibility is wanted. That names both a prerequisite and an alternative tool with the condition that selects 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/idempotentHint, so the bar is lower; the description still adds real value by stating no session is required and that backend rate limits apply — neither is derivable from the annotations. It also names the exact response fields and how they map onto create_order parameters, though it omits latency/rate-limit magnitude.

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?

Front-loads purpose, then the return shape, then defaults, then routing — a sensible order with no filler sentences. Slight redundancy in enumerating return fields that the output schema already defines, which keeps it from a 5.

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

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

For a 7-parameter read-only estimation tool with an output schema and full schema coverage, nothing an agent needs to call it correctly is missing: purpose, defaults, safety profile, rate-limit caveat, output mapping, and sibling routing are all present.

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

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

Schema coverage is 100%, so baseline is 3; the description earns a bump by restating the operational defaults (ENERGY, 100000 units / 1000 for BANDWIDTH, 900 s) in one place and clarifying that returned quote fields correspond to specific create_order inputs, which frames why those parameters matter.

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 a specific verb and resource (quote price and availability for ENERGY/BANDWIDTH) plus the precondition 'for a receiver address before placing an order'. This distinguishes it cleanly from tronsave_create_order, tronsave_list_order_books, and tronsave_get_min_price without requiring schema inspection.

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 positions the tool as a pre-order quote step, and routes two adjacent needs to named siblings: 'For order-book depth use tronsave_list_order_books; for the minimum unit price only use tronsave_get_min_price.' Both when-to-use and alternative selection are covered.

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 and idempotentHint, and the description reinforces this with "nothing is submitted" plus the 404-when-nothing-staked failure mode and public accessibility. It does not discuss snapshot volatility or whether the estimate expires, which would matter for a quote-style tool.

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

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

Two tight sentences: the first front-loads what is returned, the second carries the non-mutation and error behavior. No filler and no repetition of the title.

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

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

With an output schema present, return values need no further explanation, and annotations cover the safety profile. The description still supplies the failure mode and the non-submitting guarantee, so nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the requester pattern and meaning are already documented in the schema. The description adds only that the entire stake is estimated with no filtering options, which is a marginal but real clarification of scope.

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 pairs a specific verb (estimate) with a specific resource (flash unstaking an address's entire staked TRX) and names the outputs the estimate covers. It is clearly distinguishable from siblings like tronsave_get_flash_unstake_request and tronsave_list_flash_unstake_orders, which read existing state rather than projecting a payout.

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?

"Nothing is submitted. Public (any address), read-only" establishes the pre-flight/quote use case, and the 404 condition tells the agent when the call will fail. It stops short of explicitly naming the alternative (e.g., the actual unstake-request tool) or stating when not to call 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?

Adds substantial context beyond the annotations: the response shape ('Returns `data` containing the issued key'), handling policy ('show it to the user once... do not repeat it in later messages'), the invalidation caveat ('may invalidate the previous one per backend policy'), and rejection conditions ('unauthorized sessions or policy checks may reject issuance'). This goes well past the destructive/non-idempotent hints already in the annotations.

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

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

Front-loaded with the action and the critical output-handling instruction; four dense sentences with no filler. Slightly packed with several distinct cautions, but each one carries operational weight.

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?

Even though an output schema exists, the description supplies the one thing the schema cannot: the secret-handling protocol and the fact that repeated calls may invalidate prior keys. For a zero-param secret-minting tool, nothing an agent needs before invoking it is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. It correctly says nothing extraneous about inputs.

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 a specific verb and resource ('Generate a new internal API key credential for the current user'), leaving no ambiguity about what the call produces. It is clearly distinguishable from the sibling tronsave_revoke_api_key (opposite action) and from login/session 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?

Explains the precondition ('Requires a wallet signature identity') but never states when an agent should mint a key versus use an existing one, nor when to prefer alternatives such as tronsave_login or tronsave_get_session_status. Usage is implied by the purpose rather than explicitly guided.

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 readOnly, idempotent and openWorld, so the safety profile is covered. The description adds genuine value beyond that: it is public, requires no login, accepts any address, and returns TRX as a SUN string, which is the kind of unit detail an agent would otherwise guess at.

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 short sentences, front-loaded with what is read, followed by when to use it and the access constraint. No filler or restatement of the title.

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

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

An output schema exists and annotations cover safety, so the description only needed to establish scope, access model and result shape, all of which it does. It even clarifies the unit of the balance field, leaving nothing an agent needs missing.

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

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

There is only one parameter and schema coverage is 100%, with the base58 pattern documented in the schema. The description's phrase 'any address' usefully confirms there is no ownership restriction, but it adds no format or validation detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource: reads on-chain staked and delegatable ENERGY/BANDWIDTH plus the TRX balance of a TRON address. That is clearly distinct from the sibling set, which is dominated by order, delegation and account-settings tools, and the 'on-chain' qualifier separates it from internal account lookups.

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?

Gives concrete usage context ('check whether a wallet can sell, or how much resource it holds') and removes a common blocker by noting it is public and needs no login. It does not explicitly name a sibling alternative (e.g. estimate_buy_resource) for the resource-planning case, so it stops short of full routing 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 declare read-only, idempotent, and open-world behavior, while the description adds useful specifics: null when no bot is registered, the token is never returned, and a wallet signature is required. It does not explain rate limits or whether timeFilterBy affects all statistics, so it stops short of maximum.

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 resource and returned fields are front-loaded, followed by concise null, token, and auth notes. 'Read-only' repeats the annotation and is slightly redundant, but the description remains tight overall.

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

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

An output schema exists, so the description need not explain return values in full. It still covers the key operational facts an agent needs: wallet-signature requirement, null-bot case, and non-disclosure of the bot token.

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

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

Schema description coverage is 100% and the sole parameter's enum is documented in the schema. The description never mentions timeFilterBy or how the statistics window changes the returned data, so the schema does the parameter work.

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 the specific verb 'Read' and resource 'logged-in user's Telegram agency bot (resale bot)' and enumerates the returned fields. No sibling tool covers this resource, so the purpose is unambiguous without needing sibling 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?

Clarifies that it reads the logged-in user's own agency bot and notes the wallet-signature identity prerequisite. There are no explicit when-not conditions or alternatives, but no sibling overlaps enough to require them.

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 readOnly/idempotent/openWorld, and the description adds real context beyond them: the required credential (`tronsave_login` api-key or signature mode, or `Authorization: ApiKey` header), the rule that keys must never be passed as tool arguments and are forwarded server-side, and the 10 TRX minimum. That is exactly the auth and constraint disclosure an agent needs before calling.

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 purpose and trigger are front-loaded, and the auth and constraint sentences carry actionable information. The closing 'Read-only operation' duplicates the readOnlyHint annotation and could be dropped, but overall the length is justified for a tool with a non-obvious auth model.

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?

An output schema exists so return values need not be explained, and the description covers everything else an agent needs: what the tool returns conceptually (a deposit address), the credential path, and the deposit constraints. Nothing material is missing for 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?

Schema coverage is 100% and `amountTrx` is already documented with its minimum of 10, so the description's 'Minimum deposit amount is 10 TRX' largely restates structured data. It adds the TRX-only currency constraint but no further semantics for the amount value.

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 a specific verb ('Fetches') and a precise resource ('the specific deposit address for the TronSave internal account'), and no sibling tool covers deposit addresses, so it is unambiguous against the list. The scope (internal account, TRX) further narrows it.

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?

Explicit trigger conditions are given: 'Trigger this tool if the user asks for a deposit address or needs to top up their TronSave TRX balance,' plus the constraint that it is TRX-only. It does not name an alternative tool or state when not to use it, which is the only gap.

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 readOnly, idempotent, and openWorld. The description adds useful behavioral context beyond that: the response includes request state, payout state, amounts and release progress, and `request` is null when none exists. It also notes the authentication requirement, which is not captured in the annotations.

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

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

Two sentences, both front-loaded and information-dense. The core purpose, response contents, null case, auth requirement, and read-only nature are all communicated without any filler.

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

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

Given the zero-parameter schema, existing output schema, and annotations covering safety/idempotency, the description is complete. It adds the essential auth prerequisite, clarifies the null case, and summarizes returned fields relevant to the user's decision. No material gaps remain.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter detail and instead focuses on response semantics and auth requirements.

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 a specific verb ('Read') and resource ('the logged-in user's flash-unstake request') and explains the concept (selling staked TRX early for immediate payout). It is clear what is returned, but it does not explicitly name the sibling `tronsave_list_flash_unstake_orders` to delineate the single-request vs. list distinction.

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

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

Provides a prerequisite ('Requires a wallet signature identity') and the read-only nature, which implies when it can be used. However, it does not state when to prefer this over alternatives like `tronsave_list_flash_unstake_orders` or `tronsave_estimate_flash_unstake`, nor any explicit exclusions.

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

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

Annotations already declare readOnly/openWorld/idempotent, and the description adds real context beyond them: the authentication path, the fact that the server forwards the key from the session rather than arguments, and that API keys in the payload are masked. It restates "Read-only" redundantly and says nothing about failure modes when no internal account exists, so it stops short of a 5.

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?

Front-loaded with the purpose, then auth, then return shape, then a safety note — each sentence carries distinct information. The closing "Read-only" is the only mild redundancy with the annotations.

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

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

An output schema exists, yet the description still sketches the payload shape and masking behavior, and annotations already cover the safety profile. Auth mode selection and the no-argument rule are covered, leaving nothing an agent needs to make the call correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to convey; baseline is 4. The description usefully clarifies that credentials come from the session/header, which preempts an agent inventing an api-key argument.

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 a specific verb (retrieve) and a specific resource (Tronsave internal account profile for the current session), and names the returned fields (wallet/represent address, balances, deposit address), which implicitly separates it from siblings like get_deposit_address and get_account_resources. It never names those siblings explicitly, so an agent must infer the boundary against tronsave_get_user_info.

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?

"Use when the user needs their linked address or balance" gives a clear triggering condition, and the auth prerequisites (tronsave_login api-key mode or an Authorization header, never a tool argument) tell the agent whether the call can succeed. No explicit exclusions or named alternatives are given, keeping it below a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds value beyond that by calling the data public and disclosing a refresh cadence of about one TRON block (3 s), which is exactly the kind of freshness context annotations cannot express.

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, no filler. The returned fields are front-loaded, followed by the usage cue and then the access/freshness constraints, which is the right order for an agent deciding whether to call it.

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

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

With an output schema present, the description does not need to explain return structure, and it covers the remaining context an agent needs: public read-only access and roughly 3-second data freshness. The only gap is the absence of explicit sibling routing among the many price/market 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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description adds no parameter detail, but none is 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?

States a specific verb ('Read') and resource ('TronSave market summary') and enumerates exactly what is returned: available/listed ENERGY and BANDWIDTH, pooled seller count, and seller APY. It does not explicitly name sibling tools like get_price_table or get_min_price, so an agent cannot tell from the description alone which market-reading tool to prefer.

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?

Gives a clear usage context: 'Use for a quick "how is the market" answer before pricing.' That tells the agent when the tool is appropriate without naming alternatives or exclusions, which is the boundary between a 4 and a 5.

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

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

Annotations already declare read-only, idempotent, and open-world behavior. The description adds useful disclosure: no login required, GraphQL source `market.estimateMinPrice`, return shape `{ minPrice }`, and unit semantics that vary with `durationSec`.

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 dense sentences front-load the purpose, return value, source, and alternatives. There is no filler, and the most decision-relevant information appears first.

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?

An output schema exists, so return values need not be fully documented. The description covers auth, idempotency, source, unit semantics, optional address behavior, and how it relates to sibling tools, making it complete for 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?

Schema coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema by explaining that the returned price is in SUN per resource unit, becomes per-day when `durationSec` >= 86400, and that `address` only scopes context when supported by the API.

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

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

The description uses the specific verb 'Quote' with the resource 'minimum unit price for a buy,' and explicitly distinguishes this tool from `tronsave_estimate_buy_resource` and `tronsave_list_order_books` by stating their complementary purposes.

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

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

It clearly routes the agent toward sibling tools for full buy quotes and order-book depth, implying this tool is for the narrower minimum-price quote. However, it does not explicitly state exclusion conditions such as when not to use it or whether it is a prerequisite for a buy flow.

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 carry readOnlyHint, idempotentHint, and openWorldHint, and the description restates two of them — redundant but harmless. The real added value is "Requires a wallet signature identity," an auth requirement not expressible in the annotations. It stops short of saying what happens on a missing/foreign order (not-found vs permission error).

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 short sentences, front-loaded with the core action and result, then usage, then auth and safety. Every sentence carries distinct information; only the trailing "Read-only and idempotent" duplicates annotations.

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

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

An output schema exists, so return values need not be explained, and the description still characterizes the payload as a "full snapshot." Combined with auth and pre-mutation sequencing guidance, it covers what an agent needs to call it. Missing only failure/not-found behavior and whether the signing wallet must own the order.

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

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

Schema coverage is 100% and the single `id` parameter is already documented in the schema as an MObjectId with its purpose spelled out. The description only echoes "by `id`" and adds no format, ownership, or lookup semantics beyond the schema. Baseline 3 is appropriate for a one-parameter tool whose schema does the work.

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 a specific verb and resource ("Read one order by `id`") plus the order-type scope it covers (NORMAL, FAST, EXTEND) and what it returns (full snapshot). It differentiates from the list tool implicitly via "one order," but never contrasts itself with the similarly-named `tronsave_internal_order_details`, which is the sibling most likely to be confused with it.

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?

Gives an explicit usage condition: use as source of truth before `tronsave_update_order`, `tronsave_sell_order_manual`, or `tronsave_cancel_order` to avoid stale state. That is concrete and actionable. It does not state when-not to use it or name the alternative read tools an agent could otherwise pick.

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 and idempotentHint, so the safety profile is covered; the description adds genuinely useful behavioral context: the per-day pricing rule for durations ≥1 day with a worked example ('30d' at 40 SUN = 40 x 30 per unit). 'Public, read-only' partly restates the annotations, which keeps it from a 5.

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?

Front-loads the core purpose, then the matrix semantics, then the pricing caveat, then the alternative-tool routing. No filler sentences; every clause carries information an agent needs.

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?

Even though an output schema exists, the description adds the interpretive key (matrix indexing and per-day pricing) that the schema alone may not make obvious. Combined with the routing guidance and read-only note, an agent has everything needed to select and call it correctly.

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

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

Schema coverage is only 50%, so the description must compensate: it conveys that the tool takes a resource type (ENERGY or BANDWIDTH) and clarifies how pricing scales with amounts and durations, which is the core semantic of the output params. The optional `address` parameter is left entirely to the schema, a small residual gap.

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 a specific verb (read) and resource (price grid) scoped to ENERGY/BANDWIDTH, and explains the matrix shape `prices[i][j]` in terms of amounts and durations. It is clearly distinguishable from the sibling quote tool by being a comparison grid rather than an exact estimate.

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 says to use this to compare cost across amounts and durations in one call, and names `tronsave_estimate_buy_resource` as the alternative for an exact quote. This gives both the when-to-use and the when-to-use-something-else.

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 openWorldHint=true, so the description does not need to carry the safety profile alone. It still adds useful context by stating that a wallet signature identity is required and by naming the referral statuses (PENDING/ACTIVE) and SUN-denominated bonus 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?

The purpose and auth requirement are front-loaded, and every clause adds concrete return-field information. There is no filler or redundant restatement of the tool name.

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

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

The description covers the important behavioral context an agent needs: wallet signature identity, read-only nature, returned field families, and list statuses. With an output schema present and annotations already covering safety, the remaining gaps around pagination across lists are relatively minor.

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 67%, with limit and filterBy already described in the schema and offset undocumented. The description mentions the referral list and PENDING/ACTIVE statuses, which gives some context for filterBy, but it does not explain limit, offset, or how pagination applies across the multiple lists returned.

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 gives a specific verb and resource ('Read the logged-in user's referral status') and then enumerates the exact fields returned: referral code, sponsor, counts, bonuses, rank, list statuses, and payouts. That level of specificity distinguishes it from nearby sibling reads such as user info, session status, and permissions.

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

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

It implies when to use it by saying it reads the logged-in user's referral status and requires a wallet signature identity, which is a useful prerequisite. However, it names no alternative sibling tool and gives no explicit when-not-to-use guidance, so routing still requires inference.

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 readOnlyHint/idempotentHint annotations, the description discloses the auth requirement (wallet signature identity) and, importantly, that the totals are lifetime while the chart is daily — implying the time filter scopes only the chart. 'Read-only' merely restates the annotation, and no error/permission-failure behavior is described, so it stops short of 5.

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 tight sentences, front-loaded with what is returned, followed by the use case and the prerequisite. No filler and nothing repeated.

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?

An output schema exists, so return shape need not be spelled out; annotations cover the safety profile; the description covers identity requirements and the totals-vs-chart distinction. Nothing an agent needs in order to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents both enums, making 3 the floor. The description adds real meaning on top: framing the parameters around a lifetime-totals-plus-daily-chart output clarifies that resourceType and the time window affect the chart rather than the lifetime aggregates.

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

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

The description uses a specific verb and resource: 'Read the logged-in seller's lifetime totals (delegations, resource delegated, TRX earned, average price per resource) and a daily earnings chart.' It even enumerates the chart's breakdown dimensions (auto, manual, exclusive, extend), so an agent knows exactly what comes back. It does not, however, name or contrast itself with any sibling (e.g. tronsave_get_user_info or tronsave_list_delegations), which keeps it at 4 rather than 5.

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

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

'Use for "how much did I earn" questions' supplies a concrete triggering intent, and 'Requires a wallet signature identity' states the prerequisite before the call is attempted. There is no explicit when-not or named alternative, but the usage context is clear enough to route an agent reliably.

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 context beyond the annotations by disclosing that the check is local ('without calling TronSave'), which reinforces openWorldHint=false, and by naming the specific error codes (SESSION_REQUIRED, INVALID_SESSION_TYPE) that make this call appropriate. It does not cover rate limits or fallback behavior, but the safety profile is already fully carried by the readOnly/idempotent 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 filler, with the 'without calling TronSave' qualifier and the field list front-loaded before the usage instruction. Every clause carries information an agent can act on.

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-only status probe with an output schema and full annotations, nothing an agent needs is missing: what it reports, when to call it, and that it costs no remote call. The field enumeration is optional but harmless reinforcement of the 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The enumerated field list describes return values rather than inputs and is largely redundant with the output 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 a specific verb and resource ('Report the current authentication state') and enumerates exactly what is returned (authMode, source, walletAddress, hasInternalApiKey, expiresAt, network, available tool groups), which clearly separates it from siblings like tronsave_login, tronsave_logout, or tronsave_get_user_info.

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?

Gives explicit trigger conditions: 'Call this first when unsure whether to log in' and 'after SESSION_REQUIRED / INVALID_SESSION_TYPE errors.' It does not name an alternative tool to use instead of this one in other situations, so it stops just short of a full when/when-not/alternatives statement.

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/idempotentHint, and the description adds useful context beyond them: no auth is required and there are no side effects on the account. It also discloses the exact composite format the downstream login call expects. It does not mention expiry or how long the message remains valid, which would be the remaining behavioral detail an agent might need.

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?

Front-loaded with the flow position, then the return value, then the action to take. Three dense sentences, each carrying distinct operational information, with no padding.

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?

Even though an output schema exists, the description summarizes the return (`message`, `timestamp`) and explains how that output feeds the next tool, which is the non-obvious part. Combined with the no-auth/no-side-effects note, an agent has everything needed to call it and continue the flow.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly focuses on the return shape and downstream call convention rather than inventing parameter guidance.

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?

Opens with a precise role statement ('Step 1 of wallet login') and states exactly what the tool returns (`{ message, timestamp }`). The login-flow framing distinguishes it cleanly from `tronsave_login` and `tronsave_get_session_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?

Gives an explicit sequence: obtain message, ask the user to sign with a named wallet (TronWeb signMessageV2, TronLink), then call `tronsave_login` with the `"<signature>_<timestamp>"` format. It even names the alternative accepted input (plain decimal timestamp), so no inference is required.

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, idempotentHint and openWorldHint, so safety and idempotence are covered. 'Public, read-only' largely restates that rather than adding new behavioral context such as rate limits, freshness/staleness of block data, or caching. The field enumeration adds value but it describes output content more than 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: the first front-loads the resource and its contents, the second states purpose and access level. No filler, no repetition beyond the useful access note.

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

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

With an output schema present, the description needn't explain return shapes, and it doesn't try to. Zero params, rich annotations, and a clear statement of contents and intended use make this complete for a read-only aggregate 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-arg tool applies. The description correctly makes no false claims about inputs.

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 a specific verb (Read) and resource (TronSave and TRON protocol parameters) and enumerates exactly what comes back: latest block, minimum buy amounts, burn rates, deposit address, max lock period, USDT transfer energy cost. An agent knows precisely what this returns. It stops short of naming how it differs from close siblings like get_min_price, get_price_table or get_market_overview, which overlap in subject matter.

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?

'Use to size purchases (minimums) and to compare renting with burning TRX' gives concrete decision contexts rather than a generic 'use when needed'. It lacks explicit exclusions, though — nothing tells the agent when to prefer get_market_overview or get_min_price instead of this aggregate.

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 readOnly/idempotent/openWorld, yet the description still adds two non-obvious behaviors: auth needs a wallet signature identity and `setting` is null when Telegram is not linked. That null-return contract is exactly the kind of thing structured fields do not convey.

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

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

Two sentences, front-loaded with the resource and its contents, then the null case and auth requirement. No filler or restatement of the title.

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

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

An output schema exists, so return values need no explanation, yet the description helpfully previews the seller/buyer field groups and the null case. Auth requirement plus null semantics round out everything needed to call a parameterless read correctly.

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

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

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The mention of `setting` refers to the response shape rather than an input, which is mildly confusing in a parameter context but harmless.

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 (Read) plus precise resource (Telegram alert filters of the logged-in user), and it enumerates the two filter groups covered. It never names the write counterpart tronsave_update_telegram_notify_setting or tronsave_list_notifications, so sibling routing depends on the tool name rather than the 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?

"Requires a wallet signature identity" establishes a prerequisite, and "read-only" implies this is the inspection step. However, it never says when to choose this over tronsave_update_telegram_notify_setting or tronsave_list_notifications, and offers no exclusions.

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

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

Annotations already declare read-only, idempotent, and open-world behavior, but the description adds important context beyond them: it requires a wallet signature identity and returns the complete `autoSettings` object. The overwrite-avoidance warning provides a concrete operational reason to call it first.

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

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

The description is three tight sentences. The core action and return value come first, followed by the critical usage ordering and the authentication prerequisite, with no wasted phrasing.

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

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

Given that an output schema exists, the description need not enumerate return fields, and it still notes that the full `autoSettings` object is returned. With annotations and schema handling safety and structure, the description covers purpose, prerequisite authentication, and workflow placement completely.

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

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

The tool takes zero parameters, so per the baseline rule this scores 4. There is no parameter detail to add, and the description appropriately focuses on the return value and call sequencing 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?

The description states a specific verb and resource: read the current user's auto-sell configuration (`autoSettings`). It clearly distinguishes this read operation from the sibling write tools `tronsave_register_auto_sell` and `tronsave_update_auto_sell_setting`.

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

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

It explicitly tells the agent when to call this tool: before registering or updating auto-sell settings, to avoid overwriting unintended fields. It names the two relevant alternative actions and explains the ordering constraint, leaving little ambiguity.

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, idempotentHint, and openWorldHint; the description restates read-only/idempotent plus adds auth requirement (wallet signature identity) and nullability semantics for info/internalAccount, which is useful. But the nullability and masking details are return-value detail arguably already carried by the output schema, and no rate limits or failure modes are described.

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

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

Front-loads the purpose, then return shape, then prerequisites, then alternatives – a sensible order. It is dense but slightly over-detailed on return-value internals that the output schema already covers.

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?

An output schema exists and annotations cover safety, so the description needn't explain returns; it covers prerequisites and alternatives. The only miss is any note on auth failure behavior, which is minor.

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?

Zero parameters, so the baseline is 4; nothing in the description contradicts or muddies the empty 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 a specific verb+resource: reads the authenticated user's profile and linked internal account. It names the fields returned and contrasts directly with tronsave_get_user_auto_setting and tronsave_get_user_permissions, so an agent can distinguish it from 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?

Explicitly routes to two alternatives with the condition (when the full profile is unnecessary), plus a prerequisite (wallet signature identity). This is genuine when-to-use / when-not 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 declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description adds the non-obvious prerequisite that a wallet signature identity is required. The closing 'Read-only and idempotent' sentence merely restates the annotations, adding no new information.

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 short, front-loaded sentences: purpose first, return shape second, usage prerequisite third. The final clause about being read-only and idempotent duplicates the annotations and could be dropped without loss.

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?

An output schema exists, yet the description still names the key return field for quick scanning, and it covers the auth prerequisite and the pre-mutation check an agent needs before acting. Nothing required to invoke it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. It correctly does not invent parameter guidance that the empty schema contradicts.

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 a specific verb and resource: reads the enabled permission operations (autoSettings.permitOperations) for the authenticated user. It is clearly distinct from siblings like tronsave_get_user_auto_setting and tronsave_get_user_info by naming the exact setting field it returns.

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 says to call it before mutating auto-sell or auto-buy rules to confirm the action is allowed, which routes the agent away from blind mutation via tronsave_update_auto_sell_setting / tronsave_update_auto_buy_setting. It does not state any when-not-to-use condition, but the scope is narrow enough that this is a minor gap.

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 a non-read-only, non-idempotent, open-world mutation, and the description goes beyond them by naming the concrete side effect (creates an extension order, may commit TRX from the internal account) and the auth model (session api-key via `tronsave_login` or `Authorization: ApiKey` header, keys never passed as tool args). It stops short of covering failure modes or retry/idempotency behavior for a non-idempotent write, which is the only meaningful gap.

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

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

Purpose and endpoint come first, then auth, then side effects, then the data-sourcing rule — a sensible front-to-back order with no filler. It is on the dense side, packing auth, effects, and sequencing into a single paragraph, but nearly every clause carries actionable information.

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

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

For a 3-parameter mutation with an output schema, the description covers the operation, the required auth path, the side effect, the data-fetching dependency, and the sibling trap. Return values need not be explained since an output schema exists, so nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and the field-level descriptions already explain types, address patterns, and epoch-seconds semantics, so the baseline is 3. The prose adds real value by constraining `extendData` to the REST contract shape and requiring rows be echoed unchanged from the STEP 1 call, which prevents a plausible agent error.

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 a specific verb and resource ("Submit an extension request for existing delegated resources") and anchors it to the concrete REST endpoint `POST /v2/extend-request`. It explicitly distinguishes itself from the two nearest siblings, `tronsave_internal_extend_delegates` (source of input) and `tronsave_list_extendable_delegates` (GraphQL, market discovery only).

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?

Gives an explicit two-step workflow: obtain `extendData` from `tronsave_internal_extend_delegates` (STEP 1) and pass rows unchanged. It also states a negative rule — do not copy rows from `tronsave_list_extendable_delegates` because the payload shape differs — which is exactly the kind of when-not guidance an agent needs.

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, it discloses the authentication requirements, warns never to pass API keys as tool arguments, explains server-side key forwarding, and clarifies that the operation is read-only and does not submit anything. It also adds the important freshness constraint that pricing/availability changes within seconds and that `extendData` must be passed unchanged.

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 purpose is front-loaded in the first sentence, followed by auth, workflow placement, read-only status, and freshness guidance. Every sentence adds operational value with no redundant restatement.

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

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

With an output schema present, the description does not need to enumerate return fields, and it already covers the critical context: authentication, workflow sequencing, read-only behavior, and freshness. Given the rich schema and annotations, this is complete for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description reinforces the receiver and extendData concepts but does not add meaningful syntax or constraints beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

It states a specific verb and resource: return extendable delegations plus an `extendData` payload for the extension flow. The internal API key requirement and the step-1 relationship to `tronsave_internal_create_extend_request` distinguish it from the general list 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?

It explicitly says to use this as STEP 1 before `tronsave_internal_create_extend_request` when extending existing delegation time, and adds a freshness rule to run immediately before extending. The read-only clause also makes clear it is not the submission step.

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?

Goes well beyond the readOnly/idempotent annotations: it specifies the auth mechanism (session `tronsave_login` api-key mode or `Authorization: ApiKey` header), an explicit security rule ('Never pass API keys as tool arguments; the server forwards the key'), and a concrete staleness trait ('live market depth can change roughly every 3 seconds (one TRON block)'). These are behavioral facts an agent cannot derive from 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?

Front-loaded with the purpose, then auth, then usage, then freshness — a sensible ordering for an agent parsing top-down. It is dense but nearly every clause carries operational value; only the restated 'Read-only' overlaps with the readOnlyHint annotation.

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

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

With an output schema present it correctly omits return-value explanation, and it fully covers the auth and freshness concerns that matter for this open-world read tool. The one real hole is sibling disambiguation against `tronsave_list_order_books` and `tronsave_get_price_table`, which an agent would need in this crowded namespace.

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

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

Schema description coverage is 100%, so all four parameters (address, durationSec, resourceType, minDelegateAmount) are already documented in the schema; the baseline of 3 applies. The description adds only that the book covers ENERGY or BANDWIDTH, which the enum already conveys, and adds nothing about how duration or minDelegateAmount shape the returned tiers.

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 a specific verb and resource ('Return the current TronSave market depth/price tiers for ENERGY or BANDWIDTH') and names the transport ('via the api-key REST endpoint'), which is unusually precise. It does not, however, distinguish itself from the very similarly shaped siblings `tronsave_list_order_books`, `tronsave_get_price_table`, and `tronsave_get_market_overview`, leaving real ambiguity about which book call to pick.

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?

Gives clear sequencing guidance: 'Use before `tronsave_internal_order_create` or `tronsave_internal_order_estimate` when the user needs live prices or liquidity,' plus a re-read instruction before placing an order. It stops short of exclusions — nothing says when to prefer `tronsave_get_price_table` or `tronsave_list_order_books` instead.

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 it discloses the financial side effect (spends internal TRX balance, creates a live order), the non-idempotency consequence (each call places a new order), the staleness risk that can cause a revert, and the credential-forwarding model (server forwards the key; never pass keys as arguments). This is materially more than readOnlyHint/idempotentHint convey.

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?

Front-loaded with what the tool does, then auth, then side effects, then sibling routing, then the estimate caveat, then return shape — a logical order with no filler. It is dense and long-ish, but nearly every clause carries an actionable constraint.

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 a mutation tool with 7 params including a nested options object, an output schema, and a confusingly similar sibling, the description covers auth, side effects, the alternative tool, the pre-call estimate dependency, and the return value. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning for `unitPrice` by tying it to a just-refreshed estimate rather than any stale quote. It does not touch the nested `options` guards, which the schema already documents well.

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 a specific verb+resource: place a new buy order for ENERGY or BANDWIDTH, paid from the internal account balance. It also distinguishes itself from the near-identical sibling `tronsave_create_order` by naming the api-key/internal path versus the signature-session market path.

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?

Gives explicit routing (use `tronsave_create_order` for signature-session market orders), explicit auth prerequisites (api-key mode or signature mode with internal account), and an operational rule: always derive `unitPrice` from a fresh `tronsave_internal_order_estimate` immediately before submitting.

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 readOnlyHint/idempotentHint already covering the safety profile, the description adds genuinely new behavior: required auth mode (`tronsave_login` api-key or signature mode with an internal account), the client-header alternative, an explicit prohibition on passing keys as arguments with the server-side forwarding explained, and a freshness caveat about order state changing within seconds.

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?

Front-loaded with purpose, then auth, then usage, then a labeled FRESHNESS clause. Every sentence carries distinct information and there is 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?

An output schema exists so return values need no explanation, and auth, usage, and staleness are all covered. Only failure behavior (e.g., wrong or missing key) is left implicit, a minor omission for a one-parameter read.

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

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

Schema coverage is 100% and the single `orderId` parameter is already documented with type and format in the schema, so the description only echoes the semantics ('by order ID'). Its useful contribution is the internal-account scoping, but it adds no syntax or format detail beyond the schema's example.

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 a specific verb and resource ('Fetch full details for one internal-account order by order ID') and scopes it to internal-account orders, which distinguishes it from the public `tronsave_get_order`, `tronsave_list_orders`, and `tronsave_internal_order_history` 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?

Gives concrete trigger conditions: monitoring fulfillment after `tronsave_internal_order_create`, or a user asking for status on a specific order id, plus a decision rule ('re-read immediately before acting'). It stops short of explicitly excluding overlapping siblings like `tronsave_internal_order_history`, which is the only real gap.

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 readOnly/idempotent/openWorld, and the description adds real context on top: the auth model (internal API key via tronsave_login or Authorization header), the rule never to pass keys as tool arguments, and the ~3-second price volatility. That volatility detail is decision-relevant behavior an agent could not infer 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?

Front-loaded with purpose, then auth, then usage, then a clearly labelled FRESHNESS block. Dense but nearly every sentence carries operational weight; the auth paragraph is slightly verbose relative to the rest.

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

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

For a 7-parameter read-only estimate with a full output schema, the description covers what an agent needs: auth prerequisites, purpose, downstream handoff, and price staleness. The only gap is not stating how it differs from the non-internal tronsave_estimate_buy_resource.

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 every parameter including enums, defaults, and the nested options object is already documented in the schema. The description only reinforces unitPrice via the freshness note and adds nothing about resourceAmount, durationSec, or the partial-fill flag — 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?

States a specific verb and resource — estimate TRX cost and availability for a buy order — and qualifies it as the api-key internal-account variant, which separates it from the public estimate siblings. It also names the downstream tool (tronsave_internal_order_create) the result feeds into.

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?

Explicit when-to-use ('quote or price check') plus a concrete workflow rule: re-estimate immediately before creating the order because unitPrice/estimateTrx refresh roughly every 3 seconds. It does not explicitly exclude the sibling tronsave_estimate_buy_resource, so the alternative is only implied by the 'internal account' qualifier.

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 `readOnlyHint=true`, `idempotentHint=true`, and `openWorldHint=true`, so the description does not need to carry the full safety profile. It adds meaningful operational context beyond annotations: the internal API key requirement, the `Authorization: ApiKey <key>` header option, the instruction never to pass API keys as tool arguments, and the fact that the server forwards the key from session/header to TronSave.

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 front-loaded with the core operation and scope, then moves through auth requirements, usage guidance, read-only status, and sibling pairing. Every sentence adds useful operational context, and the auth warning is stated clearly without unnecessary repetition.

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

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

The tool has an output schema and fully documented input schema, so the description does not need to explain return values or parameter formats. It still covers the complexity that matters here: internal API key modes, header forwarding, pagination behavior, read-only status, and the related single-order tool.

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

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

Schema description coverage is 100%, so both `page` and `pageSize` are already well documented in the input schema. The description reinforces pagination and newest-first ordering but does not add syntax, defaults, or constraints beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: list paginated order history for the internal account linked to the API key, ordered newest first. It also distinguishes the tool from `tronsave_internal_order_details`, which is for a single order's full snapshot, so an agent can tell these apart without opening either schema.

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

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

The description gives clear usage context: use when the user asks about past purchases, fulfillment, payouts, or delegates on their internal account. It also names the natural alternative for single-order details, though it does not explicitly contrast this with broader order-list siblings such as `tronsave_list_orders`.

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 declare readOnlyHint, idempotentHint and openWorldHint, so safety and cacheability are covered. The description adds a genuinely new behavioral fact the annotations lack: an authenticated wallet signature identity is required. 'Read-only' merely restates an annotation and the field inventory duplicates the output schema, so it stops short of a 5.

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, both front-loaded: the core action and returned data come first, then the workflow routing and auth prerequisite. Every clause carries information 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?

An output schema exists, so return values need not be re-explained, and annotations cover the safety profile; the description still supplies the auth requirement and sibling workflow that an agent needs. It is only slightly short on paging/filtering guidance, which matters given the max-10 limit.

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 67%, with `limit`, `offset` and the `filterBy` enum documented in the schema. The description says nothing about pagination, page size limits, or when to use `filterBy`, so it adds no meaning beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('List the logged-in user's auto-buy rules') and enumerates the returned fields (receiver, resource, price cap, threshold, budget limits, totals, active state). It is clearly distinguishable from the create/update/delete auto-buy siblings named in the 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?

Explicitly directs the agent to call this before `tronsave_update_auto_buy_setting` or `tronsave_delete_auto_buy_setting` in order to obtain rule ids. It also states the prerequisite ('Requires a wallet signature identity'), so the agent knows both when and under what conditions to call 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 read-only, idempotent, and open-world. The description adds valuable context beyond that: it requires a wallet signature identity and returns results newest first, which are behavioral traits not 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, front-loaded with the core purpose and field list, then supplementary facts. No waste; every clause adds useful 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?

Output schema exists, so return details needn't be explained, but the description nonetheless lists key fields. Auth requirement is stated. For a filterable list tool with 5 params, it provides adequate context, though deeper filter explanations would help.

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 only 40%, so the description must compensate. It names the delegate type enum (AUTO, MANUAL, EXTEND, FAST) but does not explain timeFilterBy (All/D7/D30) or filterByResourceType (ENERGY/BANDWIDTH), though the enum values are largely self-explanatory.

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 a specific verb ('List'), resource ('delegations'), scope ('logged-in seller's'), and enumerates returned fields. An agent can distinguish this from siblings like list_extendable_delegates by the 'history' framing and field list, though no sibling is named explicitly.

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 by stating it lists the seller's delegation history, but offers no explicit when-to-use, when-not, or alternative tool guidance. With many similar list siblings (e.g., list_extendable_delegates, internal_order_history), this leaves room for confusion.

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, idempotentHint and openWorldHint, but the description adds real context beyond them: no login required, this is GraphQL market data only, and suggestData is server-side scoring rather than a live order. It stops short of describing pagination or result size limits for what is a list endpoint.

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 scope statement and the read-only/no-login facts are front-loaded, and each subsequent sentence (GraphQL vs REST, sibling routing) carries non-redundant information. It is dense with backticked identifiers, but nothing is 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 4-parameter read tool with an output schema and full annotation coverage, the description covers the remaining unknowns an agent would hit: auth requirements, data source (GraphQL vs REST), and how to proceed to the actual extension. Return values are correctly left to the 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 coverage is 100% and every parameter, including the nested suggestData object, is already richly documented in the schema. The description adds only the ENERGY|BANDWIDTH gloss and the framing of suggestData as a planning scenario, so the schema is doing the heavy lifting and the baseline of 3 applies.

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

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

The first sentence names a specific verb+resource (list extendable delegate candidates) and states the two key filters, receiver and resourceType, with the enum values inline. It also distinguishes itself from the write-path sibling tronsave_internal_create_extend_request, so an agent can tell the two apart without opening either schema.

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?

Explicit when-to-use (discovery/planning) and when-not (does NOT create orders or change on-chain state), plus the named alternative for the actual mutation and the note that the authenticated REST payload shape differs from this GraphQL response. It also states no login is required, which removes an otherwise likely blocker.

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 readOnly and idempotent, so the description's 'read-only' is redundant, but it adds real value by noting the tool is public and accepts any requester address (no auth requirement). It also specifies the returned fields including expiry in Unix seconds, which clarifies unit semantics beyond the structured data.

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

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

Two tight sentences with no filler; the core capability and return fields are front-loaded before the usage hint. Every clause carries information an agent can act on.

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

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

With annotations covering safety and an output schema covering the return shape, the description is nearly complete for a read-only listing tool. The one omission is the purpose/effect of the `resourceType` parameter, which an agent must guess at.

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 only 50%: `requester` is documented in the schema and echoed here, but `resourceType` (an ENERGY/BANDWIDTH enum filter) is left unexplained in both schema and description. The description does not compensate for that gap or clarify what filtering by resource type does.

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 a specific verb (list) and resource (receiver addresses with extendable delegations), plus the scoping condition ('delegations bought by `requester` which can still be extended'). The receiver focus implicitly distinguishes it from tronsave_list_extendable_delegates, which is the closest sibling.

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 says 'Use as the first step of an extension flow to find which receiver to extend', giving clear when-to-use context. It does not name the follow-up tools (e.g. tronsave_internal_create_extend_request) or state when to use the delegate-listing sibling instead, so guidance stops short of full routing.

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`, `idempotentHint`, and `openWorldHint`, so the safety profile is covered. The description adds meaningful field semantics beyond annotations: amounts are SUN-scaled and `estimateCompletionTime` is in seconds, and it clarifies what each lifecycle status means.

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

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

The description is short, front-loaded with the core action, and every clause adds value: the status meanings, the unit notes, and the access model. There is no filler or redundancy beyond the brief public/read-only reminder.

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

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

With an output schema present and annotations covering read-only/idempotent behavior, the description provides enough context to select and call the tool: status filters, unit semantics, and public access. Pagination behavior is left to the schema, which is acceptable.

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 67%, and the description adds substantial meaning beyond the schema's bare enum by explaining that `available` means open orders buyers can take, `ongoing` means being paid out, and `completed` is finished. It does not mention `limit` or `offset`, leaving pagination semantics to 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 states a specific verb and resource: browsing the flash-unstake market. It clearly explains the three order categories, which distinguishes it from the singular `tronsave_get_flash_unstake_request`, though it does not name any sibling tool explicitly.

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 category meanings imply when to select `available`, `ongoing`, or `completed`, giving useful filtering context. However, there is no explicit guidance on when to use this market-listing tool versus related tools like `tronsave_get_flash_unstake_request` or `tronsave_estimate_flash_unstake`.

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/idempotentHint/openWorldHint, so the bar is lower; the description still adds real context beyond them: newest-first ordering, that the response carries the current balance and deposit address, that amounts are SUN strings, and the wallet-signature auth requirement. It stops short of describing pagination 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?

Four short sentences, front-loaded with the resource and contents, then use case, then auth requirement. No filler, though the 'Read-only' trailing clause partly duplicates readOnlyHint.

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?

An output schema exists, so return shape needn't be spelled out, yet the description helpfully flags balance/deposit address and SUN units. Auth prerequisite is stated. The only meaningful omission is pagination guidance for limit/offset.

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 only 50% (limit has 'Default 20', offset has no description at all), and the description says nothing about pagination, page size caps, or offset semantics. It does not compensate for the gap it inherits from 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 a specific verb and resource: lists the TRX ledger of the logged-in user's internal account, and enumerates the entry types (deposits, order payments, refunds) plus ordering (newest first). This distinguishes it from order-centric siblings like tronsave_internal_order_history, though no sibling is named explicitly.

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?

'Use to reconcile spending after orders' gives one concrete scenario, and 'Requires a wallet signature identity' states a prerequisite. However, it never says when to prefer this over tronsave_internal_order_history or tronsave_list_orders, nor any exclusion conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: newest-first ordering, inclusion of unread count, and the wallet-signature identity requirement.

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 compact sentences, front-loaded with the core action, followed by usage and prerequisite. No wasted 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?

An output schema exists, so return formatting need not be explained, and the auth requirement is stated. However, with three parameters and only 33% schema coverage, the missing parameter guidance leaves the definition incomplete for 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?

Schema description coverage is only 33%: limit has a default note, but offset and unreadOnly are undocumented in the schema. The description does not compensate by explaining pagination, offset behavior, or what unreadOnly does, so parameter meaning remains largely unclear.

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 and resource: listing the logged-in user's notifications, with concrete notification categories and ordering. It clearly distinguishes a notification-list operation from sibling tools like tronsave_mark_notifications_read.

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

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

It gives a clear use case: following up on an order after creating it. It does not explicitly name alternatives such as tronsave_mark_notifications_read or explain when to use unread filtering versus full listing, but the primary context is clear.

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 repeats readOnlyHint and idempotentHint verbatim, which earns no credit since annotations already declare them. The one genuinely additive behavioral fact is 'No login required', a real auth disclosure; the bucket return shape is already covered by the output schema. Adequate but thin beyond the 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?

Three front-loaded sentences that lead with what is returned and then route to alternatives; no filler. The return-shape clause is mildly redundant with the output schema but still reads naturally.

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

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

With annotations covering the safety profile, an output schema covering return values, and 100% schema coverage on parameters, the description supplies the remaining gaps: auth requirement, the market-estimation use case, and sibling routing. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so all four parameters (including the enum for resourceType) are already documented in the schema. The description's mention of viewer address, minimum delegate amount, and duration merely restates those fields without adding syntax, defaults, or interaction rules. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Read market depth buckets for ENERGY or BANDWIDTH') plus the exact return shape `{ min, max, value }`. It also explicitly distinguishes itself from the similarly named siblings `tronsave_internal_order_book`, `tronsave_list_orders`, and `tronsave_get_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?

Gives an explicit when-to-use ('estimate market ranges before create/update decisions') and names two alternatives with the condition that selects each: `tronsave_estimate_buy_resource` for quote-style estimation and `tronsave_get_order` for a single concrete 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?

Annotations already declare readOnly/idempotent/openWorld, so the description earns credit for adding an auth prerequisite (api-key-only sessions cannot use isOnlyMyOrder) and for spelling out what ACTIVE vs COMPLETED mean in matching terms. It does not cover result ordering, rate limits, or pagination ceiling behavior (offset max 200 is only in the schema).

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

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

Front-loaded with the core action and paging cap, then filters, then the alternative. Slightly wasteful in that the full return shape is enumerated even though an output schema exists, and the status enum meanings duplicate the schema 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?

A read-only, zero-required-parameter list tool with annotations and an output schema needs exactly this: filter semantics, the auth caveat on one filter, paging bounds, and a pointer to the single-record sibling. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents all five parameters including enum meanings and the signature-identity caveat. The description largely restates those definitions and adds only the unit annotation for the output field unitPrice (SUN), so baseline 3 applies.

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

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

States a specific verb and resource ("Query the market order list") plus the paging constraint, and explicitly routes single-record reads to tronsave_get_order with an `id`. An agent can distinguish it from the order-book and single-order siblings without opening a schema.

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?

Gives clear usage context: paging via offset/limit, status filter semantics, and the prerequisite that isOnlyMyOrder requires a wallet signature identity. It names one alternative (tronsave_get_order for a single snapshot) but offers no guidance versus tronsave_list_order_books or the internal order-book 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 only flag non-read-only, non-idempotent and open-world; the description adds substantial context beyond that: the login is bound to `mcp-session-id` server-side and must not be re-passed, the signed timestamp has a server-side age limit (default 24h) with the named `SIGNATURE_EXPIRED` failure, and an internal API key may be auto-loaded as a side effect. The security guardrail ("Never ask the user for private keys or seed phrases") is exactly the kind of behavior an agent cannot infer from 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?

Purpose and the exclusive-or choice are front-loaded in the first clause, and every following sentence adds non-redundant information (session binding, expiry behavior, security rule). The return-shape sentence partially duplicates the existing output schema, and the single dense paragraph with semicolon-separated modes is harder to scan than a short bulleted split, but there is 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?

For an authentication entry point with two mutually exclusive credential paths, the description covers prerequisites (get the message first), side effects (API key auto-load, session binding), failure mode (SIGNATURE_EXPIRED), and the security constraint. Although an output schema exists, it also names the returned fields, so an agent can reason about `authMode` and `unlocked` without opening 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?

Schema coverage is 100% and both params are documented there, so the baseline is 3; the description earns above that by explaining provenance and consequence — the signature must be produced by the user's wallet over the `message` returned by `tronsave_get_sign_message`, and each param unlocks a distinct tool set. The exclusive-or requirement is stated in both places, so that part is redundant, but the meaning of each credential is genuinely enriched.

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?

Opens with a specific verb and resource ("Log in to TronSave") plus the crucial scope qualifier "for the rest of this MCP connection", which immediately separates it from per-call auth tools and from siblings like `tronsave_logout` and `tronsave_get_session_status`. The two auth modes are named with their concrete effects, so the agent knows exactly what the call accomplishes.

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?

Gives explicit routing between the two modes — `signature` unlocks wallet tools, `apiKey` unlocks internal-account tools — and names the prerequisite sibling `tronsave_get_sign_message` as the source of the message to sign. It does not state what to do if a session already exists (e.g., check `tronsave_get_session_status` before logging in, or that a repeat login replaces the session), which is the one routing gap.

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 destructiveHint=false and idempotentHint=true, so the description earns credit mainly for the non-obvious scope statement that client-configured header credentials survive the call, plus the response shape. The idempotency mention is somewhat redundant with idempotentHint, and no auth/permission requirements are stated.

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

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

Three compact clauses, front-loaded with the action and scope, then the return value, then the caveat. Every clause carries distinct information an agent needs.

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

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

For a no-parameter session-teardown tool this is nearly complete: scope, side effects, idempotency and return value are all covered, and an output schema exists. The only shortfall is the missing contrast with revoke_api_key, which matters for choosing the right teardown 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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The description correctly avoids inventing inputs and instead documents the scope of the credential being removed.

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 a specific verb (Remove) and resource (the TronSave login) plus the exact scope: the credential bound to this MCP connection, with the two credential types (api-key or signature) named. An agent can immediately tell this apart from account-level siblings like revoke_api_key or generate_api_key.

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?

Clear context is given: this clears the session credential for this MCP connection only, and header credentials configured on the client are explicitly unaffected, which is a useful exclusion. The one gap is that it never distinguishes itself from the sibling revoke_api_key, which an agent could plausibly confuse with this operation.

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