TronSave MCP Server

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

Goes beyond the annotations by disclosing that the call spends paymentAmount SUN of the internal balance, requires a wallet-signature identity, and returns one order id per receiver. The non-idempotency note duplicates idempotentHint=false, but the balance spend and auth requirement are genuine additions to a write tool with destructiveHint=false.

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

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

Opens with the operation and its distinguishing constraint, then the side effect, then the recommended pre-call workflow. No sentence is filler and the cost warning is placed before the invocation guidance where it matters most.

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

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

Covers the high-risk facts an agent needs for a 7-parameter financial batch operation: uniform amount across up to the schema's 50 receivers, balance spend, non-idempotency, signature requirement, and the estimate-first workflow. Return values are already covered by the output schema, so their absence from prose is not a gap.

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

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

Schema description coverage is 100% and the schema already documents the per-receiver semantics of resourceAmount and the paymentAmount tolerance formula. The description reinforces that resourceAmount is uniform across all receivers, which is mildly useful, but adds no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ("Buy ... ENERGY or BANDWIDTH for several receiver addresses in one call") plus the payment source and return shape (one order id per receiver). The capitalized SAME immediately distinguishes it from per-receiver or single-order purchase siblings like tronsave_internal_order_create.

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 concrete pre-call workflow: estimate one receiver with tronsave_estimate_buy_resource and show the user receivers, amount and total cost before calling. It never explicitly names the single-address alternative as the fallback for one receiver, so the when-not case is inferred rather than stated.

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

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

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?

Annotations already flag readOnlyHint=false, idempotentHint=false and openWorldHint=true, but the description adds substantial context the annotations cannot carry: funds are spent, the auth requirements differ per paymentMethod (api-key header/signature login vs. no login plus a wallet-signed TRX transfer), and the signed tx must be produced client-side, never fabricated. The non-idempotency warning is paired with a concrete recovery procedure — verify before retrying on timeout — rather than just restating the hint.

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 spending warning, and essentially every sentence carries operational value — no filler. It is a dense single block with several clauses chained together, which makes scanning for a specific rule slightly harder than a short bulleted structure would.

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-required-parameter mutation with a nested signed-transaction object, the definition covers the auth model, the estimate dependency, the return shape (`{ success, message, code, data.orderId }`) and the retry hazard. Even though an output schema exists, the added return-shape and verification guidance leaves no material gap 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, and the description adds real meaning on top: SUN-not-TRX units, the requirement to take price/amount/duration from the latest estimate, and the conditional relationship between `paymentMethod` and `paymentSignedTx` including which credentials each branch needs. It does repeat some schema text (unit and estimate sourcing) rather than purely extending it, which keeps it just below the top mark.

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 buy order for ENERGY/BANDWIDTH delegated to orderReceiver' — and immediately distinguishes it from the sibling `tronsave_internal_order_create` by naming the internal-balance use case. An agent can tell which order-creation tool applies 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 routing: API-key integrations paying from internal balance should use `tronsave_internal_order_create`, otherwise this tool. It also mandates a prerequisite ('confirm the plan with the user first'), sources inputs from `tronsave_estimate_buy_resource`, and gives post-call verification tools, leaving nothing to 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?

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 readOnly, idempotent, and openWorld, and the description adds genuinely new behavior: no session required, backend rate limits apply, safe to call repeatedly, and which returned fields map to which tronsave_create_order parameters. That mapping is actionable context not present in any structured field.

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 verb and purpose, then the downstream mapping, then defaults, then sibling routing — a sensible order with no filler sentences. It is dense as a single block and the return-shape and alternative-tool clauses could be split for scanability, but nothing is wasted.

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

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

For a read-only quote tool with an output schema, full parameter coverage, and rich annotations, the description covers purpose, defaults, output semantics, follow-up call, and alternatives. An agent has everything needed to call it correctly and use the result.

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

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

Schema description coverage is 100%, so the baseline is 3; the description still adds value by summarizing the default combinations (ENERGY/100000 units/900 s, BANDWIDTH/1000) and, more importantly, by explaining how the quote's outputs become create_order inputs. It does not add much on the less obvious params like allowPartialFill or minResourceDelegateRequiredAmount beyond what the schema says.

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: quoting price and availability for buying ENERGY or BANDWIDTH for a receiver address, explicitly positioned as a pre-order step. It also names the exact siblings it is not (tronsave_internal_order_estimate for API-key orders), so an agent can distinguish it immediately.

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 rules: use this quote to feed tronsave_create_order, use tronsave_internal_order_estimate for internal orders, tronsave_list_order_books for order-book depth, and tronsave_get_min_price for minimum price only. Defaults for resourceType, amount, and duration are restated so an agent can call with zero arguments.

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

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

Annotations declare readOnlyHint/idempotentHint, and the description still adds real context beyond them: nothing is submitted, it is public for any address, and it fails with 404 when the address has nothing staked. That error-behavior disclosure is the kind of detail annotations cannot carry; only the response/pagination shape is left unaddressed.

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 outcome and every clause earns its place (what it returns, no submission, when to use, alternative, error case). It is dense to the point of being a single run-on paragraph, which slightly hurts scanability.

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 read-only estimator with an output schema and full annotation coverage, this is complete: it covers scope, safety, the failure case, and routing to the sibling. Return-value details 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 description coverage is 100% and the single `requester` parameter is already documented with its TRON base58 pattern, so the schema does the heavy lifting. The description adds the useful nuance that the address need not be the caller's ("any address"), but nothing about the parameter format.

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 (estimate) and resource (flash unstake), enumerates exactly what the estimate returns (total staked, fee percentage, payout, delegations to reclaim, minimum unstake amount), and explicitly separates itself from `tronsave_get_flash_unstake_request`, which checks an existing request.

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 sequencing ("Use before requesting a flash unstake") and names the alternative tool with the condition that selects it (checking an existing request). An agent knows both when to call this and when to call the sibling 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?

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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description still adds real value by disclosing the auth requirement (wallet signature identity) and the empty-state contract ('request is null when there is none'). It does not cover what happens without a valid signature (error vs. empty), which keeps it just 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 first defines the resource and its returned facets, the second routes the agent to alternatives and states the precondition. Every clause carries information; there is no restatement of the title or 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?

With an output schema present, the description need not explain return shapes, and it still flags the key empty case. Auth requirement, read-only nature, and sibling routing are all covered, which is everything an agent needs to call this 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 explain and the baseline of 4 applies. The description correctly spends no words re-documenting an 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 and resource ('Read the logged-in user's flash-unstake request') and enumerates the returned facets (state, payout state, amounts, release progress). The parenthetical explains what a flash-unstake actually is, and the description explicitly excludes the sibling tools that cover previewing and browsing, so the agent can pick it 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 an explicit when-to-use rule ('the user's own request') and names two concrete alternatives with the conditions that select them: tronsave_estimate_flash_unstake for previewing a payout, tronsave_list_flash_unstake_orders for browsing all orders. It also states a precondition (wallet signature identity), leaving nothing to 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?

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantive behavior the annotations cannot express: the auth requirement (tronsave_login internal API key in api-key or signature mode, or an Authorization: ApiKey client header), that the server forwards the key from session/header rather than accepting it as an argument, and that any API key in the payload is masked. These are exactly the operational facts an agent needs before calling a credentialed 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?

Front-loaded with purpose, then auth, then sibling routing, then return shape — a sensible information hierarchy with no throwaway sentences. It is dense with parentheticals and repeats a return-shape summary that the output schema already supplies, which keeps it just short of ideal trimness.

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

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

Despite having no input parameters, this is a credentialed, session-scoped read, and the description covers the auth paths, key-handling rule, masking behavior, and the sibling routing needed to pick it. With an output schema present, the brief return summary is a bonus rather than a necessity, 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. It does add one relevant constraint about argument handling (API keys must not be passed as arguments), but that is really auth guidance rather than parameter semantics.

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

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

States a specific verb and resource ('Retrieve the Tronsave internal account profile for the current logged-in session') and immediately enumerates the contents (wallet/represent address, balances, deposit address). It explicitly distinguishes itself from the two nearest siblings, tronsave_get_user_info and tronsave_list_internal_transactions, so an agent can route correctly 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 a concrete trigger ('Use when the user needs their linked address or balance') and names both alternatives with the condition that selects them: full wallet profile to tronsave_get_user_info, deposit/payment ledger to tronsave_list_internal_transactions. It also states a hard exclusion — never pass API keys as tool arguments — which is actionable guidance rather than description filler.

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, open-world behavior, so the description only needs to add context. It contributes freshness information ('refreshes about every TRON block (3 s)') and confirms public access, though it does not discuss rate limits or any auth nuances.

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 content is front-loaded and dense with useful routing information. Every sentence adds either scope, an alternative, or a behavioral fact, 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-value explanation is unnecessary. The description covers the summary contents, intended use, alternatives, access model, and refresh cadence, which is everything needed to invoke it correctly.

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

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

There are zero parameters, so the baseline is 4 and there is no parameter meaning to add. The description correctly avoids inventing parameter semantics.

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

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

States a specific verb and resource: reads a TronSave market summary, then enumerates exactly what is included (available/listed ENERGY and BANDWIDTH, pooled seller count, seller APY). This is clearly distinguishable from pricing and order-book siblings named later.

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 it for a quick 'how is the market' answer before pricing, and routes the agent to `tronsave_get_price_table` or `tronsave_estimate_buy_resource` for prices and `tronsave_list_order_books` for depth by price. Both the use case and alternatives are stated.

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

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

Beyond the supplied annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses the auth requirement ('No login required'), the upstream source (`market.estimateMinPrice`), and the unit semantics of the returned value (SUN per resource unit, per day when durationSec >= 86400) — behavior that cannot be inferred from annotations. The only redundancy is restating 'Read-only and idempotent', which is harmless and non-contradictory.

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, front-loaded sentences leading with the core purpose and the routing decision. The closing sentence partially repeats the alternatives already named, which is mild redundancy rather than clutter.

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 carry the safety profile, so the description needs only to explain selection, upstream source, and unit semantics — all of which it does. Nothing an agent needs to invoke the tool 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 earns above that by tying `durationSec` to the returned unit (per-day when >= 86400) and by naming which inputs drive the quote (`resourceType`, `buyAmount`, `durationSec`) plus the scoping role of `address`. It does not add format or validation detail beyond that.

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 the minimum unit price for a buy') and immediately distinguishes itself from `tronsave_estimate_buy_resource` (full quote) and `tronsave_get_price_table` (grid across amounts/durations). An agent can select it 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 an explicit selection rule ('Use when only the floor price matters') plus named alternatives for the two adjacent use cases, and repeats the pairing guidance at the end. When-to-use and when-not-to-use are both 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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds two things beyond them: the wallet-signature identity requirement (an auth prerequisite the annotations do not express) and the sequencing role as source of truth before mutations. Return-value detail is omitted, but that is acceptable given the output schema.

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

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

Four short sentences, each carrying a distinct fact: what it reads, the API-key alternative, the pre-mutation sequencing role, and the auth/safety profile. Front-loaded with the action and resource, zero 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 single-parameter read tool with full schema coverage, an output schema, and complete annotations, nothing an agent needs is missing. Auth requirement, alternative tool, and ordering relative to write tools 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 already documents `id` as an MObjectId for confirming status/price. The description adds the useful framing that the id refers to one of three order types (NORMAL, FAST, EXTEND), which is not in the schema. Slightly above baseline because of that added semantic.

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

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

States a specific verb and resource ('Read one order by `id`') plus the return shape ('full snapshot') and the covered order types (NORMAL, FAST, EXTEND). It is immediately distinguishable from `tronsave_list_orders` (plural listing) and `tronsave_internal_order_details` (API-key variant), both named or implied.

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_internal_order_details` when only an API key is available, and use this tool as the freshness check before `tronsave_update_order`, `tronsave_sell_order_manual`, or `tronsave_cancel_order`. Both the when-to-use and the alternative condition are spelled out, with the stale-state risk stated as the reason.

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, and the trailing 'Public, read-only' largely restates them. The genuinely additive content is the pricing semantics — SUN as the unit and the per-day rule for durations of 1 day or longer — which is behavior an agent cannot infer from annotations. Safety/auth surface is fully covered by annotations, so this lands mid-range.

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 definition and matrix indexing, then the per-day pricing caveat with a worked example, then routing guidance. Dense but every clause carries information; only the redundant 'Public, read-only' tail is arguably wasted given 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?

For a 2-param read tool with a full output schema, the description covers the one thing the schema cannot: how to interpret the returned price grid and how per-day durations are charged. The per-day example ('40 x 30 SUN per unit in total') is slightly ambiguous about whether the multiple applies twice, but overall nothing essential 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 schema itself documents both the enum meaning and the address caveat ('prices can depend on the account'). The description adds no parameter-level detail for resourceType or address; its extra detail concerns the response matrix rather than the inputs, so 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?

States a specific verb and resource ('Read the price grid for ENERGY or BANDWIDTH') and immediately defines the shape of what comes back (prices[i][j] keyed by amounts[i] and durations[j]). An agent can distinguish it from any other pricing sibling 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 says 'Use to compare cost across amounts and durations in one call', then names two alternatives with the condition that selects each: exact quote goes to tronsave_estimate_buy_resource, floor price only goes to tronsave_get_min_price. Clear when-to-use and when-not-to-use.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the description correctly does not re-litigate safety; instead it adds genuinely new behavior: a wallet-signature identity requirement and the non-obvious detail that offset/limit page the referral list and the payout list together rather than independently. It also flags that bonus values are SUN strings, which prevents unit mistakes, though it says nothing about empty-state or error 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?

Front-loaded with the returned resource, then constraints, then pagination nuance, then the read-only/auth note; every clause carries information. The field enumeration is dense but purposeful rather than padding, though the passage is longer than strictly needed given an output schema exists.

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 paginated, read-only, 3-optional-parameter tool with a full output schema, the description covers the remaining agent-relevant gaps: auth identity requirement, pagination coupling across two lists, status filtering values, and unit conventions. No call-relevant fact 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 and the schema already documents limit bounds, offset semantics and the PENDING/ACTIVE enum. The description earns above baseline by clarifying that the same offset/limit applies jointly to two result lists, which the per-parameter schema text does not make explicit at the tool level.

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+resource ('Read the logged-in user's referral status') and then enumerates exactly what is returned: own referral code, sponsor, counts, bonus earned/remaining in SUN strings, rank, referral list with PENDING/ACTIVE states, and commission payouts. It also names the sibling it is not (tronsave_get_user_info), so an agent can discriminate it 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?

States an explicit usage boundary ('Use for referral questions only') and routes the adjacent use case to the named alternative tool (account profile via tronsave_get_user_info). Nothing about when to pick this versus that sibling is left to 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description's additional value is the wallet-signature identity requirement and the fact that results are scoped to the logged-in seller (self-only, no user parameter). The trailing 'Read-only' merely restates the annotation rather than adding information, which holds it below 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 well-built sentences front-load the returned data and then route to the alternative, with no filler. The final 'Read-only' is redundant given readOnlyHint=true and is the one sentence that does not earn its place.

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

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

With an output schema, full parameter documentation and read-only annotations, the description covers what matters: scope, return contents, alternative tool, and auth requirement. The one soft gap is that it says a wallet signature is required but does not point to the login/session tool that establishes it.

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 both parameters are enums with documented meanings and defaults, so the schema carries the semantic load. The description only alludes to the resource dimension ('per resource') and never explains the chart window parameter, so it adds little beyond the schema — baseline 3.

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

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

States a specific verb ('Read') and a precisely enumerated resource: lifetime totals for delegations, resource delegated, TRX earned, average price, plus a daily earnings chart split by delegation type. It also names the sibling (`tronsave_list_delegations`) that returns the underlying rows, so an agent can distinguish the two without opening schemas.

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 selection rule ('Use for how much did I earn totals') and an explicit alternative with its condition ('for the individual delegations behind them use tronsave_list_delegations'). It also states a prerequisite ('Requires a wallet signature identity'), so the agent knows the call will fail unauthenticated.

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=true, idempotentHint=true and openWorldHint=true, and the closing "Public, read-only" restates that rather than adding to it. The real added value is the enumeration of returned data categories, which tells the agent this is the single-call configuration snapshot. No rate-limit or freshness/caching behavior is mentioned, 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?

The purpose and the returned fields are front-loaded in one dense sentence, followed by usage intent and then sibling routing. Slightly list-heavy, and "Public, read-only" is redundant with the annotations, but no sentence 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 zero-parameter read tool with a full output schema and rich annotations, everything an agent needs is present: what it returns, why to call it, and which sibling to prefer for adjacent data. Return-value formatting is delegated correctly 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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly avoids inventing filters or options that the empty schema does not support.

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 (Read) and enumerates the exact resources returned: latest block, minimum buy amounts, burn rates, dynamic/lowest prices, deposit address, max lock period, USDT transfer energy cost. This is concrete enough that an agent can distinguish it from tronsave_get_market_overview or tronsave_get_price_table without inspecting 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?

Gives positive usage intent ("size purchases" via minimums, "compare renting with burning TRX") and explicitly routes two competing needs to named alternatives: market prices to `tronsave_get_price_table`/`tronsave_estimate_buy_resource`, supply/APY to `tronsave_get_market_overview`. Both when-to-use and when-not-to-use 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/idempotentHint, but the description adds information not in them: `setting` is null when Telegram is not linked, a wallet-signature identity is required, and the paired update tool performs whole-object replacement. Those null semantics and the auth prerequisite are the main things that could cause a caller to misbehave.

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 verb and resource, then the routing guidance, then caveats — good ordering with no filler. The parenthetical field inventories are somewhat redundant given an output schema exists, which trims the score slightly.

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 tool with an output schema, everything an agent needs is present: what is returned at a high level, the null case, the auth requirement, and the correct sibling for in-app alerts and for mutations. Nothing essential 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?

There are zero parameters, so the baseline is a 4. The description instead describes semantics of the returned `setting` object and its null condition, which is a useful addition even though it sits in output-schema territory.

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 the Telegram alert filters of the logged-in user') and immediately enumerates the two filter groups (seller: remaining amount, duration, price/APY ranges, unlocked-only; buyer: reclaim warning time, low energy/bandwidth thresholds). This clearly differentiates it from tronsave_update_telegram_notify_setting and tronsave_list_notifications.

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: read this before calling tronsave_update_telegram_notify_setting, and notes that the update tool replaces whole filter objects (so read-modify-write is required). It also names tronsave_list_notifications as the alternative for in-app alerts, which is exactly the sibling-disambiguation 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?

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 readOnly/idempotent/openWorld, yet the description adds genuinely new context: a wallet signature identity is required, `internalAccount.apiKey` is masked, `info` may be null, and `internalAccount` is null before provisioning. These nullability and masking traits materially change how an agent interprets results.

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 return shape, then the exemption list. Dense but largely waste-free; the only mild inefficiency is splitting the alternative-tool routing across the opening and closing sentences rather than consolidating 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?

Even though an output schema exists, the description restates the shape and annotates the tricky parts (nullable `info`, null `internalAccount`, masked API key), plus auth requirements and sibling routing. Nothing an agent needs in order to call or interpret this zero-parameter read 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 schema carries no semantics to supplement; per the baseline for 0-param tools this lands at 4. The description correctly spends no words on nonexistent inputs and instead documents the output fields.

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 ('Read the current authenticated user's profile and linked TronSave internal account') and immediately distinguishes itself from the narrower balance and referral tools. The agent can tell exactly what this returns without opening any 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 explicit alternatives with conditions: `tronsave_get_internal_account` for internal balance alone, `tronsave_get_referral` for referral data, `tronsave_get_user_auto_setting` for auto-sell config, and `tronsave_get_user_permissions` for permission flags. Two distinct routing cues (front and back) cover both narrow and partial-profile cases.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing the authentication model (internal API key via tronsave_login or an ApiKey client header), the security constraint that keys must never be passed as tool arguments, and that the server forwards credentials from the session. It also clarifies the non-obvious side-effect profile: read-only, submits nothing, and is the only source of a submittable extendData payload.

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 sequencing, then alternatives, then a clearly labeled FRESHNESS block. The authentication sentence is unavoidably dense but does carry unique constraints; overall every sentence does work, though the text is longer than most agents need in one read.

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

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

Covers everything an agent needs for a credential-gated, time-sensitive step-1 tool: prerequisites, sequencing, alternatives, freshness, and credential handling, while an output schema already documents the return shape. Nothing material is left to inference.

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

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

Schema description coverage is 100%, with per-field detail including the epoch-seconds format, millisecond rejection, and address regex, so the baseline is 3. The description adds only one param-adjacent rule (pass the returned extendData unchanged); it does not explain receiver, resourceType, or maxPriceAccepted beyond what the schema already says.

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 extendable delegations for a receiver, plus an extendData payload) and explicitly separates itself from the two lookalike siblings tronsave_list_extendable_delegates (public market view) and tronsave_list_extendable_receivers (receiver discovery). An agent can route correctly without opening any 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 explicit sequencing ("Use as STEP 1 before tronsave_internal_create_extend_request"), the triggering user intent (extending existing delegation time), and named alternatives for adjacent needs. It also states a hard freshness rule: run immediately before extending and pass extendData unchanged.

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

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

Annotations already declare read-only and idempotent, but the description adds substantial context beyond them: authentication modes (api-key mode vs signature mode for an internal-account wallet), the `Authorization: ApiKey` header, the explicit prohibition on passing keys as tool arguments, and the fact that the server forwards the key from session/header. It also discloses a concrete freshness characteristic (market depth changes roughly every TRON block, ~3 seconds), which is behavior an agent cannot get from 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 purpose, then alternatives, then the labeled FRESHNESS constraint, so the most decision-relevant material comes first. It is dense and the authentication sentence is long, but each sentence contributes a distinct constraint, with no filler or repeated annotation content.

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

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

An output schema exists, so return values need not be explained, and the description still covers what an agent needs to call it correctly: auth prerequisites, sibling alternatives, mutation-free nature, and the time-sensitivity of the returned data. Nothing material is missing for a read-only market query with four optional parameters.

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 (address filter, durationSec, resourceType, minDelegateAmount) is already documented in the schema, which sets the baseline at 3. The description adds no per-parameter syntax, defaults, or interaction detail beyond mentioning the ENERGY/BANDWIDTH and price-tier concepts already covered by the enum and schema text.

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

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

States a specific verb and resource: returns current market depth/price tiers for ENERGY or BANDWIDTH via the api-key REST endpoint. It also distinguishes itself from the closest sibling by noting it has the same depth as the public `tronsave_list_order_books` plus SLOW/MEDIUM/FAST tiers, 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?

Gives explicit when-to-use (before `tronsave_internal_order_create` or `tronsave_internal_order_estimate` when live prices or liquidity are needed), an explicit alternative (the public tool when there is no API key), and a pre-call timing rule (re-read immediately before placing an order). No exclusions are left to 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 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?

Goes well past the readOnly/idempotent annotations: it states the authentication requirement (`tronsave_login` api-key mode or an `Authorization: ApiKey` header), warns never to pass API keys as tool arguments, and notes the server forwards the session key. The FRESHNESS note that order state changes within seconds and should be re-read before acting is exactly the kind of behavioral context annotations cannot carry.

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 is front-loaded, auth and routing follow, and the labeled FRESHNESS caveat is easy to scan. It is slightly dense for a one-parameter read, with some backticked identifier load, but no sentence 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?

An output schema exists, so return values need not be explained; what remains — auth mode, key handling, sibling routing, and state-freshness timing — is all covered. Nothing an agent needs to call 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 description coverage is 100% and the single `orderId` parameter already documents the hex format and provenance from `internal.order.create`. The description's 'by order ID' phrasing adds nothing beyond that, so the 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?

Specific verb plus resource and scope: 'Fetch full details for one internal-account order by order ID.' It also distinguishes itself from the sibling `tronsave_get_order`, explaining that the sibling returns the same order under wallet-signature auth, so an agent can route 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: monitoring fulfillment after `tronsave_internal_order_create`, or answering a status question about a specific order id. The alternative path (`tronsave_get_order` for wallet-signature auth) is named with its selecting condition.

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, but the description adds material behavior beyond them: required internal API key, the fact that keys are never passed as arguments and are forwarded from the session/header, and the roughly 3-second price volatility requiring re-estimation before order creation.

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 routing, then a labeled FRESHNESS caveat, so an agent can stop reading early. It is dense with parentheticals (api-key mode, signature mode) that could be trimmed, but every sentence 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 7-parameter read-only estimation tool with a full schema and an output schema, the description covers the remaining unknowns: auth path, no-key-in-arguments rule, sibling routing, and quote staleness. 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 nonetheless adds that unitPrice and estimateTrx are live values that shift about every 3 seconds, which is temporal meaning the schema does not convey. Other parameters (receiver, requester, durationSec, resourceType, options) are left entirely 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?

States a specific verb and resource: estimate TRX cost and availability for a buy order before submission. It also scopes the account type (internal api-key account) and explicitly distinguishes itself from tronsave_estimate_buy_resource, which serves tronsave_create_order quotes.

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 when-to-use (user wants a quote or price check), the downstream step (feed the result into tronsave_internal_order_create), and an explicit when-not with the correct alternative (tronsave_estimate_buy_resource for tronsave_create_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?

Beyond the readOnly/idempotent annotations, the description discloses the authentication model in detail: which key is required, the two supported modes, the `Authorization: ApiKey <key>` header form, and the important constraint that keys must never be passed as tool arguments because the server forwards them. It also states result ordering (newest 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?

Purpose and ordering are front-loaded in the first sentence, auth constraints follow, then usage and routing. Every sentence carries non-redundant information, and no schema or annotation content is merely 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?

For a two-parameter paginated list tool with an output schema, the description covers everything an agent needs: what it returns, ordering, pagination, auth prerequisites, error-avoidance guidance, and which sibling to use instead or in tandem. Return-value detail is 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 both parameters (page, pageSize) are fully documented in the schema with defaults and ranges, so the baseline is 3. The description adds only the result ordering ('newest first'), which is not a parameter-level detail and is not restated per-parameter.

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 gives a specific verb (List), resource (order history), scope (internal account linked to the API key), ordering (newest first), and pagination shape. It also distinguishes itself from the sibling list tool by naming `tronsave_list_orders` as the wallet-signature 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?

It states an explicit use case ('past purchases, fulfillment, payouts, or delegates on their internal account'), names the alternative route (`tronsave_list_orders` with `isOnlyMyOrder`), and points to the companion tool `tronsave_internal_order_details` for single-order lookups.

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, and the description reinforces 'Read-only'. It adds genuinely new context by disclosing that a wallet-signature identity is required, which is an auth prerequisite an agent must arrange before calling. Nothing is contradicted, though pagination behavior beyond the schema 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?

Three tight sentences: what is listed and what fields, then the routing/sequencing tip, then the auth and safety notes. Front-loaded and free of redundancy.

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

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

Given an output schema exists and annotations carry the safety profile, the description supplies the remaining essentials: returned fields, prerequisite identity, and use-before-mutation guidance. Only the pagination contract is left entirely to the schema, a minor gap.

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

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

Schema description coverage is 100%, with limit, offset and filterBy each fully documented in the schema, including the max-10 cap and pagination semantics. The description adds no parameter-level meaning beyond that, 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 ('List') and resource ('auto-buy rules') and enumerates the fields returned (receiver, resource, unit price cap, threshold, budget limits, totals, active state). That level of specificity lets an agent distinguish it from the sibling mutation tools and from tronsave_get_user_auto_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?

Gives explicit sequencing guidance: call this before tronsave_update_auto_buy_setting or tronsave_delete_auto_buy_setting to obtain rule ids. It does not clarify when to prefer this over related reads like tronsave_get_user_auto_setting, so it falls short of full when/when-not coverage.

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 is covered structurally. The description still adds value with ordering semantics ("Newest first"), pagination mechanics, and the authentication prerequisite ("Requires a wallet signature identity"). It does not discuss rate limits or failure modes, which keeps it just short of a 5 given the lower bar set by 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 what the tool returns, then pagination, then routing to alternatives, then auth — a sensible order with no filler. It is dense, packing three sibling references and a field list into two sentences, which borders on heavy but every clause carries 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 read-only list tool with an output schema, full annotation coverage and a 100%-documented 5-parameter schema, the description supplies everything else an agent needs: sort order, paging, auth requirement, and disambiguation from siblings. Nothing essential to a correct call 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%, including enum value meanings for `timeFilterBy`, `filterByResourceType` and `filterByTypeDelegate`, so the schema already carries parameter semantics. The description only restates pagination via `offset`/`limit` and lists the type values, adding no syntax or format detail 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 seller's delegations") and immediately enumerates returned fields (amount, TRX amount, duration, unit price, type, status, payout). It explicitly distinguishes itself from `tronsave_get_seller_stats` and `tronsave_list_orders`, so an agent can route without opening schemas.

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 positive case ("a seller's per-delegation history") and two named alternatives with the condition that selects each: earnings totals go to `tronsave_get_seller_stats`, purchased orders go to `tronsave_list_orders` via `isOnlyMyOrder`. The `filterByTypeDelegate` enum even maps MANUAL back to `tronsave_sell_order_manual`, reinforcing correct 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?

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 readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered; the description reinforces this with 'Public (any requester address), read-only'. It adds useful context about output contents and the flow, though it does not detail pagination or result-size 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, front-loaded with the core purpose and followed by the flow guidance; nothing is wasted. Slightly dense with backtick-quoted sibling names but still readable and purposeful.

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 an output schema exists and annotations cover the safety profile, the description supplies exactly the missing pieces: public accessibility, downstream flow, and output field meanings. Nothing an agent needs to invoke it correctly is absent.

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 both requester and resourceType. The description references 'requester' and 'bought by requester' but adds no syntax or format detail beyond the schema, so the 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 (List) and resource (receiver addresses with extendable delegations bought by requester), and even names the output fields (expiry in Unix seconds, delegation count, total amount). It is clearly distinguishable from sibling list tools by tying the result to the extension flow.

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 frames this as the first step of an extension flow and names the two downstream alternatives with their selecting condition (market view vs API-key path returning extendData). The when-to-use and the branch point are fully specified.

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, and the closing "Public, read-only" largely restates that. The description still adds real value by defining each status bucket (open orders buyers can take, being paid out, done) and by disclosing that amounts are SUN-scaled and estimateCompletionTime is in 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?

Three tightly packed sentences, front-loaded with the purpose and closed with a safety signal; nothing is filler. It is slightly dense in the first sentence, with parenthetical glosses stacked for all three kinds, but still readable.

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 explanation is unnecessary, and pagination is fully covered by the schema. For a simple public list tool the description covers scope, alternatives and units; only ordering of results is left unstated.

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 kind, limit (default 10, max 50) and offset pagination, so the schema does the heavy lifting. The description only echoes the kind values and adds no format or default detail beyond it; the unit notes it does add concern output fields, not parameters.

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

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

States a specific verb and resource ("Browse the flash-unstake market") and enumerates the three listable order states with their meaning. It also names the two closest siblings it is not, so an agent can route correctly 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?

"Use to browse the whole market" sets the scope, then explicitly routes the user-specific case to tronsave_get_flash_unstake_request and the preview case to tronsave_estimate_flash_unstake. When-to-use and when-to-use-something-else are both stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description nonetheless adds real behavior beyond them: newest-first ordering, the unit convention (amounts are SUN strings), the additional fields returned alongside the ledger, and the authentication prerequisite ('Requires a wallet signature identity'). It stops short of describing failure modes or empty-ledger behavior, which keeps it below 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?

Five tight sentences, front-loaded with the core operation and payload before moving to alternatives, pagination and the auth caveat. Parenthetical exemplars (deposits, refunds) and the sibling names each carry information; nothing is redundant.

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 two-parameter read tool with an output schema and full annotation coverage, the description supplies everything an agent needs: scope, ordering, units, auth requirement, pagination mechanism, and disambiguation from the three nearest siblings. No material gap remains.

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

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

Schema description coverage is 100%, with both parameters fully documented in the schema including defaults and bounds (max 50). The description only adds 'Page with offset/limit', which restates rather than extends the schema, so the 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?

The first sentence names a specific verb (list) and resource (TRX ledger of the logged-in user's internal account), enumerates the entry types covered (deposits, order payments, refunds), states ordering (newest first), and names the extra payload (current balance, deposit address). It is immediately distinguishable from tronsave_internal_order_history and tronsave_get_internal_account.

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 use case ('reconcile spending after orders') and routes to the correct alternatives by name with the condition that selects each: order history tools for the orders themselves (including the API-key vs isOnlyMyOrder distinction), and tronsave_get_internal_account for balance alone. This is when/when-not/alternatives all in one place.

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, yet the description still adds real value: result ordering (newest first), that an unread count is included, and the auth precondition ('Requires a wallet signature identity'). Missing only failure/empty-state behavior, which is minor given 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 dense sentences that are front-loaded with the core purpose before paging and cross-reference details. Slightly over-packed with parenthetical category lists, but each 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?

Complete for a read-only paginated list: purpose, ordering, auth requirement, pagination approach and the companion write tool are all covered, and an output schema exists so return-value shape needs no explanation.

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 limit, offset and unreadOnly are already documented in the schema. The description adds only a hint about paging with offset/limit, which the schema itself already explains; it says nothing extra about unreadOnly. 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 ('List the logged-in user's notifications') and enumerates the notification categories covered (order created/filled/cancelled/reclaimed, referral payouts). The scope qualifier 'logged-in user's' plus ordering ('newest first') and 'unread count' makes it clearly distinct from list_orders or 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 a concrete use case ('follow up on an order after creating it') and routes the agent to the sibling tool tronsave_mark_notifications_read for the write-side action. It doesn't state when NOT to use it versus other order-listing tools, so it stops short of full alternative coverage.

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 is covered; the description adds real context on top: no login required, that an API key unlocks tiered data via another tool, and the exact return shape `{ min, max, value }`. It stops short of covering result limits, pagination or behavior on empty books, which keeps it below 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?

Dense, front-loaded prose: purpose first, then tier/auth caveat, then return shape, then routing guidance. No filler sentences and no repetition of the tool title.

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

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

Given an output schema exists and annotations cover the safety profile, the description supplies everything else an agent needs: scope, auth tier differences, return structure, filtering semantics, and sibling routing. Nothing material is missing for a read-only market-depth query.

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

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

Schema coverage is 100%, so baseline is 3, but the description frames the three optional params as a single coherent 'scoping' model (viewer address, minimum delegate amount, duration) that filters returned buckets, which is a meaningful clarification beyond the per-field schema text.

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

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

Opens with a specific verb and resource: 'Read market depth buckets for ENERGY or BANDWIDTH'. It also explicitly distinguishes itself from the close sibling `tronsave_internal_order_book`, noting that the latter adds SLOW/MEDIUM/FAST tiers with an API key, so an agent can pick correctly 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?

Gives an explicit use case ('estimate market ranges before create/update decisions') and routes two adjacent needs to named alternates: `tronsave_estimate_buy_resource` for quote-style buy estimation and `tronsave_get_order` for a single concrete order. Conditions for selecting the higher-tier sibling are also stated.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds genuinely new behavior: the `limit` ≤ 10 paging cap, the wallet-signature identity requirement, and the lifecycle meaning of `ACTIVE` vs `COMPLETED`. It loses a point for spending much of its budget restating the return shape, which the output schema already provides.

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 the paging constraint before routing and return details. The long inline field enumeration of the `orders` object is redundant with the output schema and bloats the middle of the text; trimming it would sharpen the definition.

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?

Everything an agent needs to call this correctly is present: scope, paging bounds, filter semantics, the auth precondition on `isOnlyMyOrder`, and sibling routing for adjacent needs. With an output schema supplied and full parameter coverage, no material gap remains.

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 each parameter already carries its own description, including both enums, so the baseline is 3. The description reinforces `status` semantics and the `isOnlyMyOrder` signature requirement but adds no syntax, format, or edge-case detail the schema lacks.

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+resource ("Query the market order list") and immediately scopes it with paging. It explicitly separates itself from `tronsave_internal_order_history` (API-key account's own purchases) and `tronsave_get_order` (single snapshot by id), so an agent can pick the right tool without opening any 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?

Names two concrete alternatives and the exact conditions that select them: use `tronsave_internal_order_history` for an API-key account's own purchases, and `tronsave_get_order` with an `id` for one snapshot before mutating. It also states the precondition for `isOnlyMyOrder` (wallet signature identity) and notes api-key-only sessions cannot use it.

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

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

Annotations 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.

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the description's 'idempotent' is partly redundant. However, it adds real value beyond the annotations by scoping the mutation ('Only changes the read flag') and disclosing an auth requirement ('Requires a wallet signature identity'), neither of which appears 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?

One front-loaded sentence carries purpose and both modes, followed by two short clauses for id sourcing and side effects. No filler, and the most important fact (scope of the mutation) comes 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?

With only one optional parameter, full schema coverage, annotations covering safety/idempotency, and an output schema handling return values, the description covers everything an agent needs: what it does, where ids come from, side-effect scope, and auth requirement.

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

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

Schema description coverage is 100% and the single optional `id` is already documented, including the omit-means-all behavior. The description restates that rather than adding format or constraint detail (e.g., the 24-hex ObjectId pattern), so it meets the baseline but does not exceed it.

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

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

States a specific verb+resource ('Mark ... notifications as read') and explicitly covers both modes: single by `id`, or all when `id` is omitted. Nothing in the sibling list does anything similar, so the tool is instantly distinguishable from tools like `tronsave_list_notifications`.

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 the precondition for the argument ('Get ids from `tronsave_list_notifications`') and the condition that selects each mode (with `id` vs. omitted). That is an explicit routing rule to the sibling that supplies the input.

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: discloses the concrete consequence of non-idempotency ('calling twice may reset fields'), the persistent side effect on future delegation/sell behavior, the wallet-signature identity requirement, and named failure modes (invalid config combinations, unauthorized sessions, backend policy restrictions). The annotations only supply the boolean hints (readOnlyHint=false, idempotentHint=false); the description explains what those hints mean operationally.

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 return value, then side effects, then routing guidance, then failure modes — no wasted sentences. Every clause carries decision-relevant information for an agent choosing between auto-sell tools.

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

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

An output schema exists, so return-value explanation is not required, yet the description still names the persisted `autoSettings` payload. For a mutation tool with nested config, the mutation semantics, identity prerequisite, prerequisite read, and failure modes are all covered.

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

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

With 3 optional nested parameters at 100% schema description coverage, the schema already documents fields like poolSetting.energy.minPrice, paymentTimeWindow, and reclaim. The description adds no parameter-level meaning, syntax, defaults, or interaction rules, so it sits at the baseline for high-coverage schemas.

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

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

States a specific verb+resource ('Create the initial auto-sell configuration') with explicit scope ('for the authenticated user') and distinguishes it from the sibling it is not ('for subsequent edits use `tronsave_update_auto_sell_setting`'). An agent can select this over update/get siblings without opening any 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 says when to use it ('FIRST-TIME setup only'), when not to ('for subsequent edits use tronsave_update_auto_sell_setting'), and prescribes a prerequisite ('always read the current state with tronsave_get_user_auto_setting first to avoid overwriting unknown fields'). This is the full when/when-not/alternatives pattern.

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