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

Annotations already indicate a destructive, non-read-only mutation. The description adds useful behavioral context beyond annotations: it requires wallet signing, revalidates ownership as a precondition, and returns an HTTPS page as the output. These details help the agent anticipate user interaction and response type.

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 with no filler. The first sentence front-loads the action and resource, the second adds the necessary wallet-signing context. Every word contributes.

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 destructive tool with no output schema, the description covers the core behavior, output format, and authentication requirement. However, it remains incomplete on parameter specifics and does not warn about irreversibility or blockchain side effects beyond what annotations imply.

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 0%, so the description must carry the parameter semantics. It clarifies that 'domain' is a root .ton name or .t.me Username, and that 'newOwner' is the transfer recipient, but it does not specify the format or expected value for newOwner (e.g., TON address vs username) or any examples.

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 clearly states the action: revalidate ownership and return an HTTPS page to confirm an NFT transfer to a newOwner. It names the specific resource types (root .ton name or .t.me Username) and distinguishes the transfer operation from sibling tools like dns.send_name_tx or dns.send_record_tx.

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?

No guidance is given on when to use this tool versus the many send_* siblings (e.g., dns.send_renew_tx, dns.send_name_tx). The only contextual note, 'The user signs in their wallet,' is a prerequisite, not a selection criterion.

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