bulk_register

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

With no annotations, the description carries full burden and does an excellent job. It discloses the two-transaction flow, the 60-second wait, excess ETH refund, per-name secrets for front-running protection, and the requirement that all names be available. This gives the agent a clear behavioral model.

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 description is well-structured: it starts with the primary purpose, then benefits, then a clear step-by-step flow, and finally a helpful follow-up suggestion. Every sentence adds value and there is no fluff or redundancy.

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 multi-step transaction tool with no annotations and no output schema, the description covers essential context: transaction flow, wait time, refund handling, availability requirement, and next steps. It lacks explicit details on the return value or failure modes (e.g., if one name is unavailable), but the provided info is quite comprehensive.

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%, with all parameters well-described in the schema itself. The description adds minimal parameter-specific detail beyond what's in the schema; it mentions the 20-name limit (already in schema) and the flow but doesn't enhance understanding of parameters like duration or walletAddress. Hence baseline 3 is appropriate.

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 tool's purpose: 'Register multiple ENS names in bulk' with specific details on batching and transactions. It distinguishes from siblings by emphasizing the bulk nature, cost efficiency, and the two-transaction flow, making it distinct from single-name registration 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?

The description provides clear usage context: it's 'much cheaper and faster than registering names one at a time' and supports up to 20 names per batch. It also notes that all names must be available, implying a prerequisite. However, it does not explicitly compare against alternatives like batch_purchase or state when not to use this tool, so it's slightly below a 5.

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