Skip to main content
Glama
Sign In

Radar noEixo

by com.noeixodigital
OverviewDiscussionsAdmin

Update sequence

update_sequence
DestructiveIdempotent

📋 CADÊNCIAS DE PROSPECÇÃO — Edita uma cadência existente (todos os campos opcionais, só altera o que for enviado). is_active=false PAUSA a cadência inteira e pausa automaticamente todas as matrículas ativas dela (o dispatcher para de rodar essa sequência); is_active=true faz o inverso, retomando as matrículas pausadas que NUNCA responderam (repliedAt vazio — quem respondeu fica pausado, preservado). steps substitui o array INTEIRO (mesmo formato de create_sequence) — obtenha os steps atuais via list_sequences antes de editar parcialmente.

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

Input Schema

NameRequiredDescriptionDefault
nameNoNovo nome (opcional)
stepsNoArray JSON com os steps NOVOS, substituindo os atuais por completo (mesmo formato de create_sequence). Omitir para não alterar os steps.
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.
is_activeNoLiga/desliga a cadência inteira e sincroniza as matrículas (opcional)
daily_limitNoNovo limite diário de disparos (opcional)
descriptionNoNova descrição (opcional)
sequence_idYesID da cadência (obtido via list_sequences)
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.7/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint/idempotentHint): it discloses that pausing stops the dispatcher and cascades a pause to active enrollments, that resuming only affects enrollments that never replied (repliedAt empty), and that replied enrollments stay paused. That is exactly the kind of consequence disclosure a destructive tool needs.

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?

Dense but front-loaded, leading with the resource and the optional-fields model before the risky parts. The emoji header and long single paragraph slightly reduce scanability, but no sentence is filler.

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 an 8-parameter destructive mutation with no output schema, the description covers the main hazards (step replacement, enrollment cascade, pause/resume scope). It does not discuss failure modes or whether partial updates can be reverted, which keeps it short of a 5.

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, but the description adds real meaning the schema lacks: the enrollment-synchronization and repliedAt nuance for is_active, and the array-replacement warning for steps beyond the schema's own note.

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 ('Edita uma cadência existente') plus the crucial update semantics (all fields optional, only the sent fields are modified), which cleanly separates it from create_sequence and delete_sequence in the sibling list.

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 operational guidance: obtain current steps via list_sequences before a partial edit because steps replaces the whole array, and spells out what is_active=false vs true does so the agent knows when each is appropriate.

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

All Radar noEixo 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