resume_campaign
Prepare resuming a paused campaign. Sending does not restart until confirm_action after the user agrees in chat.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes |
Prepare resuming a paused campaign. Sending does not restart until confirm_action after the user agrees in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is known, and the description adds genuinely non-obvious behavior: the mutation is deferred until confirm_action, and nothing restarts on its own. This two-phase semantics is exactly the kind of context annotations cannot convey. It does not describe failure modes or idempotency implications, keeping it below 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 sentences, zero filler, and the most important constraint (sending does not restart until confirm_action) is stated immediately after the purpose. Nothing is repeated from the schema or annotations.
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 single-parameter mutation tool with no output schema, the description covers the critical workflow nuance an agent needs to avoid prematurely triggering a send. It omits error/precondition handling (e.g., what happens if the campaign is not paused) and the source of campaign_id, so it is strong but not fully complete.
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 0%, so the description carries the burden for campaign_id, but it says nothing about the parameter — not its format, nor where to obtain it (e.g., list_campaigns). The name is largely self-explanatory, which keeps this at a minimum-viable 3 rather than lower.
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 states a specific action (prepare resuming) on a specific resource (a paused campaign), so an agent can distinguish it from pause_campaign, launch_campaign, and preview_campaign. It stops short of naming those siblings explicitly, which would have pushed it to a 5.
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?
It gives a clear usage condition: this is a preparatory step, and the actual send only restarts after confirm_action and after the user agrees in chat. It does not state the inverse case (what to do if the campaign is not paused) or name the alternative tools, but the workflow context is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.