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

Annotations already establish read-only, non-destructive, closed-world behavior. The description adds that the accounts originate from sync_accounts and enumerates returned fields plus cursor pagination. It does not cover auth, rate limits, default page size, or full response shape, so it stops short of 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 front-loaded with the tool and resource, then filters and pagination, and each clause carries information. The 'AdCP list_accounts:' prefix duplicates the tool name, but overall it is tight and readable. No unnecessary explanation is included.

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 and zero schema description coverage, the description should carry more of the parameter and return-shape burden. It gives a useful overview of source, key fields, filters, and cursor pagination, but omits status semantics, required nested brand details, limit bounds, and full response shape. It is adequate but not 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?

Schema description coverage is 0%, so the description must compensate, and it does identify the account filter as account_id or brand+operator while mentioning status, sandbox, and pagination.cursor. It leaves status values, brand.domain requirements, pagination.limit bounds, and the top-level versus nested sandbox relationship unexplained. This is minimum viable but incomplete.

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: listing the advertiser accounts declared through sync_accounts, and it names key returned fields. This distinguishes it from the sibling sync_accounts, which declares accounts rather than listing them. Purpose is clear without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It indicates filtering by account, status, or sandbox and mentions cursor pagination, which implies how to browse accounts. However, it gives no explicit when-to-use versus sync_accounts or other list/get siblings, and no exclusions or conditions. The guidance is implied rather than explicit.

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