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

The annotations already establish that this is a non-read-only, non-destructive, non-open-world operation. The description adds useful behavioral context beyond annotations: the campaign starts with one empty email by default or with a template sequence when templateId is provided, and it remains a draft until launched. It does not cover permissions or return details, but the annotations lower the burden.

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 description is three short sentences with no wasted language. The key information is front-loaded: create a draft campaign, then the two possible starting states, then the draft lifecycle.

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 simple two-parameter create tool with annotations and no output schema, the description covers the important lifecycle and initial-content behavior. The main remaining omission is that it does not describe what the tool returns, such as the created campaign identifier, but the core calling semantics are adequately covered.

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 50%, with templateId documented in the schema and name lacking a description. The description adds meaning to templateId by explaining that a saved or built-in template's sequence can seed the campaign, and it clarifies the default empty-email state when templateId is omitted. It does not explain the name parameter beyond what the schema's default and length constraints already provide.

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: "Create a draft campaign." It also clarifies the resulting state and distinguishes the draft creation step from later launching: "The campaign is a draft until it is launched." This is enough for an agent to separate create_campaign from launch_campaign and update_campaign.

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 implies when to use the tool by stating it creates a draft and that the campaign remains a draft until launched. However, it does not explicitly name alternatives such as launch_campaign, preview_campaign, or update_campaign, nor does it state when not to use this tool.

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