AdsAgent — TikTok Ads MCP

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that results are cached, pages are compact and bounded, cursors can become invalid, and that 'complete' has a specific meaning. This is substantial context for an agent to understand the tool's behavior, though it doesn't cover rate limits or auth, which are less critical for a read-only list.

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 dense but well-organized: a clear opening statement, a focused paragraph on pagination and cursor semantics, and a final note on requirements and an example. Each sentence earns its place, though it is longer than the minimal case; the complexity justifies the length.

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 output schema and no annotations, the description covers the essential aspects: purpose, caching, pagination, cursor behavior, search semantics, and the meaning of 'complete'. It omits output structure but that is not required without an output schema. Overall, an agent has enough to call it 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 0%, so the description must compensate. It explains limit (default 20, max 50), cursor (from previous response), and search (case-insensitive native id/name lookup), along with an example call. This gives agents the meaning they need without schema descriptions, effectively bridging the gap.

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 tool lists cached TikTok ad accounts (advertisers) for the authenticated tenant, using a specific verb and resource. It also mentions the joined owner_bc_name field, which is distinctive. While it references a Meta MCP counterpart, the purpose is unambiguous and distinguishable from sibling asset_list_* tools by its explicit focus on ad accounts.

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 detailed pagination instructions (follow next_cursor until complete=true, restart on rejected cursor) and clarifies that 'complete' refers to pagination, not sync coverage or permissions. However, it does not explicitly state when to choose this tool over other asset listing tools; the name and context make it obvious, but the guidance is implicit rather than explicit.

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?

No annotations are present, so the description carries the full transparency burden. It discloses that the data is cached, that linked_bcs is derived from linked_advertiser_ids, that the page is bounded, and that complete only means pagination is finished, not upstream sync or permission to create. It also states rejected/old cursor behavior, which is valuable runtime behavior.

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 organizes pagination, parameter semantics, and creation context into distinct, purposeful sentences. There is no filler; the REQUIRED and EXAMPLE lines are minimal and practical.

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 list tool with no annotations, no output schema, and four parameters, this description is unusually complete. It covers all parameters, response navigation, row-level derivation, caveats about permission, and a concrete example. The only minor omission is a full enumeration of response fields, but the pagination and linked_bcs details cover the agent's core needs.

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%, but the description compensates for all four parameters: cursor is from the previous response and must restart when stale, limit has default 20/max 50, search is case-insensitive id/name lookup, and advertiser_id comes from assets_list_ad_accounts and filters to exact cached advertiser links. This goes well beyond the bare type/default fields in the input 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?

The opening sentence states a specific action and resource: 'List cached TikTok app assets (App Promotion advertised apps) for the authenticated tenant.' The parenthetical and 'cached' scope distinguish this from the other assets_list_* sibling tools. It is not a tautology and gives an agent a clear sense of what the tool returns.

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 gives explicit pagination instructions ('Keep the same tool, filters and limit while following next_cursor serially until complete=true'), the creation-time condition for using advertiser_id from assets_list_ad_accounts, and a negative rule ('Shared BC ownership alone is not an advertiser link'). It also warns that the prepare step still verifies authorization, so an agent knows not to assume this list grants creation.

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?

With no annotations, the description carries the full burden. It discloses that the list is cached, that results are a 'compact bounded page', and explains pagination semantics including the meaning of 'complete' and cursor invalidation ('A rejected or old cursor requires restarting page one'). It also clarifies that 'complete' does not indicate upstream sync or creation permissions. These are important behavioral nuances not inferable from the schema.

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 efficiently structured: it front-loads the core purpose, then the value-add (augmentation), then the pagination contract, then parameter details, and ends with an example. Every sentence earns its place; nothing is redundant. It is detailed yet concise.

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 list tool with no output schema, the description covers all critical aspects: resource, scope, caching, pagination, cursor handling, search, limit bounds, and the meaning of 'complete'. It also references a mirror tool for cross-checking. An agent has enough to call it correctly and handle pagination without ambiguity.

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?

Despite 0% schema description coverage, the description explicitly explains all three parameters: limit (default 20, max 50), cursor (from previous response), and search (case-insensitive native id/name lookup). It adds type and constraints beyond the raw schema, fully compensating for the lack of schema descriptions.

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 Business Centers (Meta wire name: businesses) for the authenticated tenant, across every connection.' It clearly states the scope and the resource type, and distinguishes it from siblings by naming the mirror tool and the augmentation (advertiser_count, pixel_count). This is unambiguous and immediately usable.

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: this lists business centers with per-BC inventory counts so users avoid extra calls, and it explains the pagination workflow ('Keep the same tool, filters and limit while following next_cursor serially until complete=true'). However, it does not explicitly contrast with alternative list tools (e.g., when to choose this over assets_list_ad_accounts), though the resource type itself differentiates. The guidance is strong but not exhaustive.

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?

With no annotations, the description carries the full burden and does so thoroughly. It discloses that data is cached and can be stale, that the server re-verifies advertiser linkage before approval, that cursors can become rejected or old, that pagination must be followed serially until complete=true, and that 'complete' only refers to pagination, not sync coverage or permissions.

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 dense but front-loaded with the core purpose, then usage, pagination rules, prerequisites, and an example. Every clause adds practical value, including the clarification about 'complete' meaning only pagination, so no sentence is wasted.

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?

Despite having no annotations and no output schema, the description covers the tool's purpose, required inputs, parameter behavior, pagination protocol, staleness handling, prerequisite data source, and downstream usage. It is complete enough for an agent to select and call the 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 0%, so the description must compensate, and it does. It explains advertiser_id is required and sourced from a sibling tool, adds the limit maximum of 50, describes cursor continuation and restart semantics, and clarifies search as case-insensitive native id/name lookup. The example further anchors parameter usage.

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 begins with a specific verb and resource: 'List cached TikTok CTA portfolios for one exact advertiser.' It is clearly distinguishable from sibling assets_list_* tools by the CTA-portfolio resource and the cached/exact-advertiser scoping, and it explains how the output is used (as creative_portfolio_id / call_to_action_id).

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 gives clear context: when the list is empty or stale, refresh assets first; never guess a portfolio ID; advertiser_id must come from assets_list_ad_accounts; keep the same tool and filters during pagination. It does not explicitly name an alternative sibling to use instead, so it stops just short of full alternative-routing 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?

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.

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

With no annotations, the description carries the full disclosure burden. It explains what results contain and omit ('public metadata and exact music_id values only; temporary media URLs, signatures, tokens, and raw provider payloads are omitted'), how row eligibility works via 'create_eligible=true', and that the server revalidates on the create route. It also covers template and carousel behavior to prevent incorrect assumptions.

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 purpose and organized into purpose, desired row, operational warnings, required/optional arguments, and an example. Every sentence adds a distinct operational constraint or clarification, and the additional workflow notes address real failure cases rather than padding.

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 no annotations and no output schema, the description provides a complete functional contract: what results include, how to select and pass music_id, revalidation behavior, pagination rules, and integration with templates and creatives_list. An agent has enough information to call the tool correctly and chain it into the ad creation flow.

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 0%, so the description fully compensates. It defines the source and role of advertiser_id, constrains search to 1-100 characters, limit to 1..50, and describes the cursor as opaque and returned by the previous page. The example reinforces the JSON argument shape.

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 names the exact verb ('Search'), the resource ('TikTok's live advertiser-available music library'), and the specific creation use case ('for Smart+ SINGLE_IMAGE or CAROUSEL_ADS creation'). This clearly distinguishes it from sibling asset-list tools and leaves no doubt about what the tool does.

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 states a clear invocation context, provides required and optional arguments, gives the source for advertiser_id ('from assets_list_ad_accounts'), and enforces serial pagination with 'never fan out.' It also warns against guessing cross-advertiser availability, giving the agent explicit when-to-use and when-not-to-assume 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?

No annotations provided, so the description carries full burden. It thoroughly discloses behavior: pagination mechanics (cursor, limit, search, complete flag semantics), the meaning of 'complete' (pagination only, not sync coverage or permissions), handling of rejected/old cursors, the advertiser_id filtering behavior, and the prepare step verification. This goes well beyond minimal disclosure.

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 detailed but every sentence earns its place: purpose, data shape, pagination rules, creation flow, and an example. It is front-loaded with the core function, then logically proceeds through details. No redundancy 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?

Given there is no output schema, the description covers return shape (linked_bcs), pagination, error recovery, and the creation-related filtering. It also warns about misinterpretation of 'complete'. It provides everything an agent needs to call the tool correctly and interpret results, including a usage example.

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 has 0% description coverage, so the description fully compensates. It explains limit (default 20, max 50), search (case-insensitive native id/name lookup), cursor (from previous response), and advertiser_id (from assets_list_ad_accounts for exact cached advertiser link). Each parameter's purpose and constraints are defined.

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 (List), resource (cached TikTok pixels), and context (authenticated tenant, owning BC list attached). It clearly distinguishes this from sibling asset listing tools by focusing on pixels and cached data, and the mention of linked_bcs adds unique scope. No ambiguity.

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?

Provides clear context for when to use the tool: it is the pixel-specific listing tool, and it explicitly mentions the creation flow with advertiser_id from assets_list_ad_accounts, giving a conditional usage. It also gives pagination guidance (keep same tool/filter/limit). However, it does not explicitly state when NOT to use it vs other asset types, though the name and focus make that 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?

With no annotations, the description carries the full burden. It discloses that data is cached, that pages are compact and bounded, and that 'complete' refers only to pagination, not upstream sync or creation permission. It also explains cursor invalidation behavior. It does not mention auth details (implied by 'authenticated tenant') or error cases, but the disclosed behaviors are substantive and non-obvious.

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-organized: a one-sentence purpose, then pagination semantics, a caveat about 'complete', a required/optional note, and an example. Every sentence adds value; no filler. The structure front-loads the core purpose and then gives operational details, making it easy for an agent to scan.

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 list tool with no output schema and no annotations, the description covers the essential operational aspects: source of data, pagination, cursor handling, and example call. It does not specify the exact response fields or error conditions, which could be inferred from the 'compact bounded page' description, but a bit more detail on the response shape would make it fully complete. Still, it is adequate for correct 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 coverage is 0%, so the description must fully explain each parameter. It does: 'cursor from the previous response', 'limit (default 20, maximum 50)', and 'search (case-insensitive native id/name lookup)'. It also explains how cursor and limit interact with pagination, adding meaning far beyond the raw 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?

The description clearly states the tool lists cached TikTok Shops attached to the authenticated tenant's Business Centers, with a specific verb and resource. It differentiates from sibling asset-list tools by naming the exact asset type (SHOP) and even cites the underlying API endpoint. This leaves no ambiguity about what the tool does.

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?

Usage is clear for listing shops, and the description provides detailed pagination guidance (follow next_cursor serially, restart on rejected cursor). However, it does not explicitly contrast with sibling tools (e.g., 'use assets_list_tt_accounts for TikTok accounts'), though the distinct asset type makes the choice obvious. Lacks an explicit 'when not to use' statement.

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?

No annotations are provided, so the description carries the full burden. It discloses the key caveat that tt_account_id values are not identity_id values, explains that complete describes pagination not sync coverage or permission, and describes the pagination contract including cursor invalidation. Doesn't describe auth or rate limits, but these are less critical for a cached list operation.

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?

Compact and dense, with the most important information front-loaded. Every sentence carries meaning. Slight redundancy: 'REQUIRED: none' is somewhat unnecessary given the schema shows no required params, and the example is helpful but minimal.

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 list tool with no output schema and no annotations, it's reasonably complete. It tells the agent what the tool returns (cached accounts), how to paginate, how to filter, and when NOT to use it. Missing details like exact response format or auth are reasonable gaps given it's a read-only list operation.

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 0%, so the description must compensate. It does: explains limit default/maximum, cursor semantics (from previous response, rejection/old cursor requires restart), and search (case-insensitive native id/name lookup). However, it doesn't describe the response shape or what 'compact bounded page' means precisely.

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 (list cached TikTok accounts from Business Center assets) and adds a crucial scoping caveat: these are not identity_id values. It doesn't explicitly contrast with all siblings, but the content clearly distinguishes it from assets_list_identities. Loses a point for not naming more siblings explicitly.

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?

Provides explicit when-to-use guidance: for ad creation, use assets_list_identities with exact advertiser_id, and preserve identity_type and identity_authorized_bc_id. It also explains pagination behavior (follow next_cursor serially until complete=true) and error handling (rejected/old cursor requires restarting from page one). This is strong, actionable usage 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?

With no annotations, the description carries the full burden. It discloses that the data is cached, that results are bounded, and that evidence and source fields are per-connection. It explicitly warns about limitations: cache does not prove ownership or permissions, shared BC membership is not an asset link, and missing matches are not definitive. It also states no source refresh or write occurs. This is exemplary transparency.

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 every sentence is purposeful. It is front-loaded with the core purpose, then details selection rules, limitations, and alternatives. It avoids repetition and uses clear structuring, including an example. Despite its length, it is efficient and well-organized.

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 output schema, the description explains what is returned (bounded nodes and edges with evidence) and covers pagination, coverage inspection, and exclusions. It also states the exact selectors and their meaning. Given the complexity and lack of schema/annotations, this is as complete as an agent needs.

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 has zero description coverage for its 8 parameters, but the description explains each selector and the limit/cursor semantics. It states that exactly one selector must be provided, clarifies the behavior per selector type, and specifies limit range and pagination rules ('Follow next_cursor serially with identical selector and limit'). This fully compensates for the schema gap.

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 precise statement of the tool's function: 'Read the authenticated tenant's cached TikTok asset topology.' It then specifies the exact selectors (bc_id, advertiser_id, etc.) and explicitly contrasts with Meta's counterpart, clearly distinguishing it from sibling tools. The example reinforces the intended usage.

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 explicit when-to-use guidance: 'Provide exactly one native ID selector' and names which selectors are valid. It warns that 'Names are not selectors' and explains how BC/account/connection selectors differ from app/pixel/identity selectors. It also says to use TikTok selectors, not Meta identifiers, and routes creative upload to other tools. This is model 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?

With no annotations, the description carries the full burden. It discloses the async nature (submitted does not mean refreshed), the need to poll, and the return of per-task receipts and 'truthful admission failures'. It also clarifies the scope ('every active pull-enabled connection') and the necessity to verify results before proceeding.

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 longer than minimal but every sentence contributes: purpose, alias, return type, polling instructions, and verification step. It is front-loaded with the core action and uses clear formatting (REQUIRED, EXAMPLE). Slight redundancy in the alias mention but acceptable.

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 no output schema, the description must explain the return value, which it does ('per-task receipts and truthful admission failures'). It also provides the complete workflow: call, poll, verify. Nothing an agent needs to call and use the result correctly 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?

The tool has zero parameters, so the schema is trivially covered (100%). The description adds value by explicitly stating 'REQUIRED: none' and providing an example call `assets_refresh_all({})`, which is unnecessary but helpful for an agent.

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 states a specific verb ('Refresh') and resource ('TikTok asset snapshots') across all active pull-enabled connections, and explicitly names the alias sibling `tiktok_refresh_assets`. This clearly differentiates it from list tools and other operations.

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 strong context: it's an alias for `tiktok_refresh_assets`, and it instructs to poll `tasks_get_status` and check `tiktok_get_assets_status` before creation. It doesn't explicitly say when not to use it, but the alias and post-conditions make the intended use clear.

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?

With no annotations, the description carries the burden. It discloses that the token is consumed once, that the exact recorded change is dispatched, and that replaying on uncertainty is forbidden. It could go further by stating what happens on duplicate or expired refs, but the core safety-relevant behavior is covered.

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, zero filler. The main action is front-loaded, and the important retry caveat and fallback are given immediately after. 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 one-parameter mutation with no annotations and no output schema, the description covers the main purpose, the one-time behavior, and the safety fallback. It could improve by explaining that bid_prepare must have been called first to generate the approval_ref, but that is reasonably inferred from the name and sibling set.

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 0%, but the description gives the single parameter meaningful role semantics: it is a bid approval_ref that is created elsewhere and consumed by this action. The schema provides format/length constraints; the description supplies the operational meaning.

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 names a concrete action ('consume one bid approval_ref') and a concrete result ('dispatch the exact recorded TikTok ad-group change once'). It clearly distinguishes this confirm step from preparation and from querying operations_get, and the idempotent 'once' caveat adds useful precision.

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 tells the agent not to replay uncertain results and to use operations_get on the original route insteadainer. It does not explicitly mention the counterpart bid_prepare or define when the approval_ref is obtained, but the prerequisite is strongly implied by 'bid approval_ref' and the sibling list.

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?

With no annotations, the description carries the behavioral burden. It explicitly states 'This tool does not mutate TikTok', which is a key non-mutation trait, and clarifies the adset alias. However, it does not disclose other behaviors such as idempotency handling, the lifecycle of the single-use approval_ref, or what 'bounded' means in practice. These gaps matter for a tool that returns a token meant for later confirmation.

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 two sentences long, front-loaded with the core purpose and output, and contains no filler. It efficiently conveys the main point and the non-mutation caveat. It is appropriately concise for a tool with a clear single responsibility.

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?

This tool has 7 required parameters, no output schema, and no annotations, and it sits in a complex prepare/confirm pattern. The description is too sparse to guide correct invocation: it doesn't explain what 'bounded' means, how the approval_ref should be used with a confirm tool, the meaning of run_id and rule_id_and_version, or the idempotency key requirement. An agent would likely struggle to assemble a correct call without additional 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?

Schema description coverage is only 14% (only target_value has a description). The description adds meaning by stating 'advertiser-currency units' and clarifying the adset alias, but it does not explain the other six required parameters (run_id, rule_id_and_version, idempotency_key, entity_refs, ad_account_id, entity_type). Given the low schema coverage, the description fails to compensate for the undocumented parameters.

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 verb 'validate' and the resource 'TikTok ad-group bid change', and specifies the output 'single-use approval_ref'. It also notes the tool does not mutate TikTok, distinguishing it from mutating siblings. However, it doesn't explicitly name sibling tools like bid_confirm or budget_prepare, so differentiation from other prepare tools is only implied by the domain context.

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 implies a prepare/confirm workflow by mentioning it returns an approval_ref and does not mutate, but it provides no explicit guidance on when to use this tool versus alternatives. It doesn't say 'use before bid_confirm' or 'not for budget changes', leaving the agent to infer routing from naming conventions rather than clear direction.

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?

With no annotations, the description carries full behavioral burden. It discloses the one-shot consumption semantics ('never replayed'), the action taken ('dispatch'), and the recovery approach when the result is uncertain. This goes beyond a generic confirmation description, though it does not cover permissions or side effects in detail.

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 with no filler. The core action and idempotency constraint are front-loaded, and the recovery instruction 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 single-parameter confirmation tool with no output schema and no annotations, the description covers purpose, one-shot behavior, mutation, and failure recovery. It is slightly thin on expected return values and explicit prerequisite steps, but the reference to 'original authorization route' implies the flow.

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 provides only the pattern and format, with 0% description coverage, so the description must add meaning. It clarifies that approval_ref is a budget approval reference tied to an original authorization route, but it doesn't explain where the value comes from or how to obtain it beyond the pattern.

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 states a specific verb and resource: it consumes a budget approval_ref and dispatches the exact recorded TikTok change. This distinguishes it from preparation tools like budget_prepare, though the phrase 'dispatch the exact recorded TikTok change' is somewhat jargon-heavy.

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 implies this is the confirmation step after an authorization route, and it gives a specific recovery path via operations_get for transport-uncertain results. However, it does not explicitly state when to prefer this over siblings like bid_confirm, nor does it describe prerequisites such as having called budget_prepare.

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?

With no annotations provided, the description carries the full burden. It discloses that it does not mutate TikTok and that the returned approval_ref is single-use, which are key behavioral traits. It does not mention authentication, rate limits, or failure behavior (e.g., what happens on validation failure). For a validation tool, the disclosed traits are helpful but not exhaustive.

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 two sentences with zero redundancy. The main purpose is front-loaded, and the second sentence adds two crucial clarifications (non-mutation and alias) without wasted words. It is concise and well-structured.

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 7-parameter tool with no output schema and no annotations, the description is incomplete. It covers the core action and the alias, but does not explain the roles of the various ID/version parameters, the idempotency mechanism, or the expected output format beyond 'approval_ref.' An agent might correctly invoke it but lacks understanding of prerequisites or postconditions. The description is adequate but not complete for a complex tool.

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 only 14% (only target_value has a description). The description adds the critical clarification that adset is an alias for ad_group, which is essential for interpreting entity_type. However, it does not explain run_id, rule_id_and_version, idempotency_key, or the meaning of 'bounded' and 'tenant-owned' in relation to parameters. The low coverage means the description should compensate more than it does.

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 states a specific action: validate a bounded budget change and return a single-use approval_ref. It names the resource types (campaign, ad_group) and explicitly clarifies that adset is an alias, which distinguishes it from similar tools like budget_confirm. This is a clear, non-tautological purpose.

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 'does not mutate TikTok,' which implies this is a preparation step, not the final commit. However, it does not name sibling tools like budget_confirm or bid_prepare as alternatives or provide explicit when-to-use guidance. The context of the sibling list (prepare/confirm pairs) makes usage inferable but not explicit.

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?

With no annotations, the description carries full burden, and it delivers: it discloses the non-publishing prepare/confirm separation, returns needs_input with rejected_paths, 10-minute confirm-token expiry, default entity statuses of DISABLE, server-side auto-fills, music selection behavior, and retry handling for creative_image_not_ready. It also reveals mutation-affecting nuances like 'a separate durable post-create disable step must be acknowledged before ad creation' and 'unavailable music requires another explicit selection, never silent replacement.'

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 and requirements, and organized by bolded CAPS section headers. However, it is extremely long and dense, covering edge cases in a style that requires careful parsing. Most sentences earn their place given the tool's complexity, but a tighter structure would improve scannability for an agent.

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 57 parameters, no annotations, and no output schema, the description is remarkably complete. It covers modes, required inputs, recipe validation rules, budget and schedule contracts, Smart+ specifics, local image groups, Meta execution block, append behaviors, error handling, and token expiry. The example call at the end further anchors correct usage.

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 comprehensively. It explains the meaning and relationships of the central parameters (advertiser_id, template_id/name, creative, ad_params, campaign_params, adgroup_params, execution, append_mode) and Meta aliases like title/headline→display_name. It covers defaults (e.g., INSTALL_NOW, placements to PLACEMENT_TIKTOK) and conditional requirements (pixel_id for WEB_CONVERSIONS, app_id for APP_PROMOTION).

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: 'Prepare one TikTok create operation in new, append-campaign, or append-adgroup mode.' It also names the sibling companion ('does NOT publish until campaigns_quick_create_confirm is called'), making the tool's role in the two-step create flow unmistakable. The required inputs are enumerated, fully distinguishing it from related create/list 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?

Explicit guidance covers when to use template selection vs manual params, append modes, and numerous 'do not' rules: 'Do not rewrite IOS14_CAMPAIGN to REGULAR_CAMPAIGN', 'never auto-rewrite the objective', 'do not guess by name, and never supply both target IDs.' It names prerequisite calls (assets_list_ad_accounts, creatives_list, spark_ads_list_posts) and directs the agent away from Meta conventions where inappropriate.

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?

With no annotations provided, the description carries the full burden and meets it impressively. It discloses: serial execution after confirmation, one receipt journaled per created entity, stopping on uncertain outcomes, never publishing by itself, validation on one advertiser/authorization route, and the template_required/needs_input error behavior for missing selectors. This is rich behavioral context an agent needs.

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 it is dense rather than padded — every sentence carries operational meaning for a 14-parameter tool. The core purpose and safety contract are front-loaded in the first paragraph. It is appropriately sized for the tool's complexity, though a handful of sentences could arguably be tightened.

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's complexity (14 params, no annotations, no output schema, many siblings), the description is remarkably complete. It covers required fields, exclusions (Smart+), identity normalization rules, CAROUSEL_ADS objective compatibility, error behavior, the confirmation handoff, and the append-mode semantics. There is nothing an agent needs to call this tool safely that 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?

Schema description coverage is 0%, so the description must compensate. It explains the critical parameters: template_id/template_name as the required selector ('A saved template_id or exact template_name is required'), batch_items (order preservation, creative requirements), advertiser_id, append_mode (new/append-campaign/append-adgroup with exact receipts), ad_params identity overrides, and the creative fields for Spark items (identity_id, identity_type, tiktok_item_id, spark_receipt). Some params like target_campaign_id, parent_preview_receipt, and campaign_name are not individually explained, but the ones essential to correct execution are covered.

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 opening sentence is precise: 'Prepare one bounded manual TikTok hierarchy containing 2..20 ads under the same campaign and ad group, preserving batch_items order.' It names the verb (prepare), the resource (TikTok hierarchy), and the scope (2-20 ads). It clearly distinguishes itself from the single-create sibling campaigns_quick_create by explicitly contrasting the batch flow with the single-ad path.

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?

Explicit routing is provided: 'Smart+ is intentionally excluded... must be passed to campaigns_quick_create with one ad_params.creative_list instead' and 'Never fan out single-create calls.' The confirmation flow is explicit: 'show the sanitized plan and call campaigns_quick_create_confirm once only after explicit approval.' This tells the agent exactly when to use this tool vs. its siblings and what the follow-up step is.

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?

With no annotations provided, the description carries the full burden. It discloses that the create runs asynchronously, returns an opaque task_ref for tasks_get_status, explains failure behavior (bounded created objects, failure phase/reason/support_ref, next action), and details idempotency and recovery semantics. It even clarifies the legacy task path for mislabeled UUIDs, leaving no ambiguity.

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 dense and information-rich, with every sentence adding value, but it is longer than necessary. The first sentence is front-loaded and clear, and the REQUIRED/EXAMPLE lines help. Some redundancy exists (e.g., repeating recovery guidance), but the complexity of the tool justifies most length.

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 no output schema and no annotations, the description is remarkably complete. It covers purpose, parameter origin, asynchronous behavior, failure handling, idempotency, recovery alternatives, and legacy path. An agent has everything needed to call it correctly and handle uncertain outcomes.

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 0%, so the description must compensate. It explicitly states 'REQUIRED: confirm_token (from a prior campaigns_quick_create call)' and provides a concrete example. It also clarifies that task_id is a distinct legacy input, not an alias for task_ref, preventing confusion about the sole parameter.

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: 'Confirm the durable create approval minted by campaigns_quick_create.' It clearly distinguishes itself from siblings like campaigns_quick_create_deny and campaigns_quick_create_batch by focusing on the confirmation step of a two-phase creation flow, and even mentions alternatives like operations_get.

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 gives explicit when-to-use and when-not-to-use guidance: it states that the same token within expiry recovers the task and that one should not prepare a replacement, that an unavailable token does not prove no task was created (inspect receipts first), and that if uncertain, recover only with operations_get and never replay or name-match. It also names the legacy path for historical confirmations.

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?

With no annotations provided, the description carries the full burden, and it does so well. It discloses side-effect boundaries ('never cancels a submitted task'), the behavior when already claimed ('preserve the original receipt and follow its recovery action'), and a critical caveat about token expiration. These are exactly the non-obvious behavioral traits an agent needs to 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 compact and front-loaded with the core action. Every sentence adds value: the action, the claimed-draft behavior, the submitted-task warning, and the required parameter with an example.

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-argument tool with no output schema and no annotations, the description covers action, scope, edge cases, parameter requirement, and an example. Nothing essential for calling the tool correctly 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?

Schema coverage is 0%, so the description must compensate. It explicitly marks confirm_token as REQUIRED and provides a concrete example with a representative value. It implies the token identifies the draft to deny, though it could more explicitly state where the token comes from.

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 ('Deny'), a specific resource ('unclaimed campaign draft minted by campaigns_quick_create'), and a clear scope. It distinguishes itself from related siblings like campaigns_quick_create_confirm and campaigns_quick_create by emphasizing unclaimed drafts and the quick-create origin.

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?

Clearly indicates when to use the tool: to deny an unclaimed campaign draft. It also gives important contextual limitations, such as 'never cancels a submitted task' and the warning about expired/missing tokens. It does not explicitly name alternative sibling tools, but the usage context is unambiguous.

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?

There are no annotations, so the description must carry behavioral transparency, and it does: it discloses durability ('One durable task'), recovery behavior with the same unexpired token, and a caution against replaying a prior task. It does not detail side effects, permissions, or failure states, but it adds meaningful behavioral context beyond the schema.

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 three short, front-loaded sentences with no filler. The purpose is stated first, followed by recovery semantics and a safety warning; 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 single-parameter confirmation tool with no annotations and no output schema, the description covers the essential context: what is being confirmed, the durable-token recovery behavior, and an explicit 'never replay' rule. It does not explain the surrounding prepare/confirm workflow or define 'prepared task,' but the definition is largely sufficient for a simple confirm action.

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% and confirm_token is only titled 'Confirm Token.' The description references 'the same unexpired token' and recovery use, which adds meaning to the token's lifecycle. However, it never explicitly maps confirm_token to that token or explains how the token is obtained, so it only partially compensates for the missing schema documentation.

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 states a clear verb and resource: 'Confirm one prepared TikTok task recreation after explicit approval.' It identifies the triggering condition and the action, which distinguishes it from the deny/create siblings. However, it does not explicitly name sibling tools or clarify the 'task recreation' jargon, so it misses full 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?

The description gives an explicit context for when to invoke the tool: after explicit approval, on a prepared task. It also warns 'Never replay a prior task directly,' which is a meaningful usage constraint. It does not mention alternative actions such as campaigns_recreate_deny or what to do before this step, but the core when-to-use guidance is clear.

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?

With no annotations, the description carries the burden of behavioral disclosure. It adds useful nuance: claimed plans retain recovery references and submitted tasks are not canceled. However, it does not mention side effects, reversibility, or what happens to associated resources after denial.

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, with the core action front-loaded and the important caveat placed second. Every sentence earns its place and the length is appropriate for a one-parameter 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?

The tool is simple and the description covers the basic action and a key behavioral caveat. However, with no annotations, no output schema, and no parameter explanation, an agent may still be unsure how to obtain or populate confirm_token or what a successful denial returns.

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% for the only parameter, confirm_token, and the description does not mention it at all. The agent receives no guidance on where the token comes from, its format, or its role in the denial flow, so the description adds no meaning beyond the schema's title.

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 the specific verb 'Deny' and the resource 'an unclaimed TikTok recreation,' making the action unmistakable. The second sentence clarifies what this tool does not do, distinguishing it from cancellation tools like campaigns_recreate_confirm or tasks_cancel.

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 clearly scopes use to unclaimed recreations and explicitly states this is not a task-cancellation tool, which provides useful exclusion criteria. However, it does not name an alternative tool or explicitly state 'use this when you want to reject an unclaimed recreation,' leaving some inference to the agent.

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?

With no annotations, the description carries full responsibility for behavioral disclosure. It reveals server-side payload loading, removal of internal receipt/route fields, revalidation of ownership and bindings, and the non-extension of source end times. These are meaningful behavioral traits beyond what the schema shows. It does not mention return values or side effects, but covers the core action thoroughly.

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 dense but not wasteful; every sentence adds unique information. The main purpose is front-loaded, followed by behavioral details and usage guidance. It is a bit long but appropriate for the complexity of the tool. No redundant or tautological phrasing.

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 the action, conditions, and parameter usage well, but it does not mention what the tool returns or what the agent should do with the prepared recreation (e.g., follow with campaigns_recreate_confirm). Since there is no output schema and no annotations, the absence of any indication of return value or next-step linkage leaves a gap for an agent that needs to chain tools.

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. It does for execution by explaining its purpose ('explicitly rescheduled launch'), and for task_ref by calling it 'opaque' and implying it is a task identifier. It does not explicitly state that execution is optional or default null, but the schema already shows that. The description adds value beyond the schema for both parameters.

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 a specific verb ('prepare a recreation') and resource ('fully completed TikTok create/copy task'), and adds crucial constraints (caller-owned, opaque task_ref). It distinguishes the tool from siblings by specifying it is for fully completed tasks only, and later excludes failed, partial, uncertain, or foreign tasks, which clarifies its niche.

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 explicit when-to-use conditions (fully completed tasks) and when-not-to-use (failed, partial, uncertain, foreign tasks). It also gives guidance on using the execution parameter for rescheduled launches. It does not explicitly name alternative tools (e.g., campaigns_recreate_confirm), but the conditions are clear enough for an agent to select it correctly.

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?

With no annotations, the description fully carries the burden. It discloses that it only copies structure, not media ('Every source ad keeps its own TikTok provider creative; live media is often not API-reusable'), that it requires an approval step ('One approval and one serialized task journal'), and details scheduling behavior ('Optional execution.start_time/end_time replaces the source launch schedule...'). These are non-obvious behavioral traits 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 dense but every sentence earns its place: purpose, usage conditions, source constraints, media caveat, approval/journal, and scheduling. It front-loads the primary purpose and usage, then adds constraints. No wasted words.

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's complexity (structural clone, approval flow, scheduling, media limitations) and the absence of annotations and output schema, the description covers all essential aspects: when to use, how to specify sources, copy count, scheduling semantics, and behavioral caveats. Nothing critical is missing for correct 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 0%, so the description must compensate. It explains the mutual exclusivity of source_campaign_id/source_adgroup_id, the copy count range (1..5), and the meaning of execution.start_time/end_time. It does not explicitly describe advertiser_id, but that is a common context parameter. The description adds significant meaning beyond the raw 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 and resource ('Prepare a same-advertiser TikTok campaign or native ad-group structural clone from live TikTok structure') and distinguishes it from alternative flows (new launches via creatives_list + campaigns_quick_create). The scope is explicit and it is clearly differentiated from sibling tools like copy_ad_quick_copy.

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 explicit conditions for use: 'Use only when the user explicitly asks to clone an existing campaign/ad group' and explicitly names the alternative for new launches. It also specifies constraints like 'No cross-advertiser transfer' and 'Provide exactly one source_campaign_id or source_adgroup_id', leaving no ambiguity about when and how 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?

With no annotations, the description carries the behavioral disclosure burden. It discloses durability ('One durable task'), the need to poll the returned task_ref, recovery through operation_ref, and token-based recovery with the same unexpired token. It doesn't spell out full side effects, but this is meaningful transparency for a confirm action.

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: the first gives purpose, the second covers execution behavior, and the third explains recovery. 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?

Given one required parameter, no output schema, and no annotations, the description adequately covers the confirm-and-recover lifecycle via task_ref, operation_ref, and token expiry/reuse. It could explicitly identify the prior prepare step or token source, but an agent has enough information to invoke and monitor the task.

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 0%, so the description must carry parameter meaning. It adds that confirm_token must be 'the same unexpired token' and that replacement plans are never used, which clarifies reusability and expiry. It still doesn't specify where the token comes from or its format, leaving a moderate gap.

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 names a specific verb (Confirm) and resource ('one prepared TikTok structural clone') and qualifies it with 'after explicit user approval.' This clearly distinguishes the tool from its deny and prepare siblings.

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 gives a concrete condition for use: confirm only after explicit user approval, and only for a prepared clone. It does not explicitly name the deny alternative or state when not to use it, but the usage context is 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 are empty, so the description carries full burden. It discloses that the action does not cancel submitted tasks, but doesn't explain what 'deny' entails—whether it's a destructive action, if there are irreversible consequences, or what happens to the unclaimed clone. Lacks clarity on side effects beyond not canceling tasks.

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 extremely concise—one sentence. It front-loads the core action ('Deny an unclaimed TikTok structural clone') and adds one clarifying clause about claimed plans. No fluff, but it might be too sparse on detail.

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 no annotations, no output schema, and one parameter, the description is insufficient. It doesn't explain prerequisites (e.g., how to know a clone is unclaimed), what confirm_token is, or any post-conditions. The agent lacks critical context to safely invoke this tool.

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%, and only one parameter (confirm_token) exists. The description doesn't explain what confirm_token is or where to obtain it, leaving the agent to guess. The parameter name implies a token but its source or format is undocumented.

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 states a specific verb ('Deny') and resource ('unclaimed TikTok structural clone'), which clearly identifies the action. It distinguishes from confirmed clones by noting 'Claimed plans retain recovery references', but it doesn't explicitly name sibling tools like copy_ad_clone_structure_confirm or copy_ad_quick_copy_deny. The purpose is clear but not fully differentiated from siblings.

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 implies usage for unclaimed clones but doesn't provide explicit when-to-use or when-not-to-use guidance. It mentions that claimed plans are not affected, but doesn't specify conditions for unclaimed ones or when to use confirm versus deny. No mention of alternatives.

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?

With no annotations, the description fully carries behavioral disclosure. It reveals that the server reads source settings once, preserves Smart+ and Spark identity semantics, keeps new ads disabled, binds one aggregate approval, and applies specific timestamp replacement/retention rules. These are non-obvious behaviors not inferable from the schema.

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 dense but non-redundant; each clause adds a constraint or mode detail. It is a single heavy paragraph rather than structured bullets, which makes scanning harder, but there is no filler or repetition.

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 10 parameters, no output schema, and no annotations, the description is remarkably complete: mode selection, constraints, timestamp behavior, and exclusions are all covered. It could add an explicit note about the return value or downstream confirm/deny step, but that is a minor gap given the schema void.

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 0%, and the description compensates by mapping most parameters: advertiser_id, source_ad_id/source_ad_ids, copies ranges, copy_mode values, execution timestamps, and target campaign/ad group IDs. Minor gaps remain: append_mode value semantics are only implied by the 'Grouped append' paragraph, and the creative object's internal shape is unspecified beyond 'tenant-owned creative.'

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 object: 'Prepare a TikTok-native copy without publishing.' It clearly distinguishes the single-source and grouped-append modes, and differentiates this from confirm/deny and clone-structure siblings by emphasizing preparation, non-publication, and TikTok-native scope.

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 describes two invocation paths with parameter requirements, states that fresh mode requires a tenant-owned creative, and notes that grouped copy supports reuse only. It also gives explicit negative guidance: same advertiser only, never use Meta append-adset or client-side fan-out.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses one-shot semantics, token expiry, the recovery path using the exact token, post-confirm polling via tasks_get_status, and explicit constraints like never replaying or recovering by name. This is rich behavioral context beyond the bare action.

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 four sentences, all dense and purposeful, with the core purpose front-loaded in the first sentence. Every sentence contributes critical operational guidance; there is no filler or redundancy.

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 confirmation tool with no annotations or output schema, the description is remarkably complete. It covers prerequisites, what is returned, the post-action step, recovery on lost responses, and explicit anti-patterns. Nothing critical an agent needs to call this correctly 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?

The input schema only provides the name confirm_token with no description, so the description must add meaning. It does add meaning by indicating the token is exact, has an original expiry, is tied to a specific task, and can be reused only within that expiry for recovery. It does not explicitly state where the token comes from (e.g., the prepare step), but the 'prepared plan' context implies its origin.

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 states a specific verb (confirm), a specific resource (a prepared copy/bulk-append plan), and clear constraints (exactly one plan, after explicit user approval). It also distinguishes this from sibling prepare/deny tools by emphasizing it is a confirmation step and warning not to prepare a replacement copy.

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 gives explicit guidance on when to use the tool: confirm exactly once, then poll tasks_get_status. It also provides alternatives when uncertain, directing the agent to use operations_get on the original route, and explicitly forbids name-based recovery or preparing a replacement copy. This is clear, actionable routing.

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?

With no annotations, the description carries the full burden. It adds meaningful behavioral context (claimed plans return original recovery references, submitted tasks are not canceled), but doesn't explain side effects, what 'deny' actually changes, or what the response looks like.

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 short sentences with no fluff. The first sentence states the core purpose, and the second provides important caveats. Every part 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 one-parameter tool, it covers purpose and behavior boundaries, but leaves confirm_token unexplained and uses domain jargon (claimed plans, recovery references) without definition. Adequate but not fully self-contained.

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%, and the description never explains confirm_token—what it is, where it comes from, or its format. The parameter name implies a confirmation token, but no additional meaning is provided.

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 specific action (deny), the resource (an unclaimed TikTok copy plan), and distinguishes it from siblings by noting the unclaimed scope and the fact that it does not cancel submitted tasks.

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 implies when to use the tool (for unclaimed plans) and provides a boundary for claimed plans and submitted tasks. However, it doesn't explicitly name alternative tools for those cases, leaving some room for inference.

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?

With no annotations provided, the description carries the full behavioral burden and does so strongly. It discloses conditional side effects (becomes ready vs. discarded), a hard safety boundary ('never deletes a verified ready creative'), and explicit non-returned values such as hash, storage key, provider URL, and tenant identifier.

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?

Four dense sentences with no filler. The purpose is front-loaded, the parameter requirement comes second, the conditional behavior third, and the safety exclusions last. Every sentence contributes distinct 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?

For a mutating cleanup tool with no annotations and no output schema, this description covers purpose, parameter provenance, conditional outcomes, and negative guarantees. It is slightly incomplete in that it never states the success/error return shape and does not explicitly compare itself to sibling tools like creatives_confirm_upload, but these are minor gaps against an otherwise thorough definition.

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 0%, so the description must compensate, and it does: it names all four parameters and adds meaning by specifying file_hash is SHA-256, idempotency_key must be stable, and all values should match those from creatives_request_upload_v2. It does not expand on folder_id nullability or upload_attempt default, but the schema already provides those details.

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 specifies a concrete action — 'Reconcile or discard one exact tenant-owned pending/error upload' — attached to a clear motivation: a failed browser upload should not remain as a permanent library placeholder. It also distinguishes itself by explicitly stating that it never deletes a verified ready creative and references the upstream creatives_request_upload_v2 workflow.

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 gives firm when-to-use context by explaining the conditional outcome: if bytes reached storage and verify, the creative becomes ready; otherwise the placeholder is discarded. It also instructs the caller to pass the same parameters used for creatives_request_upload_v2. However, it does not explicitly route the agent away from sibling tools like creatives_confirm_upload or creatives_reconcile.

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?

With no annotations, the description carries the transparency burden. It discloses the success condition, checksum verification when available, the additive upload_contract in the response, and the no-auto-retry caveat. It does not detail failure responses or permission requirements, but the behavioral core is well covered.

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, uses a required/example section, and each sentence adds useful information. The only slight inefficiency is the somewhat open-ended double verb 'Verify or safely reconcile,' which overlaps a bit with the later success-condition sentence.

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 no output schema, the description covers trigger conditions, success criteria, response contents, a retry caveat, and an example call. It is complete enough for an agent to invoke confidently, though it does not explain error shapes or authentication requirements.

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 has one parameter, creative_id, with no description (0% schema description coverage). The description fully compensates by stating the format ('str — UUID') and the exact source ('returned by request_upload or creatives_list'), which is exactly what an agent needs to populate the parameter correctly.

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 states a specific operation ('Verify or safely reconcile a tenant-owned creative in R2') and a concrete outcome ('marks the row create-eligible only when stored size and content type match'). It is clear about what the tool does, though it does not explicitly contrast itself with the closely named sibling creatives_reconcile.

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 gives explicit trigger contexts: use after a newly prepared upload, and when creatives_list reports readiness.status=verification_pending. It also adds a clear negative guideline: never auto-retry a failed confirmation. It stops short of naming alternative tools explicitly, so it earns a 4 rather than a 5.

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?

With no annotations, the description carries the burden of behavioral disclosure, and it adds two useful behaviors: uniqueness of folder names within a parent and the surprising fact that updated_at means row-touched, not content-changed. It could also state error handling or permissions, but the mutation and returned-row behavior are at least revealed through the create verb and the note.

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?

Every sentence earns its place: purpose, uniqueness rule, surprising updated_at note, parameter summary, and example. The format is front-loaded and easy to scan.

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 two-parameter create tool with no output schema, the description covers the tenant, uniqueness, the parameter semantics, and even the unusual timestamp semantics. The only real gap is that the returned row's full shape and duplicate-name failure behavior are not specified, both of which could matter when the caller inspects the result.

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%, but the description fully compensates: it explains that name is required, that parent_id is a UUID for the parent folder, and that omitting it means top-level. The uniqueness rule and the JSON example add meaning beyond the bare property names in 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?

The description opens with a specific action and object: 'Create a creative folder for the authenticated tenant.' This directly states what the tool does and the tenant scoping, and because the sibling folder tools are delete, rename, and list operations, the create verb is enough to tell them apart.

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 invocation context: name is required, parent_id is optional, and omitting parent_id creates a top-level folder. It does not explicitly list alternative tools or when-not-to-use conditions, but the create/delete/rename/list sibling split makes the appropriate case obvious.

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?

With no annotations to indicate safety, the description carries the burden and does well by disclosing the precise effects: 'Removes the DB row and (if no other rows reference the same R2 object) deletes the R2 object too.' It also notes ownership by the authenticated tenant. It stops short of stating irreversibility or error behavior, but the core destructive behavior is transparent.

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: core action and side effects first, then the required parameter, then an example. Every line earns its place with no redundant wording.

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 one-parameter delete tool with no output schema, the description provides the essential invocation details: operation, ownership scope, side effects, parameter format, and example. It does not describe return values or error cases, but that is a minor gap given the low complexity.

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 0%, so the description must fully document the parameter. It does: 'REQUIRED: creative_id (str — UUID)' plus a concrete example. This adds meaningful type/format detail beyond the generic 'string' in 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?

The description states a specific verb and resource: 'Delete a single creative owned by the authenticated tenant by creative_id.' It clearly identifies the target and differentiates from sibling tools like creatives_delete_folder because it is explicitly deleting a creative, not a folder.

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 gives clear context for when to use the tool: deleting a single creative by its ID. It does not explicitly mention alternatives or exclusions, but the scope is unambiguous enough to guide selection among destructive creative-related siblings.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly discloses the recursive deletion, the removal of subfolders and creatives, and the nuanced R2 cleanup logic (only deleting blobs not referenced elsewhere). It also scopes the operation to the authenticated tenant. This is rich, transparent behavior description beyond any schema.

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 two sentences plus an example line, with the main purpose front-loaded. Every sentence adds value: the first explains the action and its effects, the second provides the required parameter and format, and the example reinforces usage. There is no redundancy.

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 is a destructive recursive delete with a single parameter and no output schema. The description fully covers what happens (recursive deletion, orphan cleanup), the required input, and an example. There is no missing information an agent would need to invoke it 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 0%, so the description must compensate. It does so by specifying the required parameter folder_id, its type (str), and format (UUID), and providing a concrete example call. This is sufficient for an agent to understand how to provide the parameter, though it does not elaborate on the semantics beyond the obvious (it is the folder to delete).

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 action (delete a creative folder recursively) and the scope (for the authenticated tenant). It details what is removed: subfolders, creatives, and orphaned R2 objects with a specific condition. This distinguishes it from sibling tools like creatives_delete, which presumably targets a single creative.

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 gives clear context for when to use the tool: to delete a folder and all its contents recursively. However, it does not explicitly mention alternatives or when not to use it, such as when deleting a single creative (creatives_delete). It lacks explicit exclusionary guidance but the purpose is unambiguous enough for an agent to infer the right choice.

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?

With no annotations provided, the description carries the full burden, and it does an excellent job. It discloses the return fields and their conditions (artifact_ref, download_endpoint, legacy download_url when storage-verified), explicitly states what is never returned (provider URLs and storage identifiers), and describes the 404 behavior as a shape instead of an exception.

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 logically flows through return behavior, security/redaction details, error handling, and required invocation details. Every sentence adds behavioral or usage value; the REQUIRED and EXAMPLE lines are compact and immediately actionable.

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 this is a single-parameter getter with no output schema, the description is fully complete: it explains returned fields, conditional availability, authentication properties, redaction guarantees, the not_found response shape, and the exact parameter format with an example. Nothing needed to call it correctly 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?

The schema provides only the parameter name and a bare title with 0% description coverage. The description compensates fully by stating REQUIRED, the type (str), the format (UUID), and a concrete call example using the exact parameter key, making invocation unambiguous.

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: "Get a single creative owned by the authenticated tenant by creative_id." This clearly distinguishes the tool from siblings like creatives_list (plural) and creatives_delete, and leaves no doubt about what operation is performed.

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 call the tool: when you have a specific creative_id and need a single creative. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the single-creative-by-ID framing is strong enough to guide an agent away from list-style siblings.

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?

With no annotations provided, the description carries the full burden and delivers: returned fields, row omissions, legacy download_url auth behavior, verification_pending status, and empty-page semantics. It also warns against misinterpreting folder/root counts as the whole library.

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 appropriately dense and well-structured: purpose, exclusions, caveats, compact parameter summary, return fields, and an example. Each section adds information not available in the schema, and the example makes the invocation concrete.

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 absence of an output schema and annotations, plus the high complexity around carousels, empty-reason semantics, readiness fields, and pagination, the description is remarkably complete. It equips an agent to call the tool correctly and interpret results 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 0% and the schema provides no descriptions or enums, so the description compensates fully. It documents every optional parameter with types, allowed values, ranges, defaults, and semantic caveats such as cursor scope-binding and folder_id UUID format.

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+resource: 'List creatives owned by the authenticated tenant with cursor pagination.' It explicitly distinguishes this tool from Meta adsagent.md, TikTok Ads Manager Material Center, and related creatives tools, making its role unambiguous.

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 concrete usage conditions: retry scope=library or call creatives_list_folders when no_creatives_in_root, inspect coverage/readiness before downstream use, and continue serially with next_cursor instead of fan-out. It also states what this tool is not for, clarifying selection among alternatives.

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?

With no annotations provided, the description carries the full behavioral burden and does so strongly. It warns that zero folders is not an empty library, tells the agent to inspect coverage.empty_reason before concluding emptiness, and explains that updated_at means row-last-touched rather than content-changed, including the bulk-maintenance caveat. This is genuinely useful behavioral disclosure beyond the name and schema.

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 main purpose is front-loaded in the first sentence, and each subsequent note earns its place by preventing misinterpretation or wasted operator calls. The REQUIRED/Optional/EXAMPLE block is compact and immediately actionable.

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 is remarkably complete for a simple listing tool: it covers parameter semantics, returned field creative_count, the empty-library pitfall, and updated_at interpretation. The only minor gap is that it does not describe the overall response envelope or whether pagination exists, but for this tool's complexity the description is sufficient.

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%, but the description fully compensates by explaining parent_id as 'str — UUID of parent folder' and by stating that omitting it returns top-level folders. For a single optional parameter, this is complete and unambiguous.

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 'List creative folders for the authenticated tenant', which names a specific verb, resource, and scope. It also distinguishes itself from the sibling creatives_list by clarifying that root creatives_list returns files with folder_id=null, so an agent can tell the tools apart.

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 clearly states that parent_id is optional and that omitting it means top-level folders, and gives concrete guidance about interpreting zero folders versus an empty library. It does not explicitly say 'use this instead of alternatives', but it makes the relationship to root creatives_list explicit, which gives practical routing context.

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?

With no annotations provided, the description carries full burden and delivers: idempotency, bounded concurrency, input-order preservation, and non-exposure of sensitive data. It also explains retry behavior, covering operational nuances an agent needs to invoke 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?

The description is thorough yet efficient, front-loading the core purpose and systematically covering usage, constraints, and an example. Every sentence contributes value, with clear formatting (REQUIRED, EXAMPLE) that aids parsing.

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 reconciliation tool with no output schema, the description is remarkably complete. It explains the readiness.reason_code semantics, retry rules, what results preserve, and what they never expose, giving an agent all necessary context for correct 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 coverage is 0%, so the description fully compensates by specifying the parameter type (list[str]), constraints (1..20 unique IDs), and source ('from creatives_list'). This adds meaning beyond the bare schema and gives precise, actionable guidance.

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 tool's action ('reconcile'), the resource ('creative IDs'), and its scope ('1..20 tenant-owned creative IDs in one server-side batch'). It explicitly distinguishes itself from a sibling by saying 'do not fan out creatives_confirm_upload calls', providing strong 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?

The description gives explicit when-to-use guidance via readiness.reason_code distinctions and retry conditions ('Retry only when readiness.retryable=true and follow readiness.next_action'). It also explicitly warns against using an alternative ('do not fan out creatives_confirm_upload calls'), making usage context unambiguous.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context: the uniqueness requirement and the note about `updated_at` semantics. However, it omits critical behavioral details for a mutation tool, such as required permissions, reversibility, or potential error conditions, which are not covered elsewhere.

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 well-structured: purpose, a behavioral note, required parameters, and an example. It front-loads the core purpose and includes only essential information. Every sentence earns its place, making it efficient for an agent to parse.

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 rename operation with two parameters and no output schema, the description covers purpose, constraints, parameters, and an example. It lacks mention of permissions or failure modes, but given the simplicity and no annotations, it is largely sufficient. The main gap is the absence of usage guidance relative to siblings.

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. It explicitly lists both required parameters with types and semantic hints (folder_id is a UUID, name is the new name) and provides a concrete example. This adds meaning beyond the bare schema, though it could further clarify constraints like name length or format.

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 action (rename) and the resource (creative folder), along with the ownership scope ('owned by the authenticated tenant'). The uniqueness constraint adds specific detail, distinguishing it from create/delete/list sibling operations. This is a precise, actionable purpose.

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 no guidance on when to use this tool versus alternatives. It does not mention conditions for renaming vs creating/deleting, nor does it reference any sibling tools. The example is helpful for invocation but does not address selection logic.

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?

With no annotations, the description carries the full burden. It discloses the conditional behavior based on idempotency_key, explicitly states that no presigned URLs or storage keys are returned, and notes that 'Provider presigned URLs and storage keys are never returned' as a hard constraint. It also advises to 'Trust the returned upload_attempt and reconciled fields,' hinting at the response structure. However, it does not explicitly state whether this operation creates or modifies any records, though it implies work is done in the keyed case. It is highly transparent but leaves a minor gap on side effects.

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 dense and well-organized: the first paragraph establishes purpose and conditional behavior, the second lists parameters with constraints, and the third provides an example. Every sentence adds value, and the critical upgrade_required behavior is front-loaded. There is no fluff or repetition.

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's complexity (conditional behavior, 7 parameters, no output schema, no annotations), the description covers purpose, behavior, parameter constraints, and an example. It explains the upgrade path and what is never returned, but it does not describe the full success response structure (only hints at upload_attempt and reconciled fields). Since there is no output schema, a bit more detail on the response shape would improve completeness, but the description is largely sufficient for correct 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 0%, so the description is the only source for parameter meaning. It enumerates all required parameters with constraints (content_type allowed values, file_size ≤500MB, file_hash sha256 hex) and explains optional ones (idempotency_key for retries/reconciliation, upload_attempt increment only on retry, folder_id UUID). The example further clarifies the expected payload. This fully compensates for the schema's lack of descriptions.

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 tool's role as a 'Compatibility entrypoint' for requesting creative uploads, with an explicit conditional behavior: calls without an idempotency key return upgrade_required and recommend creatives_request_upload_v2, while calls with a key use the redacted v2 proxy contract. This distinguishes it from siblings like creatives_request_upload_v2 and creatives_confirm_upload, making its purpose unambiguous.

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 explains when to use this tool versus the alternative: it tells the agent that without a stable idempotency_key, it will return upgrade_required and recommends v2, implying that v2 is the preferred modern entrypoint. It also clarifies that presigned URLs and storage keys are never returned, setting expectations for what this tool does and does not provide. This is explicit routing 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?

With no annotations, the description fully discloses critical behavioral traits: the tool is credential-free, enforces various limits (rate, concurrency, size, type, prefix), and returns either upload_endpoint or dedup_success. It also warns about what it never returns, preventing misuses. This is exceptional transparency beyond typical descriptions.

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 dense but organized: first the core function, then security/constraints, then required/optional parameters, then an example. Every sentence adds value, and the example is compact. It is front-loaded with the most critical information (what it returns and never returns).

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's complexity (7 params, no output schema), the description covers all essential aspects: idempotency, endpoint, authentication, constraints, and an example call. It even details the return behavior (upload_endpoint vs dedup_success). The example clarifies usage. It is complete for an agent to call 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 coverage is 0%, so the description must compensate. It does by listing required parameters (filename, content_type, file_size, file_hash, idempotency_key) with constraints (1..500MB, lowercase 64-hex, etc.) and optional ones (upload_attempt, folder_id). It adds value by specifying the file_hash format and size limits, which are not in the schema. Slight deduction for not explaining content_type or folder_id semantics.

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 tool's purpose: to prepare or reconcile a tenant-owned creative upload using a credential-free contract. It distinguishes itself from siblings like creatives_request_upload by version suffix and by specifying the unique behavior (returns upload_endpoint or dedup_success). The verb 'request_upload' plus the explicit conditions make it unambiguous.

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: when needing to request or reconcile an upload, with a stable idempotency_key. It also provides clear exclusions: it never returns upload_url, r2_key, or credentials, and it specifies the exact follow-up action (send bytes to the returned endpoint with Authorization header). This is more than most descriptions, making alternatives obvious.

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?

With no annotations, the description carries the full burden and discloses important behaviors: the change is executed exactly once, and uncertain writes are recorded and never auto-retried. This gives an agent a clear model of the tool's side effects, though it omits details like failure response or whether explicit user confirmation is needed.

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, with the core action front-loaded. The second sentence adds a genuinely important behavioral caveat that 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 one-parameter tool with no output schema or annotations, the description covers the essential invocation semantics and warns about retries. Minor gaps remain: the provenance of the approval_ref and the response shape are not addressed, but these are not critical for correct 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 coverage is 0%, so the description must compensate. It does by clarifying that approval_ref is the single token to be consumed, implying it comes from a prior prepare step. The schema supplies the pattern and length, while the description adds the semantic role of a one-time-use reference.

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 states a specific action—'Consume one approval_ref and execute the recorded delivery-status change once'—with a clear verb, resource, and single-use semantic. It differentiates from siblings like delivery_status_prepare and other *_confirm tools by naming the delivery-status scope.

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?

Use is implied through 'Consume one approval_ref', suggesting this is the confirmation step after a prepare operation, but the connection to delivery_status_prepare is never explicit. No when-not-to-use or alternative conditions are given, so the guidance is inferred rather than stated.

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?

With no annotations provided, the description carries full burden and delivers meaningful disclosures: never mutates TikTok, returns a single-use approval_ref, and is bounded to tenant-owned entities. These go beyond what the schema reveals. Minor gap: 'bounded' and the validation semantics are not elaborated, but the safety profile (read-only preparation) is well communicated.

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, zero filler, with purpose front-loaded and the entity_type caveat placed at the end. Each sentence earns its place; it is efficient without being under-specified on the points it does cover.

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 7-required-parameter tool with no output schema and no annotations, this is incomplete. The description explains only entity_type, does not clarify the relationship to delivery_status_confirm, and leaves the semantics of run_id, rule_id_and_version, idempotency_key, and entity_refs entirely to the agent's inference. A complex prepare tool needs more.

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 for all 7 required parameters, but it only addresses entity_type (ad_group vs adset alias). The other six — ad_account_id, entity_refs, target_status, run_id, rule_id_and_version, idempotency_key — receive no explanatory context in either the schema or description, leaving the agent to guess at their meaning and constraints.

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 (validate/prepare a delivery-status change), the resource scope (bounded tenant-owned), and the output (single-use approval_ref). It reads distinctly from delivery_status_confirm and the other prepare tools. The purpose is immediately unambiguous.

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 declares non-mutation, which signals this is a validation/preparation step rather than a committing action, and gives entity_type guidance (native ad_group vs adset alias). However, it never names the natural partner delivery_status_confirm or states 'use this before confirming,' nor does it contrast with bid_prepare/budget_prepare for other change types.

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?

With no annotations, the description carries the full burden. It discloses the output format (artifact_ref and download_endpoint), the one-hour expiry, the 5 MiB limit, and authentication requirements. It also explains export_mode behavior. It does not mention side effects beyond the export (e.g., whether it's read-only), but the confirm_export flag suggests it may trigger an operation, yet the description clarifies it returns a download link, which is transparent enough.

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 a single dense paragraph that front-loads the core purpose and mode behavior. It includes critical usage details (requirements, security) without excessive verbosity. It is well-structured, though it could be slightly more scannable with bullet points, but it earns a 4 for efficiency.

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 9 parameters, no output schema, and no annotations, the description is quite complete. It covers the required parameters, the response artifact, authentication, and attribution. It omits the date format and does not explain 'search', but these are minor gaps given the overall coverage. An agent can successfully invoke the tool based on this description alone.

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. It does explain export_mode, attribution, confirm_export, and the scope filter requirement. However, it does not describe the 'search' parameter or the 'group_by' enum values beyond what the schema already lists. Since the schema provides the enums, the description adds some context but leaves several parameters without additional meaning, resulting in a moderate score.

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 tool's function: 'Export insights as CSV' and distinguishes the two export modes with specific behavior. It is unambiguous about the resource (insights) and the action (export), and the mode descriptions (grouped vs. daily) differentiate it from other insights tools. The phrase 'Requires date_from, date_to, one scope filter...' further pinpoints its purpose.

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 lists required parameters and the condition confirm_export=true, giving clear 'when to use' instructions. It explains how to consume the download endpoint (GET with tenant Bearer credential) and forbids appending credentials to URLs. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a perfect 5.

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?

With no annotations provided, the description carries the behavioral burden. It discloses the cache-backed nature, tenant scoping, and the returned min/max stat_date. It stops short of describing empty-cache behavior or date formatting, but for a zero-parameter read accessor this is reasonably transparent.

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 short sentences with no filler. The first sentence states the output, and the second sentence gives the practical usage. Every word 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, zero-argument, low-complexity tool with no output schema, the description is complete. It names the return value, the scope, the data source, and the motivating use case, so an agent has enough context to invoke it 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?

The tool has zero parameters, so there is nothing to document. Per baseline, a parameterless tool receives a 4, and the description appropriately focuses on the returned values rather than inputs.

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 ('Returns') with a precise resource ('min/max stat_date present in cache') and a scope ('for the authenticated tenant'). It clearly communicates what the tool does and differentiates it from the sibling insights_query_* tools by framing it as a boundary discoverer for query_overview.

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 the intended use: 'Use to bound query_overview windows.' This gives clear context for when to call it, though it does not mention exclusion cases or alternative tools beyond the implicit query_overview relationship.

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?

With no annotations provided, the description carries the full burden and discloses the key traits: it is async, submits one task per active connection, and returns task_id values rather than the insights themselves. It does not mention potential side effects such as API quota/rate-limit cost or cache invalidation, which is a minor gap for an async refresh operation.

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 dense but every sentence earns its place: purpose/mechanism, the alternative path, the parameter spec, and a concrete example call. It is slightly longer than strictly necessary and could front-load the 'manual refresh compatibility path' note, but nothing is 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 one-parameter async tool with no annotations and no output schema, the description covers purpose, return semantics (task_ids, not data), the alternative path, the parameter spec, and an example. The only missing piece is how to consume the returned task_ids (e.g., via tasks_get_status), which is left implicit.

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 fully compensates by documenting the only parameter: 'days (int 1..90, default 30 — window length, NOT a date pair).' It adds the range, default, and critically disambiguates from the sibling insights_get_date_range tool. This is genuine value added beyond the bare 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?

The description states a specific verb+resource: 'Async refresh of cached insights from the TikTok Marketing API,' and clarifies the mechanism (submits pull_tiktok_insights tasks, returns legacy task_id values). It explicitly contrasts itself with insights_query_consistent, so an agent can distinguish it from the query-family siblings without opening their schemas.

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 gives explicit when-not-to-use guidance: 'Agent Method clients should follow the opaque task_ref returned by insights_query_consistent' and names the alternative tool. It labels itself as the 'manual refresh compatibility path.' It stops short of stating when a legacy/manual client would prefer this path over consistent, which keeps it from a 5.

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?

With no annotations, the description carries the full burden, and it discloses meaningful behaviors: cache-only read, server-side execution, 1–20 scope limit, and rejection of custom attribution windows. It does not describe output/pagination or error behavior, which is a minor gap for a read tool.

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 text is front-loaded with purpose, uses labeled REQUIRED/DATE PARAMS/EXAMPLE sections, and includes one useful example without redundant prose. Every sentence adds operational value.

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 10-parameter tool with no output schema and no annotations, it supplies enough to make a correct basic call, including validation constraints and date formats. It does not describe the response shape or explain optional sort/pagination/consistency parameters, so it is strong but not fully complete.

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?

With 0% schema description coverage, the description compensates for the most critical parameters: group_by, scopes, date_from/date_to, and attribution, plus a full JSON example. However, it omits the valid group_by value 'ad_group' and instructs callers to use product_id even though the schema has no product_id property, weakening its reliability.

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: 'Server-side batch overview for comparing multiple explicit scopes' and adds concrete constraints like 1–20 scopes and cache-only read from tiktok_insights_daily. This clearly distinguishes it from single-scope or row-level insights tools even though it does not name a sibling explicitly.

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 usage context: use it for multi-scope comparisons without client-side fan-out, and it provides hard rules for date fields and attribution. It does not explicitly mention alternatives or say when not to use it, so it stops short of a 5.

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?

With no annotations provided, the description carries the full burden, and it delivers substantial disclosure: batching limits, the ad_group/adset alias behavior, single-use opaque continuation semantics, the min_as_of freshness-bound constraint, the tenant-owned ad_account_id requirement, and the bounded acknowledgement deadline with dependency_unavailable backoff. This is well beyond typical disclosure for a no-annotation tool. It stops short of stating read-only safety explicitly, though 'insight read' implies it, and the return shape ('evidence envelope') is left underspecified.

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 its core purpose and every sentence adds distinct information, so it is structured rather than padded. However, it is dense with domain jargon — 'Canonical Agent Method Profile V1,' 'common-wire adapter alias,' 'opaque single-use continuation,' 'dependency_unavailable backoff' — which raises cognitive load. It could convey the same guidance in plainer language, and the jargon detracts from readability without adding precision an agent needs.

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 complex 16-parameter tool with no annotations and no output schema, the description covers pagination, batching, alias behavior, and the wait deadline well. But it leaves meaningful gaps: the consistency enum (cached/fresh_if_available/require_fresh) is never explained, the 'evidence envelope' return format is vague, and parameters like require_complete_range, after_mutation_ref, and date_range_mode get no contextual guidance. The coverage is good for the pagination core but incomplete for the full parameter surface.

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 only 6%, so the description must compensate, and it adds real meaning for several high-stakes parameters: scopes/scopes batching (up to 20, one tenant-owned ad_account_id each), min_as_of (legacy lower bound, never an anchor), wait_ms (deadline behavior), and group_by (the adset adapter-alias nuance). But with 16 parameters, many remain unelaborated — consistency enum semantics, fields, date_range_mode, require_complete_range, after_mutation_ref, response_mode — leaving the low-coverage schema only partially compensated.

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 states a clear verb-resource pair ('insight read') with concrete scope details: accepts one scope or a server-side batch of up to 20 scopes and returns 'one ordered compact evidence envelope.' This distinguishes it functionally from the continuation tool. However, it never explicitly differentiates itself from sibling readers like insights_query_rows, insights_query_overview, or insights_query_batch_overview, and the opening phrase 'Canonical Agent Method Profile V1' is opaque jargon that adds noise without clarity.

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 gives real usage guidance: start at page one, follow the server-returned continuation serially when has_more=true, and warns that min_as_of must never be used as a pagination anchor. It also specifies the wait_ms=0 fresh-request deadline with task_ref polling. But it never names alternatives or states when-not-to-use, which matters here given the sibling insights_query_consistent_continue exists for continuation — the description implies continuation but never tells the agent to route subsequent pages to that tool.

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?

With no annotations provided, the description fully carries the behavioral burden. It discloses that the continuation is opaque, tenant-bound, single-use, pinned to the original route/query/page size/snapshot, and it specifies error recovery behavior.

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 concise sentences, each carrying essential information: the action, the binding constraints, and the error-handling rule. No filler or redundancy.

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 thoroughly covers the continuation semantics, constraints, and failure handling. It does not explicitly describe the return value, but for a pagination-continuation tool the behavior is sufficiently implied by 'continue ... using the continuation returned by the prior page'.

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 provides only name, type, and validation pattern, with no descriptions. The description compensates by explaining the continuation is opaque, tenant-bound, single-use, and must come from the prior page. It provides enough meaning for correct invocation.

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 states the specific action (continue an insight read) and its resource (Agent Method insight read using the continuation from the prior page). It clearly distinguishes itself from the related starting tool insights_query_consistent by emphasizing pagination continuation.

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 explains when to use this tool: after receiving a continuation from a prior page. It also gives explicit guidance on what not to do (do not pass or synthesize min_as_of) and how to handle failures by restarting the page-1 request serially.

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?

With no annotations provided, the description carries the full burden. It discloses cache-only behavior, legacy common-wire surface mapping adset to TikTok's native ad group role, attribution limitations, daily mode behavior, and metadata semantics. It doesn't mention pagination limits or error behavior, but the disclosed traits are substantial and go well beyond a basic summary.

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 dense but well-structured: a summary sentence, a cache/legacy note, attribution and mode semantics, then REQUIRED/DATE/EXAMPLE blocks. It front-loads the core purpose and uses formatting to make requirements scannable. Slightly long, but every sentence adds value and the structured callouts justify the length.

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 16-parameter tool with no output schema and no annotations, the description covers the essential invocation contract: required fields, date parameter naming, scope filter, attribution constraints, and an example. It doesn't explain the meaning of consistency, require_complete_range, or query_contract_version, and doesn't describe the return shape, but the provided guidance is enough to invoke the tool correctly in the common case.

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. It explains the critical semantics: group_by enum values, required date_from/date_to, one scope filter (ad_account_id or product_id), attribution values, and view_mode daily behavior. It doesn't explain every parameter (e.g., consistency, require_complete_range, query_contract_version), but it covers the most decision-critical ones with enough detail to make correct calls.

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 tool aggregates insight rows for the authenticated tenant, is paginated and sortable, and is a cache-only read from tiktok_insights_daily. It also distinguishes itself from related tools like insights_pull_insights and insights_query_rows by naming them and explaining the relationship.

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 to call insights_pull_insights first if data is stale, and notes that attribution custom 1d/7d windows are unsupported. It also provides REQUIRED parameter guidance, DATE PARAMS clarification, and a concrete EXAMPLE, which gives an agent clear when-to-use and how-to-use instructions.

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?

With no annotations present, the description carries the disclosure burden and does well: it reveals the 5000-row cap, tenant scoping, and mandatory filter requirements. It does not describe output structure or pagination beyond the cap, so a small transparency gap remains.

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 purpose is front-loaded, critical requirements are clearly formatted, and the example closes the description. Every line adds functional value with 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?

Given the absence of an output schema and annotations, the description is nearly complete for calling the tool correctly: purpose, cap, tenant, required params, and an example are all present. The main missing piece is what the returned raw rows actually look like, which is a notable gap for a raw-data tool.

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 0%, and the description fully compensates: it marks the required date pair, the exact one-of scope filter condition, warns against wrong date param names, and provides a concrete invocation example. All four parameters are meaningfully explained.

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 as 'raw insight rows' capped at 5000 and explicitly contrasts it with query_overview as the main read path. An agent can distinguish this debug/drilldown tool from its siblings without opening schemas.

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 states the intended use ('debugging or detail drilldown'), points to the preferred alternative ('query_overview is the main read path'), and gives required parameter combinations. This is explicit when-to-use guidance with a clear alternative.

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?

With no annotations, the description carries full responsibility for disclosing behavior. It explicitly reveals that this is a hard delete (destructive) despite the 'archive' name, explains the naming inconsistency with Meta, and notes the consequence that the pack disappears from interests_list. This is critical, non-obvious information 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 well-structured: main purpose in the first sentence, then important context about the hard-delete behavior, followed by a required-parameter line and an example. The extra context about Meta and TikTok schema is valuable and not redundant. It is slightly verbose but 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 one-parameter tool with no output schema, the description covers the core behavioral context: what it does, side effects, and naming rationale. It does not mention error cases or idempotency, but these are not critical for a simple mutation. Overall, it is sufficiently complete for an agent to invoke it 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 coverage is 0%, so the description must compensate. It mentions the required parameter and provides an example, but adds little semantic detail beyond the schema. The parameter name is self-explanatory, and the example is a placeholder. It does not explain what the ID refers to, though that is obvious from context. This is adequate but not enriched.

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 action (archive), the resource (saved interest pack), and ownership (authenticated user). It distinguishes itself from siblings like interests_list by noting the pack disappears from that list after the call. The Meta mirror note adds context without ambiguity.

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?

Usage is implied: if you want to remove an interest pack, use this tool. However, there is no explicit 'use this when' or comparison to alternative tools like interests_delete (which doesn't exist) or interests_save_fetched_pack. It does state a side effect (no longer appears in interests_list), but does not explicitly say 'use this instead of X when Y.'

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?

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.

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly signals a read-only operation ('Get') and adds useful behavioral detail about returning both source_adgroup_id and source_adset_id keys. It doesn't mention error cases or permission specifics, but for a simple fetch this is sufficient.

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: purpose, key behavioral guarantee, then required parameter and example. Every sentence earns its place, with no filler or repetition.

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 one-parameter read tool with no output schema, the description covers purpose, parameter provenance, and the notable dual-key return behavior. It doesn't detail the full response shape or error conditions, leaving minor ambiguity but no critical gap for basic usage.

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 only says the parameter is a string and provides no description. The tool description compensates by declaring it REQUIRED, specifying it is a UUID from interests_list, and showing a concrete invocation example.

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 states a specific action ('Get one saved interest pack owned by the authenticated user') on a specific resource identified by interest_pack_id. It also distinguishes itself from siblings like interests_list and interests_fetch_from_adset by emphasizing single-item retrieval by ID.

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 context: use this when you have a specific interest_pack_id from interests_list, and it provides an explicit example call. It doesn't explicitly name when not to use it or compare alternatives, so it falls short of a 5.

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?

No annotations are provided, so the description carries the behavioral burden. It notes the wire name is shared but rows retain TikTok-native targeting semantics, adding useful context. The verb 'List' implies read-only, and it states 'for the authenticated user', indicating auth scope. However, it does not explicitly declare non-destructive behavior, nor mention pagination or return format, leaving moderate gaps.

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 concise sentences plus a required note and an example. The core purpose is front-loaded, and the extra semantics note and example are placed after. No wasted words, and the structure aids quick comprehension.

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 zero-parameter list tool, the description covers the core purpose, the user scope, and provides an example. It does not detail the return structure or pagination, but since there is no output schema and the tool is straightforward, this is acceptable. The note about TikTok-native semantics adds depth.

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 is empty (0 parameters), and schema description coverage is 100% trivially. The description explicitly states 'REQUIRED: none' and provides an example call, which clarifies that no arguments are needed. This adds value beyond the empty schema, aligning with the baseline for zero-parameter tools.

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 the exact verb 'List', the resource 'saved interest packs', and clarifies they are 'reusable audience targeting bundles'. It clearly differentiates from sibling tools like interests_get (single fetch) and interests_archive by specifying 'saved' and the listing scope.

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 makes the usage context explicit: it lists all saved interest packs for the authenticated user. While it does not name alternative tools or exclusions, the purpose is clear enough that an agent knows to use this when it wants to enumerate saved packs, not for fetching a specific one or archiving.

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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It states that the tool fetches and saves, implying a write operation, and clarifies the alias between adset_id and adgroup_id. It does not explicitly mention side effects like overwriting existing packs, return values, or error conditions, but the core behavior is well explained. Minor gaps prevent a 5.

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 dense but every sentence earns its place: it states purpose, the equivalence to a sibling, the Meta mirroring rationale, required parameters, and an example. It is front-loaded with the core purpose and uses a clear structure (description, requirements, example) without fluff.

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's complexity (combined fetch+save, alias handling, Meta mirroring), the description covers the essential usage points. It does not mention what the tool returns or error behaviors, and there is no output schema to fill that gap. However, for the primary purpose of enabling correct invocation, it is nearly complete, missing only minor return/error details.

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. It explicitly enumerates required parameters (advertiser_id, name) and explains that either adgroup_id or adset_id works, clarifying that adset_id is the TikTok adgroup identifier under a different wire name. The example further illustrates the expected format, fully covering parameter meaning 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?

The description opens with a precise verb+resource statement: 'Fetch one live TikTok adgroup's interest targeting and save it as a reusable interest pack.' It clearly differentiates from the sibling interests_fetch_from_adset by noting it is equivalent to that call with a name supplied, and it explicitly references the Meta flow. The purpose is unambiguous and distinct.

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 gives explicit guidance on when to use this tool versus the alternative: 'Equivalent to calling interests_fetch_from_adset with `name` supplied, but matches the Meta two-step flow so portable agent code stays identical.' It also lists required parameters and provides a concrete example, making usage conditions clear and actionable.

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