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

Annotations already mark the tool readOnly, idempotent, and non-destructive, so the bar for added context is lower. The description adds behavioral detail beyond the schema: results come 'newest first' and cover all statuses including unlaunched drafts and scheduled campaigns. This gives an agent useful expectations about ordering and coverage without contradicting annotations.

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?

Two sentences with no filler. The core behavior is front-loaded in the first sentence, and the second sentence provides the differentiating edge case. Every clause earns its place.

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?

The tool is simple with two optional parameters and no output schema. The description covers the result contents, ordering, and inclusion semantics, which is sufficient for an agent to know what to expect. No critical gaps like pagination or error behavior are needed given the read-only nature and schema docs.

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 coverage is 100%, with both 'limit' and 'status' fully described in the input schema including defaults and ranges. The description does not add any additional parameter-level guidance, so the baseline of 3 applies.

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 uses a specific verb and resource: 'List' 'campaigns'. It states scope ('Every simulation campaign in the workspace'), ordering ('newest first'), and the included fields ('status' and 'funnel'). The contrast with reporting tools distinguishes it from 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?

The description explicitly positions the tool against 'reporting tools' and gives the deciding criterion: this tool includes drafts and scheduled campaigns that have never been launched. That is a clear when-to-use signal. However, it does not name specific sibling tools or mention cases where a more targeted tool like get_campaign would be preferred.

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