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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds genuinely useful operational context: live registry data, free/no API key, shared fair-use pool with per-caller daily allowance, Instagram returning a confirm-link, and 'Not legal advice.' These are behavioral details beyond the annotations and schema.

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 long but every segment adds value — scope, result contents, usage triggers, alternative routing, cost/access caveats, and data source. It is front-loaded with the core action and the one-name limitation, and the later sentences deepen rather than repeat.

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?

With one required parameter and an output schema present, the description still covers the full decision context: what the check covers, what the output includes, when this tool is appropriate, when to use check_names, access constraints, and non-legal caveat. Nothing an agent needs to correctly select or invoke it is missing.

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%, and the schema already instructs 'Plain name only — no URL, no TLD, no @handle' and to use check_names for multiple names. The description reinforces that this checks a single name but does not add much parameter-level meaning beyond what the schema already provides.

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 opens with a specific verb and resource: 'Run a free Clearance Check on ONE brand, business, product or app name.' It enumerates the exact checks performed (USPTO, EUIPO, domains, social handles, developer namespaces, iOS App Store) and explicitly contrasts itself with check_names, so an agent can distinguish it without inspecting other 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?

It gives explicit when-to-use guidance: 'Use it when the user asks whether a SPECIFIC name is taken...' and covers everyday naming moments. It also names the alternative for shortlists: 'For a shortlist or comparison use check_names instead' — clear routing to the sibling tool.

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