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

With no annotations, the description carries the behavioral disclosure burden. It discloses that the tool makes multiple API calls, that it can either preview or preview-and-save depending on the `name` parameter, and that the `advertiser_id` must be owned by the user. It does not mention rate limits or failure modes, but for a tool of this complexity the key side effect (persistence) is clearly surfaced.

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 well-structured with clear sections for purpose, behavior, required/optional params, and an example. It is somewhat verbose with the 'Mirrors the Meta sister-product' aside and endpoint lists, but each part contributes to agent comprehension. It is longer than strictly necessary but not bloated.

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 description covers how to invoke the tool, parameter constraints, and side effects, but there is no output schema and the description does not describe the shape or contents of the returned preview. It also does not explain what happens if neither adgroup_id nor adset_id is supplied, even though it advertises them as required. This is a meaningful gap for correct use.

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 0%, so the description is the only source of parameter meaning. It explains every parameter: advertiser_id is a TikTok advertiser the user owns, adgroup_id and adset_id are interchangeable names for the same TikTok adgroup, and name controls persistence. The either-or relationship between adgroup_id and adset_id is explicitly stated, which the schema alone does not convey.

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: 'Preview a reusable interest pack from one live TikTok adgroup's targeting.' It also clarifies its internal behavior (calls three endpoints to resolve IDs). However, it does not explicitly distinguish itself from siblings like interests_get or interests_list, only mentions interests_save_fetched_pack as a follow-up, so it stops short of full sibling differentiation.

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 operational guidance: when `name` is omitted it returns an unsaved preview, and when supplied it fetches and saves. It also states required vs. optional parameters and provides a concrete example. It does not, however, tell the agent when to prefer this tool over sibling interest tools, so it lacks explicit exclusions.

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