Skip to main content
Glama
mailkite

MailKite

Official

mailkite_send

Send email messages from verified domains, using templates, attachments, scheduled sends, and open/click tracking.

Instructions

Send a message over a verified domain. Pass templateId (+ optional templateData) to send from a saved or base template. Requires an API key (mk_live_…).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNo
toYesOne recipient or a list.
bccNo
fromYesAn address on a verified domain.
htmlNo
textNo
headersNoExtra raw MIME headers, applied after threading headers (caller wins). Use for what the structured fields can't express — e.g. `List-Unsubscribe`, a dedup/idempotency key (`X-Entity-Ref-ID`), or a tag header (`X-Tag`). Carried on both immediate and scheduled sends.
replyToNo
subjectNoRequired unless supplied by a template.
metadataNoStructured metadata kept SERVER-SIDE for this send: stored on the message and echoed back on reads, but never emitted as a MIME header, so order ids, tenant keys, and internal correlation stay off the wire (that is the difference from `headers`). Scalar values only; at most 20 keys, keys ≤ 64 characters, string values ≤ 512.
sequenceNoEnroll this recipient in a sequence when the send succeeds — the name or id of an ACTIVE sequence. Naming a sequence IS the consent: no trigger is involved, and an unnamed send enrols in nothing. The sequence's input is auto-injected from `templateData` and `metadata` (add `sequenceInput` for explicit params), and the message itself is readable in steps as {{trigger.from}}, {{trigger.subject}}, {{trigger.messageId}}. A name that does not exist, or a sequence that is not active, is answered on this call rather than silently ignored.
inReplyToNo
templateIdNoSend using a saved template — a user template (tpl_…) or a base template (base_…). Its subject/html/text seed the message; explicit subject/html/text here override them.
trackOpensNoOpen-tracking override for this send (HTML only). Omitted → the from-domain's default applies.
attachmentsNo
scheduledAtNoSend later: ISO 8601, simple relative natural language ("in 2 hours"), or a ms-epoch. A future time parks the message with the scheduler — the response carries an ssnd_… id and status "scheduled", cancelable via DELETE /v1/scheduled/{id}. Omitted or past sends now.
trackClicksNoClick-tracking override for this send (HTML only): http(s) links are rewritten to a signed redirect that records the click, then 302s to the destination. Omitted → the from-domain's default applies.
templateDataNoValues substituted into the template's {{merge_tags}} (e.g. {"name":"Ann"} fills {{name}}). HTML values are auto-escaped.
sequenceInputNoExplicit input for the sequence named in `sequence`, checked against its declared signature. Merged OVER the values auto-injected from `templateData` and `metadata`, so an explicit value always wins over one inferred from the message.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.20.0

TDQS

A4/5.0
Behavior4/5

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

Adds meaningful behavior beyond annotations: headers 'carried on both immediate and scheduled sends', metadata is structured and survives, template data is auto-escaped, sequence names trigger consent-based membership, and subject can be supplied by template. The readOnlyHint=false annotation is consistent with a send operation; no contradictions.

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

Conciseness4/5

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

The description is compact and front-loaded with the core action, then covers key behaviors in a logical order. It's about three sentences but packed with necessary detail; no filler. Slightly long due to headers examples, but that's justified by complexity.

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?

Given the tool's complexity (11+ parameters) and no output schema, the description covers the critical decisions: template vs explicit content, headers use cases, scheduling, tracking overrides, and metadata purpose. It omits obvious param names (left to the schema) and doesn't attempt to describe return values, which aligns with the rule.

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

Parameters4/5

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

While the schema already describes several fields, the description adds semantic depth: precedence rules for subject (template vs explicit), header override behavior, the role of templateData, and what metadata is used for (tenant, correlation). This goes beyond basic types and helps an agent pick the right parameter.

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

Purpose4/5

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

The description clearly states the action ('Send a message over a verified domain') and distinguishes from sibling tools like mailkite_send_broadcast by focusing on direct sends with templates, headers, and scheduling. It doesn't explicitly say 'email' or contrast with alternatives, but the combination of verified domain, from/to, subject, and template makes the purpose unambiguous.

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?

Provides concrete situational guidance: when to pass templateId vs explicit content, using headers for what structured fields can't express, and the behavior of trackOpens overrides. It doesn't mention when to prefer send_broadcast or send_event, but the description effectively explains the main parameters and their precedence rules (e.g., template subject fallback, header override behavior).

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

Install Server

Other Tools