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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds substantial context beyond that — creation is draft-only and non-dispatching, and the campaign will silently become unsendable ('send ends FAILED') unless the HTML body contains specific CAN-SPAM placeholders and an unsubscribe link. That is a real behavioral constraint an agent could not infer from structured fields.

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?

Front-loaded with the write/draft distinction, then prerequisites, then the validation gate, then next steps — a sensible priority order. It is a dense run-on sentence and the placeholder list is bulky, but every clause carries information.

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?

Covers purpose, dependencies, failure mode, and follow-up for an 8-parameter mutation tool with no output schema. Minor gap: it doesn't say whether text_body is optional or that the response returns a campaign id needed to schedule later, though the schema fills in the optionality.

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%, so the baseline is 3; the description earns an extra point by enumerating the exact required placeholder tokens ([[account:business]], [[account:address_1]], etc.) that the schema only alludes to vaguely as 'the CAN-SPAM placeholders,' and by tying sender_id to a verification source.

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?

Opens with an explicit verb and resource plus a scope qualifier — 'WRITE: create a new campaign as a DRAFT (nothing is sent)' — which immediately separates it from emailchef_send_campaign and emailchef_schedule_campaign in the sibling list.

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?

States prerequisites (verified sender via emailchef_list_senders, at least one list) and explicitly routes follow-up work: 'Schedule or send it afterwards,' naming the two downstream siblings by function. An agent knows both when to call this and what to call next.

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