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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds the key behavioral nuance that this tool builds a URL for independent browser verification rather than performing the search itself or returning ad data. No contradiction with 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?

Two sentences, no filler: the first states the action and output, the second provides a practical trigger. The most important content is front-loaded.

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 simple URL-builder with readOnly annotations, an output schema, and all parameters optional, the description fully covers what the tool does, why it exists, and when it should be used. Nothing essential 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?

Description only refers generically to 'a set of filters' and gives no parameter-specific semantic help. Schema descriptions cover only three of five parameters, and the description doesn't compensate for the undocumented media_type and active_status semantics beyond their enum values.

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?

Description uses a specific verb ('Turn'), a clear object ('a set of filters'), and a concrete deliverable ('public Ad Library URL'). It distinguishes itself from sibling data-returning tools by emphasising browser-verifiable output rather than ad records or search results.

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 explicitly states when the tool is useful: when a search returns empty and the user needs to distinguish 'no results' from 'blocked'. It does not name alternative tools, but the use case is concrete enough for an agent to select it.

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?

The annotation already marks the tool as read-only, idempotent, and non-destructive, so the description does not need to repeat those. It adds useful behavioral context by revealing that the tool can explain cost-per-call and availabe optional features, which matters for deciding whether an unavailable action is actually impossible or merely unsupported.

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 filler. The first sentence lists exactly the information returned, and the second gives the precise moment to call the tool. Everything in the description 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?

The tool takes no inputs, has an output schema, and has unambiguous read-only annotations. The description is sufficient for an agent to know when and why to call it, and because there is an output schema, the description need not enumerate return fields.

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 input schema requires no parameters, so the description has no parameter meanings to add. The tool's whole purpose is self-contained, and the description adequately conveys that calling it requires no arguments.

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 clearly states what the tool reports: the active backend, per-call cost implications, and available optional features. This distinguishes it from the ad-focused sibling tools, which all operate on ads or advertisers rather than on backend configuration.

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 condition: call this when another tool reports something unavailable, and just before informing the user that something cannot be done. This is concrete, actionable usage guidance and there are no alternative sibling tools that compete with this purpose.

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 declare readOnlyHint=true and idempotentHint=true, but the description says the first call records a baseline and later calls report movement. This is a persistent server-side side effect and repeated identical calls intentionally return different results, directly contradicting the idempotent and read-only hints. Flagged as Annotation Contradiction.

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 core purpose, then the key stateful caveat, then the sibling distinction. Every sentence earns its place and there is 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?

For a low-complexity tool with a full schema and an output schema, the description provides the needed operational details: baseline behavior, expected first-use outcome, and when to call again. It is nearly complete, but the contradiction between the stateful behavior and the idempotent/read-only annotations leaves some context unresolved.

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%, with all three parameters documented including the limit consistency note and country default. The description itself adds no extra parameter semantics, so the baseline of 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?

States a specific action (compare/report changes) on a specific resource (advertiser's ads), and immediately distinguishes itself from siblings: 'the only tool here that answers what changed rather than what is running.' An agent can tell what it does 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?

Explicitly handles the first-call case (records a baseline, reports nothing changed) and tells the agent to call again later to see movement. It also names the conceptual alternative category, tools describing what is running, so an agent knows when not to use it.

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. The description adds meaningful behavioral detail about the comprehensive nature of the response: 'every creative, all copy variants, the full destination URL and any transparency data'. This goes beyond what the annotations alone convey and sets expectations for output completeness.

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 filler. The first sentence states action and coverage; the second gives usage guidance. The most important information is front-loaded and every sentence 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?

For a simple single-id fetch tool, the description covers what, when, and why, while the input schema covers parameters and the output schema covers return structure. Annotations cover the safety profile. Nothing essential is missing for an agent to select and invoke this tool correctly.

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 library_id and country. The description itself does not add parameter-level semantics beyond referring to 'Ad Library ID', which matches the schema. Baseline 3 is appropriate because the schema carries the load.

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 and resource: 'Fetch a single ad by its Ad Library ID'. It enumerates the scope of what is returned ('every creative, all copy variants, the full destination URL and any transparency data'), which clearly separates it from bulk search tools and narrower sibling tools like view_ad_creative or get_eu_transparency.

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 explicitly says 'Use this after search_ads when one ad is worth studying properly', giving clear when-to-use context and naming the relevant sibling workflow. It does not enumerate when-not-to-use cases or alternative tools for narrower lookups, but the placement and rationale are clear enough.

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 read-only, idempotent, and non-destructive, but the description adds meaningful extras: the META_ADS_ARCHIVE_TOKEN requirement and the critical non-error empty-result behavior for unpublished data. This goes beyond what annotations and schema provide.

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 with no filler: core function first, scope second, and the important empty-result and auth notes last. Every sentence carries necessary 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?

Output schema exists, annotations cover safety, and the description covers purpose, scope, an important edge-case behavior, and the required token. An agent has enough to select and invoke this tool correctly without hidden surprises.

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?

All four parameters are already fully described in the schema with meaning for limit, query, country, and page_ids. The tool description does not add significant parameter-level semantics beyond that, 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 clearly identifies the resource (Meta's official Ad Library API) and the data returned (spend, impressions, reach, demographic breakdown). It also states the scope (EU-delivered ads and political or issue ads anywhere), which distinguishes it from general ad lookup tools.

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 provides clear context for when to use it: EU ads and political/issue ads anywhere, and explicitly says an ordinary US commercial ad will return nothing rather than an error. It doesn't name a specific sibling alternative, but the exclusion is enough to prevent misuse.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context: it returns actual advertiser Pages and ranks them by ad count, which sets expectations beyond the annotations alone.

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 tightly written sentences cover purpose, ranking behavior, usage context, and the relationship to search_ads. There is no filler or redundant restating 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?

With a rich set of annotations, full schema coverage, and an output schema present, the description supplies the missing strategic context: when to use it and what to do with the result. Nothing critical is left unexplained for correct tool selection and invocation.

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 both 'query' and 'country'. The description reinforces that 'query' is a brand name but does not add any new parameter-level detail, so the baseline of 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 uses a specific verb, 'Resolve', and names the resource (advertiser Pages) and the key output property (ranked by number of ads running). It clearly distinguishes this tool from siblings like search_ads and get_ad by focusing on brand-to-Page-ID resolution.

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 explicitly states when to use this tool first (when you know the brand but not the Page ID) and gives the follow-up path (pass that ID to search_ads). This provides clear routing relative to sibling tools.

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 signal a safe, read-only, idempotent operation, so the description adds behavioral value by disclosing that spend and reach are null outside the EU and that this is expected rather than an error. It also clarifies the return scope (advertiser, copy, creative count, etc.), which helps the agent interpret results correctly.

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, each earning its place: the action, the return content, and a critical data caveat. The most important behavior is front-loaded, and the paragraph stays compact despite covering several nuances.

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?

Given the tool has 7 well-documented optional parameters, an output schema, and safe read-only annotations, the description is complete enough. It covers selection-relevant scope, the null-data gotcha, and the returned fields, leaving only details that are already in the schema.

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% and each parameter already has a rich description, including the query/page_id trade-off and defaults. The description frames keyword vs. page_id as two modes but adds little meaning beyond what the schema already states, so the baseline of 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?

States a specific verb ('Search') and a clear resource ('Meta's public Ad Library'), and distinguishes two invocation modes: keyword search or listing all ads for a page_id. The phrase 'list every ad from one advertiser by passing page_id' also differentiates it from sibling tools that fetch a single ad or advertiser list.

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 sets useful context: it works for ordinary commercial advertisers in any country, and it preempts the EU spend/reach caveat. The schema adds explicit routing guidance ('Use list_advertisers first if you only know the brand name'), but the description itself does not spell out when to prefer siblings like get_eu_transparency or get_ad. This is clear context with room for firmer exclusion guidance.

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, and non-destructive behavior. The description adds a valuable behavioral detail beyond those annotations: on unsupported backends it explains the limitation rather than failing silently. This is meaningful runtime behavior that an agent could not infer from the schema or annotations alone.

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 compact and front-loaded, stating the core purpose first and then adding the important backend caveat. Every sentence earns its place with no wasted words or redundant restatement of the title.

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 single-parameter tool with rich annotations and an output schema, the description covers the essential context: what it does, what input it needs, and a key behavioral constraint. The only minor gap is that it does not mention any prerequisites for identifying video ads, but this is likely supplied by the library_id semantics and sibling tool context.

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 schema already fully describes the single parameter, library_id, with 100% coverage, so the baseline is 3. The description adds no new meaning about the parameter beyond what the schema provides, but it also does not need to given the high schema coverage.

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 clearly states the function: converting a video ad's spoken script into readable text. It identifies the resource (video ad) and the specific operation (speech-to-text transcription), but it does not explicitly differentiate itself from siblings like view_ad_creative or get_ad beyond the transcription action itself.

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 provides important backend-specific context: only the scrapecreators backend can perform transcription. However, it does not explain when an agent should choose this tool over siblings or what conditions make transcription appropriate, so usage guidance is only implicit.

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 mark it read-only, idempotent, and non-destructive, and the description adds meaningful runtime behavior: carousels return each card in order, video ads report that they have no still, and the tool needs no API key. These disclosures go well beyond the annotations and help an agent predict outcomes.

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 front-loaded with the core purpose, then moves to use cases, edge behavior, and authentication. Every sentence contributes either usage guidance or behavior; there is no repetition or 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?

For a read-only image-retrieval tool with no output schema, the description covers what is returned, the carousel order, the video fallback, input provenance via schema, and authentication. An agent has enough to decide when to call it and what to expect.

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 limit, country, and library_id clearly. The description adds carousel ordering and video behavior but no extra parameter-specific meaning beyond what the schema provides, 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?

The description uses a specific verb and resource: 'Return the actual images from one ad so you can see them.' It also distinguishes the tool from copy-focused siblings by framing it against 'rather than only reading its copy,' and grounds it in visual questions like 'visual hook, layout, product shot.'

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 explicitly says when to use it: 'when the question is about what an ad looks like,' with concrete examples. It also states when not to expect results ('Video ads have no still to show') and that no API key is needed. However, it does not name sibling tools like get_ad or transcribe_ad as alternatives, only contrasting with 'reading its copy' indirectly.

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