campaign_set_statusSet an email campaign's status to send immediately, schedule delivery, pause, resume, or cancel it; verify recipients and body before changing status.
Start, schedule, pause, resume, or cancel a campaign. 'running' SENDS EMAIL to all recipients immediately. 'scheduled' sends at send_at. Confirm the recipient lists and body before using.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| status | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the description's real contribution is the irreversible side effect: 'running' SENDS EMAIL immediately. That is high-value context beyond the annotations. It falls short of explaining whether 'cancelled' aborts an in-flight send or whether paused can be resumed mid-send, which matters for a destructive 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 short sentences, front-loaded with the action list and immediately followed by the highest-risk behavior. Minor friction: 'resume' is listed as an action but is not an enum value, forcing the agent to infer it maps to 'running'.
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 destructive, non-idempotent, open-world mutation with no output schema, the critical warning about immediate sending is present, but gaps remain around cancellation semantics, irreversibility, and how the 'id' is resolved.
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 0%, so the description must carry parameter meaning, and it only explains two of the four enum values (running, scheduled). 'paused' and 'cancelled' are left undefined, and the 'id' parameter is never described as the campaign identifier.
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?
Names the exact lifecycle actions (start, schedule, pause, resume, cancel) applied to a campaign, which distinguishes it cleanly from campaign_update (field editing) and campaign_test_send (test delivery). An agent can identify the tool's job without opening the schema.
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 clear operational precondition ('Confirm the recipient lists and body before using') and explains what two of the status values do. It does not explicitly state when to choose this over campaign_update or campaign_test_send, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.