register_bns_name

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

With no annotations, the description carries the full burden and does well: it discloses the on-chain confirmation gate, the mandatory salt reuse, and contract-version auto-detection (V2 for .btc, V1 for other namespaces) — behavior not inferable from the schema. It omits failure modes (what happens if the preorder is unconfirmed or the salt mismatches) and the fee/irreversibility of the registration, 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?

The core content is front-loaded and dense: operation, step position, timing gate, salt requirement, version detection — all in three tight sentences. The trailing 'Tip: call earning_opportunities' line is a cross-sell unrelated to executing this tool and 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?

For a 2-parameter mutation with no annotations and no output schema, the description supplies the sequencing, timing, and salt-binding context an agent needs to invoke it correctly. The remaining gap is expected failure behavior and fee implications, which an agent would likely want before signing.

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 both parameters are already documented, including the salt's 'must match exactly' constraint. The description reinforces the salt requirement but adds no syntax, format, or edge-case meaning 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 ('Register a BNS domain name') and immediately situates it as step 2 of a 2-step preorder flow, which cleanly separates it from preorder_bns_name (step 1) and from claim_bns_name_fast. An agent can identify the operation and its position in the flow 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?

Gives explicit invocation preconditions: preorder must be confirmed on-chain (~10 minutes) and the salt from the preorder must be reused. That is strong when-to-use guidance. It stops short of explicitly contrasting with claim_bns_name_fast as an alternate registration path, so it lands at 4 rather than 5.

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