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

Annotations already declare readOnlyHint and idempotentHint, so "Public, read-only" is largely redundant. However, the description adds genuinely non-obvious behavior: the ~3 s price-movement window and the instruction to re-run immediately before ordering, plus the per-option return fields (readyToFill percent, payout in SUN, extendData rows) that signal the response can contain multiple candidate strategies.

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

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

Four sentences, each with a distinct job: define the operation, list outputs, route to the sibling tool, and warn about staleness. The most decision-critical information (the three strategies) is front-loaded, and nothing is padded.

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 summarizes the key returned fields, which is enough for an agent to route on. Combined with the freshness warning and the sibling hand-off, everything needed to invoke this correctly for a read-only, open-world suggestion tool is present.

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

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

Schema description coverage is 100%, so every parameter (receiver, requester, unitPrice, durationSec, resourceType, resourceAmount) is already documented in the schema. The description adds no parameter-level meaning—nothing about how unitPrice interacts with the returned strategy options or what resourceAmount means relative to existing delegations—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?

The description opens with a specific verb and resource ("Ask the market how a buy would be filled") and immediately enumerates the three concrete strategy options it returns: plain new order, buy-more-only, or extend existing delegations. The named sibling tronsave_create_order makes the boundary unambiguous, so an agent can distinguish it from the many other order-listing tools.

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

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

It gives a clear use condition ("before tronsave_create_order when the receiver may already have delegations that can be extended cheaper") and a timing rule ("re-run right before ordering"). It does not address the other plausible alternative, tronsave_estimate_buy_resource, so the agent must infer when to prefer a full strategy suggestion over a simple estimate.

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