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, and it delivers. It discloses that this is 'a live read, not a mutation receipt,' explains what 'configured' includes (actual parent IDs, app_id, optimization_event, schedule times), defines the semantics of 'complete,' bounds hints to '20 unique campaigns per advertiser,' and clarifies the adset/ad_group alias. The null-value warning and omitted_fields caveat further disclose partial-coverage 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 long, but every sentence carries operational value — no filler. It is front-loaded with the core purpose and progressively layers caveats (field coverage, error handling, hints, alias, mutation recovery). Given zero annotations and zero output schema, the density is justified rather than bloated; it is only slightly longer than the minimum needed for a tool of this complexity.

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 multi-entity read with no annotations and no output schema, the description is remarkably complete. It covers return semantics (configured vs effective status, field coverage), error handling (response_budget_exceeded with next_action), data-quality caveats (null values, omitted_fields, 'complete means entity coverage, not field equality'), limits (50 entities, 20 hints), alias clarification, and the distinction from mutation receipts. An agent has everything needed to call this 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 fully compensate for the single entities parameter, and it does. It explains the entity types (campaign/ad_group/adset/ad), the alias ('adset is only the common-wire alias for ad_group'), the 50-item ceiling, and the purpose of the optional campaign_id ('An ad may include its exact parent campaign_id to retrieve Smart+ fields when generic ad readback omits the ad'). The description adds substantial 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?

The opening sentence is a precise verb+resource+scope statement: 'Read allowlisted current TikTok configuration for up to 50 tenant-owned campaigns, native ad groups, or ads in one server-side request.' It identifies the resource (TikTok config), the operation (read), and the cardinality (up to 50) unambiguously. It also clearly enumerates the covered entity types, distinguishing it from any mutation or list tool in the sibling set.

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 operational guidance: 'Check null values and readback_omitted_fields/creative.omitted_fields before comparing with an approved draft,' and 'complete means entity coverage, not field equality.' It prescribes recovery behavior for errors ('follow its exact-ID next_action with a smaller read; do not retry the same oversized batch or fan out') and explicitly names the alternative for uncertain writes: 'must still recover with operations_get on the exact original route.' This is textbook when-to-use and when-not-to guidance.

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