listmonk-mcp

Create campaign draft

campaign_create

Creates a draft campaign with name, subject, sender, and target lists; nothing is sent until its status is moved to running or scheduled.

Instructions

Create a campaign as a draft. Nothing is sent until campaign_set_status moves it to running or scheduled.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "subject": "<subject>",
      "from_email": "<from_email>",
      "list_ids": "<list_ids>"
    },
    "name": "campaign_create"
  }
}

Input Schema

Name	Required	Description	Default
`body`	No
`name`	Yes
`tags`	No
`type`	No		regular
`send_at`	No	RFC 3339 timestamp; set to schedule on start
`subject`	Yes
`list_ids`	Yes
`from_email`	Yes	Sender, e.g. 'Name <address@domain>'
`template_id`	No
`content_type`	No		richtext

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 1, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations flag it as a non-readonly, non-idempotent, open-world write, and the description adds real context beyond that: creation only produces a draft and no email goes out until a separate status change. It doesn't mention required permissions or whether a campaign id is returned, but the draft/deferred-send semantics are a meaningful addition over 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?

Two tight sentences, front-loaded with the create-a-draft purpose followed by the sending constraint. No filler.

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

Completeness3/5

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

For a 10-parameter mutation tool with 20% schema coverage and no output schema, the description is thin. It omits parameter guidance and doesn't state what comes back (e.g., a campaign id) or permission requirements, though the draft/send-deferral framing covers the most important behavioral risk.

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

Parameters2/5

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

Schema coverage is only 20% across 10 parameters, so the description must compensate, but it names no parameters at all. The nuances of body/template_id, list_ids, content_type, and send_at scheduling are left entirely to the under-documented 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?

States a specific verb and resource (create a campaign) plus the resulting state (draft), and distinguishes itself from campaign_set_status, which handles sending. An agent can tell exactly what this does versus the status-mutating sibling.

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?

Explains the key selection condition: use this to build a draft, nothing is sent until campaign_set_status runs it. That clear routing to the send sibling is strong, though it doesn't address when to use campaign_create vs campaign_update for an existing campaign.

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