Skip to main content
Glama
Sign In
@kieksme/listmonk-mcp

@kieksme/listmonk-mcp

by kieksme
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create Mailing List

listmonk_create_list

Creates a new mailing list with a name, public or private type, and single or double opt-in so you can group subscribers for targeted campaigns.

Instructions

Creates a new mailing list.

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>",
      "type": "<type>",
      "optin": "<optin>"
    },
    "name": "listmonk_create_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
tagsNo
typeYes
optinYes
descriptionNo
response_formatNoOutput format: 'markdown' for human-readable text (default) or 'json' for machine-readable data.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare the key traits: readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds nothing beyond that — no disclosure of duplicate-name behavior, side effects on subscribers, or whether the created list is immediately active.

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

Conciseness3/5

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

The single sentence is tight and front-loaded, so it is not padded. However, its brevity reflects under-specification rather than disciplined economy, since an essentially equivalent statement is already in the title.

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

Completeness2/5

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

For a 6-parameter creation tool with no output schema and very low schema description coverage, the definition leaves too much unstated — what fields matter, what the opt-in choice implies, and what the response contains. It is not sufficient on its own to call the tool correctly.

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 description coverage is only 17% (only response_format is documented), so the description is expected to carry meaning for name, tags, type, optin, and description. It mentions none of them, leaving enum semantics such as single vs double opt-in unexplained.

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

Purpose3/5

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

The description gives a verb ("Creates") and a resource ("mailing list"), but it essentially restates the tool name (create_list) and title (Create Mailing List). It adds only the disambiguation that a "list" here is a mailing list, and does nothing to distinguish it from siblings like listmonk_update_list or listmonk_create_public_subscription.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus related ones, no prerequisites (e.g. required permissions), and no mention of what happens if a list with the same name already exists. The agent must infer everything from the name alone.

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