Check website traffic rank (coming soon)

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

The description goes well beyond the annotations (readOnlyHint=true, destructiveHint=false). It discloses the 'coming soon' status and its error behavior, the fact that it does not visit websites, the ranked=false outcome for unranked domains, cost per domain, and the spending cap behavior. This is rich behavioral context that an agent needs to handle calls correctly.

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 sentence conveys necessary information. It is well-structured: it begins with the critical 'coming soon' caveat, then explains the tool's purpose, data sources, outputs, use cases, limitations, and cost. It is not concise in word count, but it is efficient in packing value without redundancy, earning a 4 rather than a 3.

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 4 parameters and no output schema, the description does a thorough job of covering what an agent needs: it describes the output fields (countryRanks, topCountries, ranked=false), error behavior, cost, and how parameters affect results (includeCountries flag). It even notes the behavior for subdomains and timeout handling. The description is complete for correct invocation and expectation setting.

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% and each parameter has a description. The tool description adds extra meaning beyond the schema: it explains subdomain fallback behavior, the default for maxTotalChargeUsd with a server setting, and advises splitting batches to avoid timeout. This adds practical guidance not present in the schema, elevating the value above the baseline of 3.

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: checking website traffic ranks and popularity tiers. It specifies the resource (websites) and the verb (check), and details exactly what it outputs (global tier, country tiers, Majestic rank, etc.). It also distinguishes itself from alternatives by noting it gives tiers, not exact positions or monthly visit counts, and that it does not visit websites.

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 explicitly lists use cases: lead scoring, competitor and market research, vetting publishers, affiliates, link-building targets, and market sizing by country. It also sets expectations for when results are free (ranked=false) and notes the tool's limitation (tiers, not exact numbers), implying alternative tools are needed for exact data. This is helpful, though it does not explicitly name sibling tools as alternatives.

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