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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by specifying the sort order (newest to oldest) and that each campaign includes a status field with enumerated values. However, it does not disclose pagination or filtering behavior beyond that. With annotations covering safety, the description contributes enough extra transparency to merit a 4.

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, front-loaded sentence that conveys the core purpose without extraneous words. It is appropriately sized and efficient, 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?

With three optional parameters and zero schema coverage, an agent cannot correctly invoke this tool from the description alone. It does not specify how to set limit, cursor, or status, nor does it describe the response structure (even the output schema is absent). The minimal information provided is insufficient for reliable 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% and the description does not explain any of the three parameters (limit, cursor, status). The mention of status values refers to the output field, not the status filter parameter. An agent receives no guidance on how to use limit, cursor, or valid status values, leaving parameter usage entirely 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 clearly states the action (list), the resource (campaigns of the workspace), and specific details like ordering 'newest to oldest' and included status values. This fully distinguishes it from sibling tools like list_subscribers or get_campaign_stats, which target different resources or 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 explains what the tool does but gives no explicit guidance on when to choose it over alternatives. It does not reference sibling tools or mention scenarios like 'use this when you need an overview of campaigns'. The intention is implied but not stated directly.

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