Mailzzy

Mailzzy MCP automations create

mcp_crm_automations_create

Create a new automation DEFINITION for the authenticated user. The new automation is always created INACTIVE (a definition only) — it does NOT run, send, or activate. Use when the user wants to define a new automation by name. Do NOT use to activate, run, or wire the automation's step graph — activation is a separate, later capability and is not available here. Do NOT use to edit an existing automation — use mcp_crm_automations_update. The automation's status cannot be set via this tool. Tenant is bound to the session and cannot be changed via arguments. Automation-level RULES (all optional, and all independent of the step graph — use mcp_crm_automations_set_steps for that): entryConditions / exitConditions / restartConditions are arrays of {type, segmentId, operator, contactFilters, campaignIds, linkUrl} where type is one of added_to_lists, removed_from_lists, contact_in_segment, contact_matches_filters, email_opened, email_clicked, email_unsubscribed; a membership type needs segmentId, contact_matches_filters needs contactFilters, and the email types take optional campaignIds (plus linkUrl on email_clicked). operator is MATCHES or DOES_NOT_MATCH. Pass an EMPTY array to clear a slot; omit the key to leave it unchanged. reentryPolicy is once (a contact runs this automation at most once) or every_time, with reentryWaitMinutes as the cool-down before a contact may re-enter. onDeactivate is continue (in-flight contacts finish) or cancel (in-flight contacts are cancelled when a human deactivates the automation). Returns the created automation projection (id, name, status, rules, version).

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

Input Schema

Name	Required	Description
`name`	Yes	Name of the new automation (1-100 characters)
`onDeactivate`	No	What happens to in-flight contacts when a human deactivates this automation
`reentryPolicy`	No	Whether a contact may run this automation more than once
`exitConditions`	No	Conditions that make a contact EXIT this automation early. Empty array clears the slot; omit to leave unchanged.
`idempotencyKey`	No	Optional client key so a retried create returns the original result instead of inserting a duplicate
`entryConditions`	No	Conditions a contact must match to ENTER this automation. Empty array clears the slot; omit to leave unchanged.
`restartConditions`	No	Conditions that RESTART a contact in this automation. Empty array clears the slot; omit to leave unchanged.
`reentryWaitMinutes`	No	Cool-down in minutes before a contact may re-enter (every_time only)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare only the generic write profile (readOnly=false, destructive=false, openWorld=false); the description adds the critical behavioral fact that the created automation is always INACTIVE and does not send or run, that tenant is session-bound and immutable via arguments, and that status cannot be set here. It also discloses the clear-vs-unchanged semantics of condition arrays.

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?

Long but front-loaded: the inactive-definition constraint and misuse cases come first, then rule semantics. Content is dense with little waste, though the condition-type enumeration is effectively repeated across the entry/exit/restart clauses, which adds length without new information per repetition.

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

Completeness5/5

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

No output schema exists, and the description compensates by stating the return shape (id, name, status, rules, version). Combined with mutation semantics, non-activation guarantee, and tenant binding, an agent has everything needed to call this correctly.

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

Parameters5/5

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

Schema coverage is 100% (baseline 3), but the description adds real meaning beyond it: which condition types require which fields (segmentId for membership types, contactFilters for contact_matches_filters, optional campaignIds/linkUrl for email types), that an empty array clears a slot while omitting the key leaves it unchanged, and how reentryWaitMinutes couples to reentryPolicy=every_time.

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 ('Create a new automation DEFINITION') and immediately scopes it by clarifying the created object is inactive and does not run. It explicitly differentiates from siblings mcp_crm_automations_update and mcp_crm_automations_set_steps.

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?

Gives explicit when-to-use ('define a new automation by name') plus multiple when-NOT-to-use clauses: not to activate/run/wire steps, not to edit (use update instead), not to set status. Alternatives are named concretely rather than implied.

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

All Mailzzy 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.