Skip to main content
Glama
monk24215

listmonk-mcp

by monk24215

Create campaign draft

campaign_create

Creates a draft email campaign with specified subject, sender, and lists; sending only starts when the campaign status is set to running or scheduled.

Instructions

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

Input Schema

NameRequiredDescriptionDefault
bodyNo
nameYes
tagsNo
typeNoregular
send_atNoRFC 3339 timestamp; set to schedule on start
subjectYes
list_idsYes
from_emailYesSender, e.g. 'Name <address@domain>'
template_idNo
content_typeNorichtext

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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.