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

Far exceeds what the annotations declare: costs 1 credit, the first call returns only a price quote and starts nothing, the build begins only after human confirmation in the iter0 card or chat, and the card self-updates with progress and the finished site. It also preempts a likely confusion ('A running build is not a finished site') and states that iter0 does not sell credits through ChatGPT.

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?

Leads with what the tool builds before cost and the confirmation flow, so the essential action is front-loaded. It is dense but almost every clause carries a constraint an agent would otherwise get wrong; the pricing/payment sentence is the only slightly tangential one.

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 costly, destructive, non-idempotent build tool with an output schema and full annotation coverage, the description covers cost, the quote-then-confirm gate, progress visibility, and domain boundaries. An agent has everything needed to call it correctly and to not spend a credit accidentally.

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; the description adds real value by framing prompt/bindUrl/cloneUrl/directionId as mutually exclusive input modes (brief vs. reference URL vs. direction). It does not touch the less obvious flags such as variant, briefBuild, or faithfulClone, which are left entirely to the schema.

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 (Build) and resource (a new website in the person's iter0 account) and enumerates the three input modes: brief, reference URL, or directionId from Show 3. That makes it immediately distinguishable from siblings like iter0_edit_site, iter0_open_builder, or iter0_show_three.

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 scope boundaries ('Covers only the person's own iter0 websites and designs, not general design, colour, logo or branding advice, hosting elsewhere or domains') and routes the confirmation step to iter0_confirm_paid_action. It does not name the alternative to use when the person wants to edit or open an existing site, so sibling routing is only partly covered.

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