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

The annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) are consistent with the description, and the description goes well beyond them by disclosing the critical non-effect: workflows and automations stay paused and disabled. It also explains the intentional design rationale (avoiding silently messaging real people) and the search-watches side effect — exactly the behavioral context annotations cannot convey.

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 compact, logically ordered, and every sentence earns its place: action, side effect, critical warning, rationale, lookup guidance, error fallback. The safety-critical constraint is front-loaded with 'IMPORTANT:' and the included rationale makes the constraint memorable without adding fluff.

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 write operation with real-world outbound-messaging implications, the description covers the action, the intentional non-effects, the safety rationale, input sourcing, and error handling. Nothing an agent needs to invoke it correctly or to decide whether it is the right tool is missing, even without an output schema.

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% for the single campaignId parameter, but the description compensates by telling the agent exactly how to obtain a valid value (campaignstack_list_campaigns with includeArchived) and how to handle a not-found case. For one obvious parameter this is strong compensation, though it stops short of explicitly defining the value domain (e.g., that it must be an archived campaign's ID).

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 verb and resource ('Unarchive a campaign') plus the observable outcome ('bringing it back into active views'), making the purpose unmistakable. It is clearly distinguished from siblings like campaignstack_archive_campaign, campaignstack_delete_campaign, and campaignstack_update_campaign by its unique action and the added side-effect note about re-evaluating search watches.

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 explicitly names the sibling tool campaignstack_list_campaigns with the includeArchived flag for finding archived campaigns, and provides a fallback instruction for not-found errors. It also establishes an important exclusion — this tool does NOT restart workflows/automations — signaling the agent that separate re-enable tools are needed, which is precise when-to-use vs alternative guidance.

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