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

Annotations already declare readOnly/idempotent/non-destructive/no-open-world, so safety is covered. The description adds real behavioral context beyond that: the output is a human-openable public URL for independent verification, and the tool is a diagnostic fallback. It doesn't mention form/expiry of the URL, but the added context is substantive.

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 sentences, front-loaded with what the tool produces, followed by the diagnostic rationale. No filler, no repetition of the title or schema.

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?

An output schema exists (the URL) so return values need no explanation, and annotations cover the safety profile. The description supplies purpose plus the key diagnostic rationale, leaving only minor gaps such as whether any filter combination is invalid.

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?

At 60% schema description coverage, three params (query, country, page_id) are documented in the schema and two (media_type, active_status) are covered only by self-explanatory enums. The description adds nothing parameter-specific beyond the generic word 'filters', so the schema does the heavy lifting and the baseline 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 states a specific verb and resource: it 'turns a set of filters into the public Ad Library URL.' That is unambiguous and clearly distinct in kind from the retrieval siblings (search_ads, get_ad), though it never names an alternative tool to contrast against, so it stops short of a 5.

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?

It gives a concrete usage context — diagnosing whether an empty search means 'no results' versus 'blocked' — which is exactly the situation that selects this tool over search_ads. It provides no explicit when-not-to-use or named alternative, so 4 rather than 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds no behavioral traits beyond that (no side effects, auth needs, or rate limits), and the return content it names is already captured by the existing output schema. No contradiction, but limited added value.

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 with no filler. The purpose is front-loaded and the call condition follows immediately, so every clause earns its place.

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 an output schema documenting return values and annotations covering safety, the description only needs to convey purpose and when to invoke it, and it does both. Nothing an agent needs to call a zero-parameter diagnostic 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument diagnostic call.

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 first sentence states exactly what the tool reports: the serving backend, per-call cost, and available optional features in the current configuration. This is a distinct diagnostic/config resource that cannot be confused with any ad-related sibling tool, so an agent can identify its role without opening the schema.

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?

It gives an explicit trigger: 'Call this when a tool reports something unavailable, before telling the user it cannot be done.' That is a clear, actionable condition. It does not name when-not-to-call or alternatives, but the siblings are unrelated ad tools with no overlapping function, so there is little to exclude.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior, so the description's added value is the baseline/no-op-on-first-call semantics and the dependency on when the server last looked, both genuinely non-obvious. It stops short of anything about snapshot freshness limits, rate limits, or how a large limit affects the diff, so it is strong but not exhaustive.

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?

Three sentences, front-loaded with the action and outcome, then the baseline caveat, then the sibling differentiation. No filler and nothing buried.

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?

An output schema exists, so return shape need not be explained; the description instead spends its words on the one thing an agent would otherwise get wrong (the empty first diff). For a 3-parameter read tool with full annotation coverage, nothing needed to call it correctly 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 schema already documents page_id, limit and country, including the 'keep limit consistent between calls' advice. The description adds no parameter-level detail beyond the comparison framing, which is the expected baseline when the schema does the heavy lifting.

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?

States a specific verb and resource: compare an advertiser's ads against the last snapshot and report what started/stopped. It explicitly positions itself against every sibling with 'the only tool here that answers "what changed" rather than "what is running"', so an agent can route without opening another schema.

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 the non-obvious usage condition directly: the first call records a baseline and reports no change, so it must be called again later to observe movement. It also states the differentiation from search_ads/list_advertisers-style tools, leaving little to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds content-scope behavior (full creative, all copy variants, transparency data) that helps the agent anticipate result richness beyond what the annotations say.

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 sentences, zero filler, with the resource and return scope front-loaded before the routing hint. Every clause earns its place.

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 rich annotations, an output schema, and fully documented parameters, the description needs only to state purpose, scope and routing, which it does. Nothing an agent needs to invoke it correctly 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% and both parameters are documented in the schema, including the country default of US. The description reinforces the library_id meaning ("the long number in an ad's URL" is already in the schema) but adds no new syntax or format detail, so baseline 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?

States a specific verb (Fetch) and resource (a single ad by Ad Library ID) and enumerates exactly what is returned: creative, copy variants, destination URL, transparency data. This distinguishes it clearly from search_ads, which retrieves sets rather than one ad in full.

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?

"Use this after search_ads when one ad is worth studying properly" names the sibling and the condition that selects it, which is real routing guidance. It stops short of an explicit when-not or a note on other siblings like view_ad_creative, so it is clear but not exhaustive.

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

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

Annotations already cover the read-only, idempotent, open-world, non-destructive profile, so the bar is lower. The description still adds real context: the empty-result case is a valid answer rather than an error, and a free token is required. It doesn't discuss rate limits or pagination behavior.

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?

Three sentences, front-loaded with what is returned and where, followed by the non-obvious empty-result semantics and auth need. No filler or repetition of structured fields.

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 an output schema present, return-value explanation is unnecessary, and the description covers scope, the negative-result edge case, and the credential requirement. An agent has everything needed to call it and interpret an empty response.

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 all four parameters are already documented, including the DE default and the page_ids-vs-query distinction. The description adds only indirect meaning via the EU/political scope, so the baseline 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?

States a specific resource set (spend, impressions, reach, demographics) from a named source (Meta's official Ad Library API), which no sibling like search_ads, get_ad, or list_advertisers provides. The EU/political scope clause further pins down the resource it returns.

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?

Explains the crucial when-not case: an ordinary US commercial ad yields nothing and that is the correct answer, not a failure. It also states the auth prerequisite (META_ADS_ARCHIVE_TOKEN). It stops short of routing the agent to a specific sibling for non-EU/non-political ads.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are ranked by ad volume, and the tool performs fuzzy brand-name resolution rather than exact lookup. It does not mention result limits or ambiguity handling, so it stops short of a 5.

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 sentences, no waste, front-loaded with the core purpose and followed by the workflow handoff. Every clause earns its place.

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 an output schema present, the description needn't explain return values, and it covers purpose, ranking, and the chaining workflow to search_ads. Nothing an agent needs to select or invoke this tool correctly 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 coverage is 100%, so both parameters are already documented, and the description adds no syntax or format detail for them. It clarifies the intent of the query (brand-name resolution) but says nothing about the country parameter, so the baseline 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?

States a specific verb (resolve) and resource (brand name → advertiser Pages), plus the ranking behavior. It is clearly distinguishable from search_ads and the other siblings, which retrieve ads rather than resolve brand names to Page IDs.

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?

Explicitly says to use this first when you know the brand but not its Page ID, and names the downstream alternative (search_ads) plus the handoff artifact (the ID). This is a complete when/when-not routing instruction.

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

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

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's real contribution is behavioral: it lists what comes back (advertiser, copy, creative count, domain, CTA, platforms, run duration) and preempts a likely misinterpretation by explaining that null spend/reach outside the EU is expected, not an error. That is genuinely additive context beyond the annotations.

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?

Three sentences, zero padding, with the core capability front-loaded and the EU-data caveat placed at the end where it serves as a footnote. Every sentence carries information an agent needs.

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 read-only search tool with a full input schema, output schema, and complete annotations, the description supplies the missing pieces: the two search modes, the returned field set, and the EU spend/reach caveat. Nothing needed to call it correctly is absent.

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 schema already documents all seven parameters, including enum values and defaults. The description reinforces the query/page_id mode split but adds no syntax, format, or default detail beyond what the schema states, 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 names a specific verb and resource ('Search Meta's public Ad Library') and cleanly separates its two invocation modes: keyword search versus listing all ads for one advertiser via page_id. It stops short of differentiating itself from siblings like get_ad or list_advertisers, so it is clear but not fully sibling-aware.

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?

It gives clear context for choosing between the two modes ('by keyword, or ... by passing page_id') and states the domain of applicability ('ordinary commercial advertisers in any country'). There is no explicit when-not guidance or pointer to alternative tools, which keeps it below a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely new behavioral context: the backend dependency and the graceful-degradation behavior ('explains that rather than failing silently'), which an agent needs to interpret a non-transcript response. It does not contradict any annotation.

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?

Three short sentences, zero filler, and the core purpose is front-loaded before the backend caveat. Every sentence carries distinct information.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies the key operational caveat (backend requirement, non-silent failure), though it omits any note about non-video ads or transcript availability limits.

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?

There is a single required parameter whose schema description (100% coverage) already documents it as the Ad Library ID of a video ad. The description adds no extra meaning about the parameter, so the baseline 3 for high schema coverage 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?

States a specific transformation (speech to text) on a specific resource (a video ad) and clarifies the output is the readable spoken script. This is clearly distinguishable from siblings like get_ad or view_ad_creative, which retrieve ad data rather than transcribe it.

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 states a precondition for success ('Only the scrapecreators backend can do this') but never says when an agent should choose this tool over alternatives such as view_ad_creative, nor which ads are eligible. Usage is implied (you want the transcript of a video ad) rather than explicitly guided.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for the extra behavior it discloses: carousels return each card in order, video ads have no still and report that instead, and it needs no API key. These edge cases and auth details go well beyond structured fields.

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-loaded with the core action, followed by when-to-use, then edge-case behavior in compact sentences. Every sentence carries distinct information with 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 compensates by explaining return shape for carousels (each card in order) and the video-ad exception, and annotations carry the safety profile. Nothing needed to invoke it correctly 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 library_id, country, and limit are already fully documented, including the 'up to 6' limit and 'Carousels have several' note. The description adds no param syntax or format detail beyond that, making the baseline 3 correct.

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 states a specific verb+resource: 'Return the actual images from one ad.' It distinguishes itself functionally from copy-reading siblings via 'rather than only reading its copy,' which implies the contrast with get_ad, though no sibling is named outright.

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?

It gives concrete trigger conditions: 'Use this when the question is about what an ad looks like: the visual hook, the layout, the product shot...'. Strong when-to-use guidance, but no explicit when-not or named alternative such as get_ad for text-only questions.

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