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

@kieksme/listmonk-mcp

by kieksme
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send Transactional Message

listmonk_send_transactional_message

Sends a one-off transactional email to an existing subscriber by rendering a 'tx' template with provided data. Specify the recipient by email or subscriber ID.

Instructions

Sends a one-off transactional e-mail to a subscriber by rendering a 'tx'-type template with the given data. Requires either subscriber_email or subscriber_id. The subscriber must already exist.

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": {
      "template_id": "<template_id>"
    },
    "name": "listmonk_send_transactional_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataNoTemplate variables available to the template as {{ .Tx.Data }}.
headersNo
messengerNoemail
from_emailNo
template_idYesId of the transactional ('tx') template to render.
content_typeNo
subscriber_idNoRecipient by subscriber id (use this or subscriber_email).
subscriber_emailNoRecipient by email (use this or subscriber_id).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations indicating a non-idempotent, open-world write, it explains the one-off send behavior, template rendering with data, and the existing-subscriber precondition. It does not describe delivery failures, error handling, or the response, but it adds meaningful operational context.

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?

Three short sentences front-load the operation and then state the recipient and subscriber prerequisites. Every sentence contributes useful selection or invocation information without unnecessary wording.

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

Completeness4/5

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

The definition supplies the essential behavior and non-obvious preconditions needed for a basic correct invocation. Given eight parameters, nested inputs, and no output schema, it could still be more complete about optional delivery overrides, content formatting, and response or error behavior.

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

Parameters3/5

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

The description reinforces the roles of data, template_id, and the two recipient identifiers, while adding the important cross-parameter requirement that one recipient identifier is mandatory. However, much of this repeats schema descriptions, and it adds no guidance for headers, messenger, from_email, or content_type despite only 50% schema coverage.

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 clearly states the action, resource, and scope: sending a one-off transactional email to one subscriber by rendering a 'tx'-type template. This distinguishes it from campaign sending, campaign tests, and subscriber opt-in messages.

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?

It provides concrete invocation prerequisites: supply either subscriber_email or subscriber_id, and ensure the subscriber already exists. It does not explicitly route agents to create_subscriber for new recipients or name alternatives for other messaging scenarios.

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