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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fully discloses the read-only nature, the public-data scope, the EU/UK coverage limitation, the return fields (page, creative text, platforms, delivery dates, permalink, pagination cursor), and the meaning of empty results. It also explicitly warns against overpromising, which is critical behavioral context an agent needs to avoid misleading users.

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 a single paragraph but well-structured: purpose first, then return details, then the coverage ceiling and its implications. It is slightly long but every sentence carries necessary information, especially the coverage warning. It is front-loaded with the main purpose and distinguishes siblings early. It earns a 4 rather than 5 because a bit more trimming could make it punchier, but it is far from verbose.

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 tool with 8 parameters, no output schema, and no annotations, the description is remarkably complete. It covers what the tool returns, pagination, the coverage ceiling, and alternatives. It also addresses edge cases (non-EU/UK results) and provides guidance on interpreting empty results. Nothing an agent needs to invoke it correctly or manage user expectations is missing.

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%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it reiterates the coverage ceiling for countries and why ad_account_id is required, but these are already in the schema descriptions. It does not introduce new parameter semantics, so the 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?

The description opens with a specific verb-resource pair ('Search Meta's public Ad Library for ads') and immediately states the two use cases: competitor research and ad transparency. It distinguishes itself from related tools by explicitly naming adsap_list_campaigns/adsap_get_insights as the alternatives for the caller's own ads. The coverage-ceiling note further clarifies the tool's exact scope, leaving no ambiguity about what it does or does not do.

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 gives explicit when-to-use and when-not-to-use guidance. It states 'not your own account's ads — use adsap_list_campaigns/adsap_get_insights for that' and warns against promising non-EU/UK competitor research, pointing users to the public Ad Library website for those markets. It also explains the coverage ceiling as Meta's rule, so an agent knows when to expect zero results and how to interpret them.

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