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

No annotations are provided, so the description carries the full disclosure burden; it does step up by stating 'Read-only', which is the most important behavioral fact for a listing tool. It still omits pagination semantics, the 200-row cap, default page size, and whether the prepared state is expensive or asynchronous — gaps that matter for an unannotated tool.

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?

Three parallel state clauses plus a trailing 'Read-only' safety note — front-loaded, no filler, and scannable. Minor inefficiency: semicolons chain three separate definitions into a single dense sentence, which slightly reduces readability over a bulleted structure.

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 6-parameter listing tool with no output schema and no annotations, the description covers the core decision (which state, which filters) plus read-only safety, which is enough to call it correctly. It could be stronger by noting that prepared returns aggregate counts/progress rather than email rows, but overall nothing blocking is missing.

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 83% and already documents id, limit, offset, and status well. The description adds meaning the schema does not: which optional params are meaningful per state (status filtering and address search apply to sent/queued, status maps to pipeline values for prepared). That state-to-parameter mapping is genuine added value beyond the schema.

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?

States a specific verb + resource (list campaign emails) and disambiguates the three modes via state=sent/queued/prepared with a one-line gloss each. It does not explicitly distinguish itself from near-neighbour siblings like get_campaign_email, list_campaign_email_leads, or preview_campaign_email, which leaves some ambiguity in a crowded email-related tool family.

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?

By defining what each state returns, the description implicitly tells the agent which state to pick for a given question. However, it never says when to prefer a sibling (e.g. get_campaign_email for a single email, list_campaign_email_leads for lead-level data), so the agent must infer routing from tool names alone.

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