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

With empty annotations, the description carries the full burden of behavioral disclosure. It discloses the one-time fee, the 402 payment fallback path, the requirement that the lease be live, and the proxy behavior for Cloudflare hostnames. It doesn't fully describe success-response semantics or reversibility, but it goes well beyond a minimal description.

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 dense but every sentence contributes critical info: DNS mechanics, billing model, Cloudflare edge case, and card/PromptPay fallback. Some phrasing feels slightly repetitive ('while lease is live' and 'Not a monthly fee' could be consolidated), but the overall structure is efficient enough.

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?

The description covers prerequisites (lease live, existing hostname), the payment fallback with a 402 response, and the post-payment polling step ('poll preview_status/retry until live'). It doesn't return the details of a successful response, which is a modest gap given the absent output schema.

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?

The input schema provides no description coverage for slug or hostname, so the description must compensate. 'hostname' is inferable from the prose, but 'slug' is never explained, its role in identifying the lease or wallet remains ambiguous ('same claiming wallet' helps only indirectly). This is a clear gap in per-parameter semantics.

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 function: connecting an existing hostname via CNAME to sites.sornkan.com without registrar involvement. It also distinguishes this from recurring-fee tools by noting 'Not a monthly fee' and 'One-time $1 USDC', though it doesn't explicitly name competing siblings.

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 includes a conditional payment flow ('If you have no wallet, get payment_url from the 402 response') and practical guidance for Cloudflare-hosted CNAMEs ('keep the CNAME proxied'). It does not explicitly list alternative sibling tools to choose between, but the context is clear enough for when this tool is appropriate.

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