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

With no annotations provided, the description carries the full disclosure burden. It usefully discloses the audit breadth (~30 rules across six coverage areas) and the return format (verdict, per-rule analysis, rewrite suggestions). However, it does not explicitly confirm whether the operation is read-only or clarify the precedence when both 'url' and 'text' are supplied.

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 two sentences that front-load the core purpose ('Run the full GDPR + ePrivacy marketing self-audit (~30 rules)') and then list coverage areas and outputs. Every clause earns its place—rule count, scope, and returns are all material—with no filler or redundancy.

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 correctly explains returns (verdict, per-rule analysis, rewrite suggestions), and the coverage list sets accurate expectations for a 30-rule audit. Minor gaps remain around operational details like url-versus-text precedence and explicit read-only confirmation, but the rich schema and clear scope make this largely complete.

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 100%—all three parameters (url, text, asset_type) are well-documented, including the SSRF guard note and exhaustive asset-type examples. The description adds contextual framing about what the audit examines but no per-parameter meaning beyond the schema, so the baseline of 3 applies.

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 uses a specific verb and resource ('Run the full GDPR + ePrivacy marketing self-audit (~30 rules)') and further delimits scope with a concrete coverage list (cookie banners, email/SMS opt-in, signup forms, privacy notices, marketing automation, ad-pixel placement). The GDPR/ePrivacy focus clearly distinguishes it from sibling regime-specific tools like run_fca_pro_check and run_sec_pro_check.

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 usage context is implied through the 'marketing self-audit' phrasing and the asset types in the schema (landing page, ad, email, etc.), but no explicit when-to-use or when-not-to-use guidance is given. Alternatives such as get_lite_ruleset for a lighter check are not mentioned, and no exclusions are stated.

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