x ads list line items

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds marginal safety context. It does disclose that pagination is preserved and that monetary fields ending in _micro are millionths of the account currency, which is useful. However, the meaning of 'Native X fields' is vague, and the description does not explain behavior like default returns or relationship to drafts/deleted records beyond what the schema provides.

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 short but poorly punctuated and structurally confusing. 'Native X fields and pagination are preserved' reads as a run-on fragment after 'ads account.' A period or restructured phrasing would improve clarity. It conveys only two main ideas in roughly 30 words, so it is not verbosely long, but the awkward structure hurts readability.

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 has 11 parameters, a full output schema, and rich annotations, the description is mostly adequate because the schema covers parameter semantics. However, the vague phrase 'Native X fields' and lack of sibling differentiation create uncertainty about expected usage. Completeness is acceptable for a list operation but leaves room for clarification of field/pagination behavior.

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 100%, with every parameter already documented including descriptions for q, count, cursor, sort_by, and boolean filters. The description adds a caveat about _micro monetary fields and pagination preservation, but it does not map this to any specific parameter. Baseline 3 is appropriate since the schema already carries the heavy lifting.

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 action ('List line items (ad groups) for an ads account') with a specific verb and resource. It does not explicitly distinguish from sibling tools like x_ads_get_line_item or x_ads_list_campaigns, but the name and phrasing make the purpose evident. The awkward 'Native X fields' interrupt the sentence but do not obscure the core intent.

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?

No guidance is given on when to use this tool versus alternatives such as x_ads_get_line_item or x_ads_list_campaigns. The description does not mention exclusions, prerequisites, or selection criteria. The most one can infer is that 'list' suggests retrieval of multiple records, but that is implied by the name rather than stated.

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