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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower; the description still contributes the non-obvious default-filter behavior that would otherwise cause an agent to wrongly conclude no drafts exist. It adds nothing about auth, rate limits, or pagination behavior, keeping it short of a 5.

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 tight sentences plus the endpoint; the returned-fields summary is front-loaded and the surprising default-filter caveat follows immediately. No filler, every sentence 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?

With no output schema, the description usefully enumerates the returned metrics and flags the default-state pitfall, which is enough to call the tool correctly. Pagination and sorting are fully handled by the schema, so only minor gaps (result envelope shape, ordering of the default set) remain.

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 100% and all six parameters (limit, offset, order, order_by, search, status) are documented in-schema, including the default status set and the 'pass the previous reply's next_offset' pagination hint. The description's status guidance largely restates what the schema already declares, so it adds only marginal semantic value beyond structured data.

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 and resource ('List email campaigns') plus the exact fields returned (state, recipients, delivered, unique opens, unique clicks), and names the underlying endpoint GET /campaigns. It is distinguishable from emailchef_get_campaign by the plural/list framing, but never explicitly names or excludes near-siblings like emailchef_list_campaign_engagement, which also reports engagement data.

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?

Gives a genuinely actionable usage rule: without a status filter only SENT and ARCHIVED campaigns come back, so the agent must pass a status to reach DRAFT/SCHEDULED/SENDING/FAILED. That is clear conditional guidance, but it does not address when to prefer this over list_campaign_engagement or get_campaign for a single campaign.

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