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

With no annotations, the description carries the full burden, and it does disclose real behavior: zero credit cost, bounded/explicit source acquisition, and that results retain dates, scope and confidence. That provenance and cost disclosure is genuinely useful beyond structured fields. Gaps remain: no mention of read-only nature, pagination via `cursor`, result volume, or failure modes for invalid tool/mode pairings.

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?

It is front-loaded with a usable one-line summary and stays to four sentences, but the middle sentence is a dense run-on list of data sources with no mapping to the `tool` enum. Sentences like "Ad text and Publisher ID reverse lookups cover the recorded collection" are vague filler that does not help an agent act.

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 an 11-parameter, 0%-documented dispatcher over eight sub-tools and five modes with no annotations and no output schema, the description should be doing far more. It omits filter/fan-out semantics, cursor pagination, region scoping, and the valid tool/mode matrix, leaving most invocation decisions to guesswork.

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 0% across 11 parameters, so the description must compensate and only partly does. It implicitly maps a few sources to `tool` values ("Google ads", "public Meta ads", "AdSense", "outbound page links", "DR changes") and hints at `mode` ("by domain or advertiser", "by keyword"), but says nothing about `limit`, `cursor`, `region`, `minDr`/`maxDr`, `minVisits`/`maxVisits` or `maxAgeMonths`. Most critically, the required relationship between `tool` and `mode` is never explained.

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?

"Free early-access standalone site research" plus an enumeration of ad/AdSense/link/DR data sources conveys the general domain, and "all these tools" hints that the `tool` enum dispatches sub-queries. But it never states plainly that this is a single dispatcher over eight sub-tools, and it draws no boundary against close siblings like lookup_domain and lookup_keyword. An agent can guess the purpose but not cleanly distinguish it from its neighbours.

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?

"Free" and "spend 0 credits" give a cost-based reason to prefer this tool, but there is no explicit when-to-use/when-not statement and no alternative is named despite heavy overlap with lookup_domain, lookup_keyword and compare_bulk. "Source acquisition is explicit and bounded" is unexplained jargon rather than actionable selection guidance.

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