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

No annotations are provided, so the description carries the burden. It usefully discloses that the operation is read-only and lists the live progress fields returned, which is meaningful context. But it does not address permissions, data freshness, rate limits, or what 'live' means operationally.

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 definition is a single front-loaded metrics sentence followed by a terse 'Read-only.' tag. There is little waste, though the slash-separated field list is slightly compressed.

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?

For a one-parameter status tool with no output schema, the description adequately names the returned metrics and read-only nature. It is still incomplete on return structure and on how it differs from sibling analytics/monitor tools, which matters given the crowded campaign tool family.

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?

There is one parameter, and the input schema provides 100% coverage with a clear description ('Campaign id (UUID) from list_campaigns'). The tool description adds no additional parameter meaning, so the schema does the work. Baseline 3 is appropriate.

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 names the resource (email channel progress) and enumerates the specific metrics returned: audience size, processed, percent complete, event counts, queue depth, provider status. It is clearly a read-only campaign status tool. However, it does not distinguish itself from close siblings like get_campaign_email_stats, get_campaign_monitor, or get_campaign_pulse.

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 gives no explicit when-to-use guidance and never identifies when another campaign email/status tool should be selected instead. 'Read-only' is a safety trait, not usage guidance. With many similar siblings, an agent has no routing rule.

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