Skip to main content
Glama
D4umak

HeyLead

by D4umak
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

campaign

Destructive

Control outreach lifecycle: launch, pause, resume, archive, delete, emergency stop, retry failed, or monitor. Manage LinkedIn prospecting from draft to completion.

Instructions

Control campaign lifecycle — launch, monitor, pause, resume, archive, delete, emergency stop, or retry failed.

Hosted accounts get a dashboard link and a snapshot card; relay the link,
because some clients show the image only to the model.

Args:
    action: What to do:
        "launch"         — Start outreach for a draft campaign (create_campaign
                           leaves it as a draft; nothing sends until this runs).
                           On a hosted account this also commissions the cloud
                           scheduler, so the campaign keeps sending with the
                           laptop closed
        "monitor"        — Activate a campaign for signal collection only. Sends
                           nothing; requires scheduler(action='observe')
        "pause"          — Pause an active campaign
        "resume"         — Resume a paused campaign
        "archive"        — Archive a completed campaign
        "delete"         — Permanently delete a campaign (requires confirm=True)
        "emergency_stop" — Immediately pause ALL active campaigns (kill switch)
        "retry_failed"   — Reset error outreaches to pending
        "repair_queue"   — Drop never-contacted rows below min_fit_score
        "status_history" — View campaign status change audit log (who stopped/started and when)
        "clear_coordinator_hold" — Release a campaign-wide coordinator hold
    campaign_id: Which campaign to act on. Auto-selects if empty.
    confirm: Must be True for delete action. Safety guard.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
confirmNo
campaign_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.375

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description reveals important behavioral traits: delete is permanent, emergency_stop pauses ALL active campaigns, repair_queue drops rows below min_fit_score, monitor sends nothing, and hosted accounts produce a dashboard link/snapshot that must be relayed. This is rich, non-obvious context with no contradiction to the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every line earns its place: it front-loads the tool's purpose siege, includes a scannable action list, and adds only the hosted-account note and parameter details that are needed. The structure is clear and efficient with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-action lifecycle tool with no output schema, the description is remarkably complete. It covers all actions, safety requirements, prerequisite scheduler calls, and even hosted-account behavior. An agent should be able to call this tool correctly across all listed scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage and no enums, so the description carries the full burden. It documents every action value with operational meaning, explains campaign_id auto-selects when empty, and clarifies confirm is a safety guard for delete. This fully compensates for the bare input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb phrase, 'Control campaign lifecycle', and enumerates concrete operations such as launch, monitor, pause, resume, archive, delete, emergency stop, and retry failed. It also references create_campaign's draft state and scheduler requirements, which helps distinguish this tool from related siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear sequencing context: launch is required after create_campaign, hosted accounts need the cloud scheduler, monitor requires scheduler(action='observe'), and delete requires confirm=True. It does not explicitly state when to prefer edit_campaign or other siblings, but the action-by-action guidance is strong enough for correct invocation.

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

Deploy Server

Other Tools