Skip to main content
Glama
tecspda

listmonk-mcp-ts

by tecspda
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

send_transactional_email

Destructive

Send an immediate transactional email to an existing Listmonk subscriber using a 'tx' template and supplied data; delivery cannot be recalled.

Instructions

Send one transactional email right away, using a 'tx' template, to a subscriber that already exists in Listmonk. The email cannot be recalled. data fills the template variables. Create tx templates with create_template (type 'tx').

Input Schema

NameRequiredDescriptionDefault
dataNoKey/value data for the template, available there as {{ .Tx.Data.<key> }}
template_idYesID of a template of type 'tx' (see get_templates)
content_typeNoBody format: html, markdown or plainhtml
subscriber_emailYesEmail of an existing subscriber to send to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.1
    • changedInput schema / properties / content_type / description
      Previous value: -"Content type"New value: +"Body format: html, markdown or plain"
    • changedInput schema / properties / data / description
      Previous value: -"Template data"New value: +"Key/value data for the template, available there as {{ .Tx.Data.<key> }}"
    • changedInput schema / properties / subscriber_email / description
      Previous value: -"Recipient email"New value: +"Email of an existing subscriber to send to"
    • changedInput schema / properties / template_id / description
      Previous value: -"Template ID"New value: +"ID of a template of type 'tx' (see get_templates)"
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false. The description adds useful context beyond that: the email is sent immediately and 'cannot be recalled', which clarifies the irreversibility of the side effect. It does not discuss permissions or rate limits, but annotations carry the primary safety signal.

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 three compact sentences, front-loaded with the action and critical constraints. Every sentence contributes useful information, including the template creation pointer, with no filler.

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?

For a destructive send tool with full schema coverage and annotations, the description covers timing, irreversibility, prerequisites, and where to create tx templates. Response and error behavior are not described, but that is minor because no output schema exists.

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?

Schema description coverage is 100%, and the schema already documents all four parameters, including the nested data object and its template-variable usage. The description only restates that 'data' fills the template variables, adding little semantic detail beyond what the schema provides.

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 states a specific verb and resource: send one transactional email right away. It adds distinguishing constraints ('one', 'right away', 'tx template', 'subscriber that already exists') and explicitly points to create_template for template creation, so an agent can distinguish this from sibling operations.

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 gives clear prerequisites: the subscriber must already exist and the template must be of type 'tx'. It also directs users to create_template for creating tx templates. However, it does not explicitly mention send_campaign or schedule_campaign as alternatives for bulk/campaign email, so the exclusion is only implicit.

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