Meisa

Create Broadcast

meisa_create_broadcast

Create a new email broadcast in Meisa in draft status. A broadcast sends one email to many contacts matching an audience segment. Requires a name and a template_id (use meisa_list_templates to find one). The broadcast is created as a draft and must be sent with meisa_send_broadcast. Do NOT use for one-to-one transactional emails. Use meisa_send_email for those. Optionally enable Warm Send (warm_send_enabled) to deliver in engagement-ranked chunks spaced over up to 24 hours. Top openers receive the email first, which protects sender reputation on large or low-engagement lists. Pass a non-empty subject_override_b to enable a 50/50 subject-line A/B test on this broadcast. Each recipient deterministically receives one variant (hashed by recipient + broadcast id) and analytics include per-variant open and click rates. subject_override_b requires subject_override to also be set. To send a follow-up that lands in the same inbox thread as an earlier broadcast, pass thread_broadcast_id (the earlier, already sent broadcast) and leave subject_override empty.

Input Schema

Name	Required	Description
`name`	Yes	Internal name for this broadcast (not shown to recipients).
`sender_id`	No	UUID of the sender identity to use. If omitted, the product default sender is used.
`description`	No	Internal description/notes about this broadcast.
`template_id`	Yes	UUID of the email template to use. Use meisa_list_templates to find available templates.
`track_opens`	No	Add the open-tracking pixel. Default true. Set false to skip it (open stats are not recorded).
`track_clicks`	No	Wrap links in click-tracking redirects. Default true. Set false to send links straight to the destination (can help inbox placement; click stats are not recorded).
`segment_query`	No	Audience segment filter rules. Example: {"rules": [{"field": "status", "operator": "equals", "value": "active"}]}. If omitted, all active contacts are targeted.
`email_category`	Yes	REQUIRED. Which kind of email this broadcast is, so recipients can unsubscribe from just this kind: 'product_updates' (new features, improvements, important changes), 'promotions' (offers, discounts, sales, launches with a deal), 'newsletter' (regular articles and news), 'onboarding' (tips and onboarding). Unsubscribing from one category never stops the others. Pick 'product_updates' when unsure.
`subject_override`	No	Override the template's subject line for this broadcast.
`warm_send_enabled`	No	Enable Warm Send for this broadcast. When true, the audience is split into chunks ordered by historical open engagement (top openers first) and the chunks fire over up to 24 hours. Recommended for sends larger than ~5,000 contacts or for re-engagement campaigns to lists that have not been emailed recently. Default false.
`subject_override_b`	No	Optional second subject line. When set together with subject_override, the broadcast runs a 50/50 subject-line A/B test. Each recipient deterministically receives one of the two subjects. Requires subject_override to also be set.
`thread_broadcast_id`	No	Send this broadcast as a reply in the same inbox thread as an earlier broadcast. Pass the UUID of an earlier broadcast of this product with status 'sent' (use meisa_list_broadcasts with status 'sent' to find it). Every recipient who received the earlier broadcast gets this one as a reply to their copy; recipients who did not get a normal new email. Leave subject_override empty so the subject becomes "Re: <earlier subject>", which Gmail needs to group the two. A subject_override is kept as written, and Gmail may then show the email as a separate conversation.
`preview_text_override`	No	Override the template's preview text (the snippet most email clients show next to the subject in the inbox).
`preview_text_override_b`	No	Optional second preview text shown to recipients who receive subject variant B in an A/B test. Only used when subject_override_b is set.
`warm_send_chunk_gap_hours`	No	Hours between Warm Send chunks. Default 8. Total send window is always capped at 24 hours, so very large gaps are auto-compressed. Only used when warm_send_enabled is true.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 12, 2026

addedInput schema / properties / track_clicks

Added value: +{
+  "description": "Wrap links in click-tracking redirects. Default true. Set false to send links straight to the destination (can help inbox placement; click stats are not recorded).",
+  "type": "boolean"
+}

addedInput schema / properties / track_opens

Added value: +{
+  "description": "Add the open-tracking pixel. Default true. Set false to skip it (open stats are not recorded).",
+  "type": "boolean"
+}

Changed1 schema field changedOct 10, 2026

addedInput schema / properties / thread_broadcast_id

Added value: +{
+  "description": "Send this broadcast as a reply in the same inbox thread as an earlier broadcast. Pass the UUID of an earlier broadcast of this product with status 'sent' (use meisa_list_broadcasts with status 'sent' to find it). Every recipient who received the earlier broadcast gets this one as a reply to their copy; recipients who did not get a normal new email. Leave subject_override empty so the subject becomes \"Re: <earlier subject>\", which Gmail needs to group the two. A subject_override is kept as written, and Gmail may then show the email as a separate conversation.",
+  "format": "uuid",
+  "type": "string"
+}

First observedOct 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare the safety profile (not read-only, not destructive, non-idempotent); the description goes well beyond by stating the object is created as a draft and requires a separate send call, explaining Warm Send chunking/engagement ordering, A/B test determinism by hashed recipient+id, and the threading behavior of thread_broadcast_id. This is exactly the extra context annotations cannot carry.

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-loaded with the core action, then progressively adds advanced options. Well ordered and readable, but several sentences duplicate constraint text already present in the input schema, which adds length without new information.

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 15-parameter, non-idempotent mutation tool with no output schema, the description covers the workflow (draft creation, later send), required inputs, and advanced features (Warm Send, A/B testing, threading) adequately. It could mention failure/duplicate-creation behavior, but nothing essential for correct invocation is missing.

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 itself already documents cross-parameter constraints (subject_override_b requires subject_override; thread_broadcast_id with empty subject_override; warm_send_chunk_gap_hours only when warm_send_enabled). The description's parameter content largely restates the schema, so the high-coverage baseline of 3 applies; it adds rationale for Warm Send but little new syntax or semantics.

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 and resource ('Create a new email broadcast in Meisa in draft status') and immediately clarifies scope ('sends one email to many contacts matching an audience segment'), which cleanly separates it from meisa_send_email and meisa_create_template.

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

Usage Guidelines5/5

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

Explicitly names the negative case and the alternative ('Do NOT use for one-to-one transactional emails. Use meisa_send_email for those'), and routes the agent to meisa_list_templates for the required template_id and to meisa_send_broadcast for the follow-up send. When-to-use is fully specified.

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

All Meisa tools Inspect

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

Need Help?