Skip to main content
Glama
Sign In

Mailercloud

by com.mailercloud.mcp
OverviewDiscussionsAdmin

send_personalized_email

Destructive

Send a mail-merge email through the Email API: one call, many recipients, each with its own merge_vars object substituted into {{key}} placeholders in the subject, from name and body ({{{key}}} inserts raw HTML). Combined merge_vars must be at most 100 KB. Two steps: call first WITHOUT confirm to get a preview (recipient count, from, subject, merge keys) — nothing is sent. Show it to the user and get an explicit yes, then call again with confirm: true. dry_run: true previews without sending even when confirm is true.

Input Schema

NameRequiredDescriptionDefault
ccNoCC addresses (use the first recipient's merge_vars)
toYesRecipients, each with its own merge_vars; each gets an individual message
bccNoBCC addresses (use the first recipient's merge_vars)
fromYesVerified sender email address
htmlNoHTML body. {{var}} is HTML-escaped, {{{var}}} is inserted raw
textNoPlain text body
confirmNoMust be true to actually send. Leave false first to get a preview
dry_runNoValidate and show the send preview without sending, even when confirm is true
subjectYesSubject; {{var}} allowed
versionNo1.0 for HTML or 2.0 for AMP (default: 2.0 when amp_html is given, else 1.0)
amp_htmlNoAMP HTML body (needs version 2.0)
reply_toNoReply-to addresses (verified senders; no {{var}})
from_nameNoSender display name; {{var}} allowed
attachmentsNoAttachments (array of name and url)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / from / description
      Previous value: -"Verified sender email address,required"New value: +"Verified sender email address"
    • changedInput schema / properties / subject / description
      Previous value: -"Subject; {{var}} allowed,required"New value: +"Subject; {{var}} allowed"
    • changedInput schema / properties / to / description
      Previous value: -"Recipients, each with its own merge_vars; each gets an individual message,required"New value: +"Recipients, each with its own merge_vars; each gets an individual message"
    • changedInput schema / properties / to / items / properties / email / description
      Previous value: -"Recipient email address,required"New value: +"Recipient email address"
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already flag destructive/openWorld/non-idempotent; the description goes well beyond, disclosing the 100 KB merge_vars cap, that the first call sends nothing, that missing keys render empty, and how {{}} vs {{{}}} differ. Rich behavioral context for a destructive send.

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?

Front-loads the purpose then the two-step flow; dense but nearly every sentence adds operative detail. Minor duplication of HTML-escaping rules already in the schema keeps it just under top marks.

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 14-param destructive tool with no output schema, it supplies the workflow, limits, and preview contents an agent needs. Slight gap in not clarifying return/error behavior on failed validation.

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?

Schema coverage is 100%, so baseline is 3, but the description adds the merge_vars substitution model and the combined 100 KB limit that the schema does not state. Explains merge semantics beyond raw field definitions.

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+resource: send a mail-merge email, and immediately distinguishes it by scope ('one call, many recipients, each with its own merge_vars'). This implicitly differentiates it from send_transactional_email and send_test_email, which handle single/test sends.

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?

Prescribes the exact two-step protocol (call without confirm to preview, then with confirm: true) and explains dry_run. Clear when/how to use, but doesn't explicitly name sibling alternatives like send_transactional_email as the choice for single-recipient sends.

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

All Mailercloud toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources