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

Annotations (readOnlyHint=true, openWorldHint=true) already carry the safety profile, and the description adds the key behavioral contract — the boolean result signals rentability, which is exactly what an agent needs to interpret the call. No side effects, auth requirements, or rate limits are disclosed, but for a read-only check with an output schema these are minor gaps. No contradiction with annotations exists.

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 purpose and return contract are front-loaded in the first sentence, and every sentence earns its place. The tip is slightly long but substantive — it explains why input choice matters and grounds the guidance with concrete examples rather than padding.

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 read-only tool with a full output schema and safety-carrying annotations, the description covers purpose, return contract, and input strategy comprehensively. The only notable gap is sibling differentiation (try_domain near-miss), which leans more toward usage guidance than completeness.

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 100%, so the baseline is 3, but the description adds genuine value beyond the schema: it explains the conceptual relationship between domainId and subdomain ('the subdomain and domain read as one phrase') and gives concrete selection guidance with examples (iamyour.slopmommy.com). This helps an agent construct high-quality, contextually appropriate inputs, not just schema-valid ones.

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 states a specific operation — checking whether a specific subdomain is available on a given domain — with an explicit return contract ('Returns true if the subdomain can be rented'). The subdomain-vs-domain scope cleanly distinguishes it from siblings like search_domains and rent_domain even without naming them, so an agent knows exactly what this tool does.

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 tip provides substantive guidance on how to choose good subdomain inputs ('pick a single lowercase label that is funny or fits the domain's theme') and explains the phrase-joining concept with examples, which helps an agent invoke it effectively. However, there is no explicit when/when-not guidance or alternative routing — notably it never mentions try_domain, which may overlap as an availability check, nor does it say to call this before rent_domain.

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