Radar noEixo

Send whatsapp template

send_whatsapp_template

Destructive

📱 Envia um TEMPLATE WhatsApp Business (WABA) já APROVADO pela Meta para um número — necessário pra contato FRIO (sem janela de atendimento de 24h aberta), já que texto livre (send_whatsapp_message) é rejeitado nesse caso. Use list_whatsapp_templates antes pra confirmar o nome exato e quantas variáveis {{1}}, {{2}}... o corpo do template tem — a contagem de "params" enviada precisa bater exatamente, senão a Meta rejeita com erro de contagem de parâmetros. A mensagem (corpo já interpolado) fica registrada na conversa do contato no Radar (cria Contact/Conversa automaticamente se ainda não existirem).

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": {
      "phone": "<phone>",
      "template_name": "<template_name>"
    },
    "name": "send_whatsapp_template"
  }
}

Input Schema

Name	Required	Description
`phone`	Yes	Número com DDD e código do país (somente dígitos ou formatado, ex: 5511999999999). Não precisa reinserir o 9º dígito de números BR — a normalização é automática.
`numero`	No	Etapa 1b — WhatsApp da conta (telefone, ex.: "5548992172321", ou o id em list_agent_profiles → numeros). Os modelos são da conta da Meta de cada número. Vazio = o número da conversa do contato, ou o principal.
`params`	No	Valores das variáveis {{1}}, {{2}}... do CORPO do template, separados por vírgula, na ordem (ex: "José,eKyte"). Omita se o template não tem variáveis no corpo.
`language`	No	Idioma do template (padrão "pt_BR").
`template_name`	Yes	Nome exato do template já aprovado (ver list_whatsapp_templates).
`target_user_id`	No	ID da conta-alvo (opcional; APENAS o admin da plataforma pode usar). Padrão: a conta autenticada.
`header_image_url`	No	URL pública de uma imagem (opcional) — só se o template tiver cabeçalho de IMAGEM. A Meta busca essa URL em tempo real no envio.
`header_video_url`	No	URL pública de um vídeo (opcional) — só se o template tiver cabeçalho de VÍDEO. Ignorado se header_image_url também vier.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / numero

Added value: +{
+  "description": "Etapa 1b — WhatsApp da conta (telefone, ex.: \"5548992172321\", ou o id em list_agent_profiles → numeros). Os modelos são da conta da Meta de cada número. Vazio = o número da conversa do contato, ou o principal.",
+  "type": "string"
+}

First observedOct 26, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing that the template must already be Meta-approved, that param count must match the body variables exactly or Meta rejects the send, that the interpolated body is recorded in the contact's Radar conversation, that Contact/Conversa are auto-created, and that the header image URL is fetched live by Meta. It does not state whether a send is irreversible or what a rate-limit/failure response looks like, which matters given destructiveHint=true.

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 constraint (approved template, cold contact) before the operational caveats, and every clause carries information. It is a dense single block rather than structured, and the parenthetical about auto-creating Contact/Conversa is somewhat tangential to the call decision.

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, side-effecting, open-world tool with no output schema, the description supplies the critical prerequisites and the failure mode (parameter-count mismatch), which is enough to call it correctly. Missing is any statement of what is returned or confirmation behavior on success, and no coverage of the account-selection parameter.

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 already 100%, so baseline is 3; the description adds a genuine cross-parameter constraint not expressed in the schema — the count of comma-separated 'params' must exactly equal the number of {{1}}, {{2}}... placeholders in the template body — and reinforces the template_name lookup path. It does not add guidance for numero, target_user_id, or the image/video precedence, which stay schema-only.

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 — sends a Meta-approved WABA template message to a number — and immediately contrasts it with the sibling send_whatsapp_message, explaining that free text is rejected outside the 24h window. An agent can distinguish the two without opening either 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?

Explicitly says to use this for cold contacts with no open 24h service window, names send_whatsapp_message as the alternative that fails in that case, and prescribes a prerequisite step (list_whatsapp_templates to confirm exact name and variable count). When-to-use, when-not-to-use, and alternatives are all present.

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

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