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

Annotations declare readOnlyHint=false and destructiveHint=false, so the write surface is partially covered; the description adds real value by disclosing the side effect that own-domain scans are persisted and that apply=true mutates the site's banner configuration. It stops short of saying whether apply is reversible or what permissions/plan are required.

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?

Two tight sentences: capability and detected signal types first, then the persistence and apply semantics. Every clause carries information an agent needs; no filler.

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 no output schema, the description must carry return semantics, and it names the headline output (0–100 compliance score). It omits the shape of the rest of the result (per-tracker detections, cookie list, Consent Mode findings) and whether the scan is synchronous or asynchronous, which matters for an open-world network fetch.

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 all three parameters are already documented. The description restates the apply behavior and adds the useful default-resolution rule ("otherwise matched by domain") for site_id, but provides no format or constraint detail beyond the schema. Baseline 3 is appropriate.

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?

Specific verb ("Scan") plus a concrete resource ("a public web page") and an enumerated list of what it detects (GA4, GTM, Meta Pixel, cookies, Consent Mode) with a 0–100 score output. It does not, however, differentiate itself from the sibling pre_consent_scan, which reads as a closely related scan operation.

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 conveys context ("Scans of your own domains are saved") and the effect of apply=true, which implies when the mutation path is appropriate. But it never states when to choose this over pre_consent_scan or configure_banner, and no exclusions or prerequisites are given.

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