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

With no annotations provided, the description carries the full burden, and it delivers rich behavioral detail: eligibility rules by identity_type, Spark-only AUTH_CODE paths, Smart+ restrictions, identity_authorized_bc_id handling for duplicate identities, pagination semantics with next_cursor and complete, and advertiser-link verification. It goes well beyond a simple read/list description and exposes important edge cases an agent must know.

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 long, but the tool is complex and the content is dense with edge cases. Purpose is front-loaded, and the pagination and parameter guidance are structured logically. Some phrases like "Meta pages analog" add little and could confuse, but overall the length is justified by the behavioral complexity covered.

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 tool with no annotations and no output schema, the description is remarkably complete. It covers return contents, pagination protocol, cursor invalidation, filtering semantics, identity eligibility, creation prerequisites, and verification expectations. An agent has enough context to invoke this tool correctly and interpret its results in the surrounding workflow.

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 must compensate, and it does. It explains limit defaults and maximum (20/50), cursor comes from a previous response, search is case-insensitive native id/name lookup, and advertiser_id filters to assets with an exact cached advertiser link. Each parameter gains meaning beyond the raw schema definitions.

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: "List cached TikTok posting identities for the authenticated tenant." It clearly distinguishes this from the broader asset-listing sibling tools by focusing on TikTok posting identities and explaining its role in assets discovery before campaigns_quick_create. The scope is precise and immediately actionable.

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 call it: "call this from assets discovery before campaigns_quick_create when ad_params lacks identity_id / identity_type." It also explains how advertiser_id relates to assets_list_ad_accounts and gives filtering guidance. It does not enumerate sibling alternatives to rule out, but the triggering condition and surrounding workflow are clear enough for an agent to select it appropriately.

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