List X Pixels (web event tags)

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds value by explaining the semantics of returned fields (id vs website_tag_id, and the embedding of embed_code), which helps the agent interpret results. However, it does not describe pagination behavior or the overall response shape, relying on the annotations for safety context.

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 at three sentences with no filler. The primary purpose is front-loaded in the first sentence, and the subsequent sentences efficiently clarify field semantics and the embed-code format, which are non-obvious and useful.

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 low parameter coverage, the description carries a heavier burden than it fully meets. It usefully disambiguates return-field IDs and embed code, but omits pagination behavior, response size expectations, and any usage context needed to call the tool correctly for filtering results.

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 33%, with only account_id documented. The description explains output field meanings (id, website_tag_id, embed_code) but these are return values, not input parameters. The count and cursor parameters are left unexplained by both schema and description, and the description does not compensate for the low schema coverage 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 states a specific verb ('List') and resource ('Universal Website Tags / conversion pixels'), making the tool's purpose clear. It is distinguishable from siblings like x_ads_get_pixel (singular retrieval) and x_ads_create_pixel (creation) by its list-scope phrasing, though it does not explicitly name those 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?

No guidance is given on when to use this tool versus alternatives. There is no mention of x_ads_get_pixel for fetching a single pixel, no pagination guidance despite a cursor parameter, and no stated conditions for choosing this over the sibling pixel tools. The usage context must be inferred entirely from the name.

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