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.