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

Goes far beyond the readOnly/openWorld annotations: discloses advertiser-name typeahead resolution to legal entity, region-scoped results with per-market `countries`, relevance ranking with recency only as a tiebreak (explicitly not date-ordered), cursor pagination of 12, non-disjoint pages that can repeat ads, political ads excluded, reach reported as a band in `raw.estimated_audience`, and a 1-credit cost.

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 purpose and search modes, then dense operational caveats, nearly all of which are decision-relevant (region requirement, ranking, page overlap, reach semantics, credit cost). It is information-rich but quite long and clause-dense, costing a little on readability.

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 5-param read tool with no output schema, the description covers what an agent needs: required params and their semantics, return shape hints (`countries`, detail URL, `pagination.cursor`, `raw.estimated_audience`), ordering guarantees, and pagination behavior.

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 already 80%, so the baseline is 3; the description adds real meaning by explaining that `region` is validated against the library's own published market list (rather than a fixed local list) and that `advertiser_name` matches the registered legal name ("NIKE Retail B.V.") rather than a brand. It adds little for `query`, `cursor`, or `cache_max_age` beyond the schema.

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+resource ("Search the TikTok Ads Library") and immediately enumerates the two search modes (keyword `query` vs `advertiser_name`). This lets an agent distinguish it from tiktok_adLibraryAd (detail fetch) and the analogous facebook/google ad-library search tools without opening any 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 clear when-to-use framing: it is the search entry point, `region` is mandatory and required, and political/election ads are out of scope. It does not explicitly name which sibling to call for per-ad detail (tiktok_adLibraryAd) or how it differs from the other platform ad searches, so it falls short of full alternatives routing.

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