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

Goes well beyond the annotations: a real browser visits home/product/cart for up to 90 seconds, the scan returns grade/score/problems with no fixes, the full PDF report is sent by the agency, and there is a per-email daily cap plus an asynchronous 'running' state. This is unusually rich behavioral context for a non-idempotent open-world tool.

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?

Front-loads what is scanned, then return shape, then the consent/rate-limit workflow, then the polling fallback. It is long, but nearly every sentence carries a distinct operational instruction; only the enumeration of tracking technologies is dense enough to slow reading.

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 complex, non-idempotent, open-world tool with no output schema, the description still explains the return payload (grade, score, problems list, e-mailed PDF), the async polling path, consent obligations, and limits. An agent has everything needed to call it correctly and legally.

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 genuine meaning: the consent semantics of zgoda (only true after explicit agreement), the rule that email must be user-supplied and is the sole delivery target, and the note that only the home domain of url is used. It reinforces rather than merely restates the schema.

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?

Names a specific action (free analytics/tracking scan) and enumerates exactly what is checked: GTM, GA4 and e-commerce events, consent banner/Consent Mode v2, server-side tagging, Meta Pixel and Conversions API. This is clearly distinct from siblings like get_scan_result (retrieval) and scan_ai_visibility (different domain).

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?

Gives explicit preconditions (tell the user the report goes to their e-mail, get consent, set zgoda only after agreement), a rate limit (max 2 scans per e-mail per day), a constraint (never invent an e-mail), and a routing rule (if status is 'running', call get_scan_result after 30-60s). Alternatives and when-not conditions are covered.

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