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

Annotations only declare readOnly/openWorld/idempotent/non-destructive; the description goes well beyond them by disclosing the two-step payment flow (validate, return payment_url, POST over MPP/HTTP 402), the $8.00 price, the charge-only-on-sound-run policy, the refusal-on-failed-control behavior, and the run id/date/citation line attached to every result. That is exactly the kind of cost, auth and failure-mode context annotations cannot carry.

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 trigger is correctly front-loaded, but the body is bloated: pricing is stated twice ('This tool charges nothing' followed later by 'Price: $8.00 per run'), and the payment mechanics, safety claims and sample URL are packed into one dense paragraph. The information is useful but not tightly organized.

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 paid, open-world tool with no output schema, the description covers the return shape (counts of answers, ownership verdict, stability across askings, your domain's position), the cost, the payment protocol and a free sample link. The only gap is that the exact response structure and the optional q3 behavior are left implicit.

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%, so the baseline is 3, but the description adds real meaning: it clarifies that q1-q3 are buyer questions posed live to four assistants and each is asked twice, and that domain is used to report where your own site stands. It does not add format or phrasing guidance for the questions beyond the schema's length limits.

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 names a concrete verb and resource: it asks ChatGPT, Claude, Gemini and Perplexity 2-3 buyer questions live and returns the most-cited domains with an ownership verdict (owned/led/contested/fragmented). It also explicitly scopes out what it does not return ('Not the answers themselves'), which separates it from answer-content siblings like run_ai_visibility or run_share_of_search.

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 opening 'Use when the user asks which brands or websites AI assistants rely on... who they are competing with... or whether any source dominates' gives a clear, concrete trigger condition. It stops short of naming an alternative sibling and the condition that would select it, so it is strong context without explicit routing.

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