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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, and the description still adds real behavior: typeahead resolution of advertiser names, adv_biz_ids returned per ad, fallback to name search when no entity matches, global scope, latest-date ordering, and cursor pagination. The cost section undercuts this by stating both 'at least 10 Nexscope credits' and '1 credit per request', leaving the actual charge ambiguous.

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 core behavior is front-loaded in clear sentences, but the trailing block is noisy: duplicated title text ('TikTok Ad Library Ad Library Search'), repeated promotional phrasing, and mutually inconsistent credit figures. Roughly a third of the description is boilerplate that does not help an agent call the tool.

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, four-parameter search with no output schema, the description covers input modes, resolution/fallback behavior, return contents (adv_biz_ids, TikTok Ads Library URL per ad), ordering, pagination, and cost. An agent has everything needed to invoke it correctly; only the pricing detail is muddled.

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 the baseline is 3, but the description adds interaction semantics the schema fields only partially convey: advertiser_name is resolved through the typeahead to an entity, adv_biz_ids pins that entity, and the two must be supplied together. It still adds little about cursor semantics or query syntax beyond what the schema says.

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 a specific verb and resource (searches TikTok's public Ads Library) and immediately splits the two operating modes: general query vs. advertiser-specific results. An agent can distinguish this from social_tiktok_ad_library_ad and social_facebook_ad_library_search_ads 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?

It gives an explicit selection rule for the two search modes ('provide exactly one of query or advertiser_name') and explains the adv_biz_ids + advertiser_name combination with the failure mode (ID-only returns 400). It does not route the agent to sibling tools such as the ad-detail endpoint, so there is no when-to-use-this-instead guidance.

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