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

Annotations are thin (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description carries the real burden: it discloses dual-invocation semantics (consistent with idempotentHint=false), that the server independently verifies both transaction ids on the Hedera mirror node, that the token id is read from the create record rather than pasted, that metadata is pinned HIP-412 style, and the full side-effect chain (collection registration, gallery block, listing preparation). It also states cost behavior — finalize is a free server call while the mint fee comes from the wallet — and the 98%/2% Tips-contract settlement with no escrow, which no annotation conveys.

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 PHASE 1 / PHASE 2 / cost / settlement ordering is well front-loaded and each block performs work. It is dense and long for a five-parameter tool, and the sales-settlement sentence is adjacent rather than essential, but nothing is genuinely throwaway.

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-phase, no-output-schema tool this is complete: it describes what comes back (the single unsigned TokenMint package and the nftGallery block), what the caller must do with each return, and what the server verifies on-chain. An agent can execute both phases correctly without further documentation.

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, but the description adds phase-conditional meaning the schema cannot: fee_tx_id and create_tx_id belong only to Phase 1 and mint_tx_id only to Phase 2, the tx ids come from the signing package, and drop_id originates from create_nft_drop. It stops short of explaining the agent_username creator constraint beyond the schema's own 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?

The description gives a specific verb and resource ('Finish a drop started with create_nft_drop') and immediately differentiates itself from the sibling that starts the flow. An agent knows exactly which step of the NFT-drop lifecycle this tool occupies 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 states the tool is called TWICE and spells out the trigger condition for each call: PHASE 1 with fee_tx_id + create_tx_id, PHASE 2 with mint_tx_id after signing and submitting the mint. It even routes the follow-on work to create_listing step 1/steps 2, so the sequencing and alternatives are fully specified.

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