Arara MCP

Official

Overview Schema Source Related Servers Discussions Admin

create_automation

Creates an inactive WhatsApp automation from a trigger and ordered steps, letting you review the flow before separate approval activates message sending.

Instructions

Create an automation. It is always born INACTIVE and this tool never activates it: nothing is sent until the user approves set_automation_active. Shape: {name, trigger, triggerConfig?, steps}. All wire values are lowercase. Triggers: webhook, cart.abandoned, payment.failed, tag.applied, conversation.started, button.replied, charge.paid, charge.expired. A step is {type, config, branches?}. Types: message {templateId, variables[]} or {sessionText} ({sessionText, chargeFromRun:true} sends the charge that came with the trigger); wait {minutes}; condition {tag}; tag {tag}; question {mode:'buttons'|'list'|'template', text, buttonText? (list only), options:[{id,title,match[]}], timeoutMinutes, retryText?, templateName?/templateId?/variables? (template mode)} with branches keyed by option id plus '__timeout' and '__other'; wait_payment {timeoutMinutes} with branches 'paid' and 'unpaid'. Hard rules: at most 2 levels of branching steps (question / wait_payment inside a branch counts as level 2); buttons take up to 3 options with title up to 20 chars; list takes up to 10 options with title up to 24 chars; sessionText and question modes 'buttons'/'list' only reach people inside the 24h WhatsApp window, so the FIRST message to someone outside it must be a template message or a question in 'template' mode. Pick templateId from list_automation_templates. Example: {"name":"Carrinho","trigger":"cart.abandoned","steps":[{"type":"wait","config":{"minutes":30}},{"type":"question","config":{"mode":"template","templateName":"carrinho_lembrete","variables":["{{name}}"],"text":"Ainda quer o pedido?","options":[{"id":"sim","title":"Quero","match":["sim","quero"]},{"id":"nao","title":"Agora nao","match":["nao"]}],"timeoutMinutes":1440},"branches":{"sim":[{"type":"message","config":{"sessionText":"Segue o link: https://loja.example/checkout"}}],"nao":[{"type":"tag","config":{"tag":"sem-interesse"}}],"__timeout":[{"type":"tag","config":{"tag":"sem-resposta"}}]}}]}. When the API refuses the payload it answers with a sentence saying what to fix; correct the payload and call again.

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>",
      "trigger": "<trigger>",
      "steps": "<steps>"
    },
    "name": "create_automation"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`steps`	Yes
`trigger`	Yes
`triggerConfig`	No

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	No
`error`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv6.0.1Nov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only say this is a non-read-only, non-idempotent write; the description goes far beyond that by disclosing that nothing is sent until a separate approval step, that repeated calls create new automations, and how failures surface ('the API refuses the payload answers with a sentence saying what to fix; correct the payload and call again'). That error-recovery contract is exactly the kind of behavior annotations cannot express.

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?

Purpose and the inactive-state warning are front-loaded, then shape, then rules, then a worked example, which is the right order. It is a dense wall of prose rather than bullets, and the embedded example is long, but nearly every clause encodes a rule an agent would otherwise get wrong.

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?

For a deeply nested, 4-parameter polymorphic payload with no schema descriptions, the definition covers grammar, domain rules (the 24h WhatsApp window forcing template mode), limits, and a full example. An output schema exists, so omitting return-value detail is appropriate.

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 description coverage is 0%, so the description carries the full burden and does: it gives the top-level shape, the allowed trigger values, per-step-type config keys, branching keys ('__timeout', 'paid'/'unpaid'), and hard limits such as two branching levels and the 3-option/20-char button cap. These constraints exist nowhere in the schema.

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 opens with a specific verb+resource ('Create an automation') and immediately qualifies the resulting state ('always born INACTIVE'), which is the single most consequential fact about this tool. An agent can distinguish it from update_automation and set_automation_active without opening any schema.

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 names two siblings with explicit conditions: activation requires set_automation_active, and templateId must come from list_automation_templates. It also states a when-not ('this tool never activates it'). The only gap is that it never distinguishes create from update_automation when a similar automation already exists, which is left to inference.

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