Skip to main content
Glama

Create sequence

create_sequence

📋 CADÊNCIAS DE PROSPECÇÃO (multi-touch, multi-day) — Cria uma nova cadência de prospecção ativa. Use quando o usuário quiser: sequência de prospecção, cadência de contato, follow-up automático ao longo de dias, sequência multicanal (WhatsApp + email + LinkedIn). (Automações que reagem a eventos são outra ferramenta: create_automation.) Tipos de step: send_whatsapp, send_email, send_sms, send_linkedin, send_facebook, add_tag (campo tag: nome da etiqueta), move_stage (campo stageId: id da etapa, de list_pipeline_stages), send_webhook (delega o toque pra um sistema externo, ex: RD Station Marketing Conversion Events API, pra usar um e-mail com o design/marca da empresa em vez do texto simples do send_email — config: webhookUrl, webhookMethod, webhookPayload, webhookHeaders, todos com {{contact.*}} disponível). Variáveis: {{contact.name}}, {{contact.firstName}}, {{contact.company}}, {{contact.phone}}, {{contact.email}}. Em steps send_email, também disponível {{unsubscribe_url}} (opcional — o link de descadastro one-click já sai automático no header do e-mail (RFC 8058); use essa variável no corpo só se quiser deixar visível também, ex: rodapé "não quer mais receber? clique aqui").

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

Input Schema

NameRequiredDescriptionDefault
nameYesNome da cadência, ex: "Prospecção Agências SC — 14 dias"
stepsYesArray JSON com os steps da cadência. Cada step deve ter: id (string único), delayDays (inteiro), delayHours (inteiro), type, e template (para send_*). O delay é relativo ao step anterior. ⚠️ 1º TOQUE FRIO NO WHATSAPP (step type send_whatsapp SEM janela de atendimento aberta): a Meta só aceita um template WABA JÁ APROVADO, nunca texto livre — usar só "template" nesse caso falha silenciosamente ou é rejeitado pela Meta. Para esse caso, o step precisa de "waTemplateName" (nome exato do template aprovado — confira com get de templates aprovados antes, ex: via /templates no Radar ou API meta-templates), "waTemplateLang" (ex: "pt_BR") e "waTemplateParams" (array de strings, uma por variável {{1}},{{2}}... do template, na ORDEM exata — cada item pode usar {{contact.firstName}} etc ou texto literal; a contagem tem que bater exatamente com as variáveis do template, a Meta rejeita se não bater). "template" continua opcional nesse caso — só é usado como texto de exibição no histórico da conversa, não é o que é enviado. Steps de follow-up (D+3 em diante), depois que o contato já respondeu e a janela de 24h está aberta, podem usar "template" (texto livre) normalmente, sem waTemplateName. Exemplo (1º toque frio via template aprovado + follow-up livre): [ {"id":"s1","delayDays":0,"delayHours":0,"type":"send_whatsapp","waTemplateName":"primeiro_toque_aprovado_v1","waTemplateLang":"pt_BR","waTemplateParams":["{{contact.firstName}}"],"template":"Oi {{contact.firstName}}! [texto igual ao template, só pra exibição]"}, {"id":"s2","delayDays":3,"delayHours":0,"type":"send_whatsapp","template":"{{contact.firstName}}, tudo bem? Queria saber se teve chance de ver minha mensagem..."}, {"id":"s3","delayDays":5,"delayHours":0,"type":"send_linkedin","template":"Oi {{contact.name}}, te mandei mensagem no WhatsApp sobre..."}, {"id":"s4","delayDays":7,"delayHours":0,"type":"send_email","emailSubject":"Site da {{contact.company}}","template":"Olá {{contact.name}}, Passei pelo site da {{contact.company}}..."} ]
numeroNoWhatsApp por onde a cadência envia (telefone, ex.: "5548991589433", ou o id em list_agent_profiles → numeros). Os modelos dos toques precisam existir nesse número (list_whatsapp_templates com o mesmo numero). Vazio = o número principal; "principal" volta ao principal.
daily_limitNoMáximo de disparos por dia (padrão: 50). Use valores menores para evitar bloqueio no WhatsApp.
descriptionNoDescrição opcional da cadência
target_user_idNoID da conta-alvo (opcional; APENAS o admin da plataforma pode usar). Padrão: a conta autenticada.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / numero
      Added value: +{
      +  "description": "WhatsApp por onde a cadência envia (telefone, ex.: \"5548991589433\", ou o id em list_agent_profiles → numeros). Os modelos dos toques precisam existir nesse número (list_whatsapp_templates com o mesmo numero). Vazio = o número principal; \"principal\" volta ao principal.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare non-readonly, non-destructive, and not open-world. The description adds useful behavioral context beyond annotations: send_webhook delegates to an external system, contact variables are available, and unsubscribe_url is optional because RFC 8058 headers are automatic. It does not mention the WhatsApp approved-template prerequisite or post-create enrollment lifecycle, but those gaps are partly covered by the schema.

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 long, but it front-loads purpose and usage before diving into step semantics, which is appropriate for a complex multi-step creation tool. Some parenthetical density and repetition with the schema keep it from being maximally concise.

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 complex create tool with no output schema, the description covers purpose, sibling differentiation, step types, variables, and key behavioral constraints. It could be slightly more complete by mentioning what happens after creation, such as enrollment or returned sequence identity.

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 the baseline is 3. The description adds real meaning for the complex steps parameter by enumerating allowed step types and extra fields such as tag, stageId, and webhook config, which are not fully documented in the schema itself.

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 states a specific verb and resource: 'Cria uma nova cadência de prospecção ativa'. It also distinguishes the tool from its closest sibling by explicitly saying event-driven automations belong to create_automation. An agent can identify the tool without opening the schema.

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?

It gives explicit when-to-use cases: prospecting sequence, contact cadence, multi-day follow-up, and multichannel sequence. It also names the alternative create_automation and the condition that selects it, so routing between the two is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources