WACrew

responder_midia

Send images, documents, audio, or video to a WhatsApp group, reusing files already received or new paths, with captions in the operator's voice. Confirm recipient and file first.

Instructions

Envia um arquivo para um grupo no WhatsApp: imagem com legenda, documento/PDF, áudio (nota de voz) ou vídeo. REGRA: só chame DEPOIS de confirmar com o usuário o destinatário e o arquivo. Se houver legenda (caption), o texto deve passar pela skill de voz do operador e ser confirmado, igual ao 'responder'. O 'path' pode ser absoluto (arquivo novo no disco) OU o mediaPath de uma mensagem já recebida (campo 'midia') para reenviar.

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": {
      "grupo": "<grupo>",
      "kind": "<kind>",
      "path": "<path>"
    },
    "name": "responder_midia"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	tipo do arquivo
`path`	Yes	caminho absoluto do arquivo OU mediaPath relativo (de uma mensagem recebida)
`grupo`	Yes	nome exato do grupo OU o jid
`caption`	No	legenda (ignorada em audio); escreva na voz do operador, é revisada como o responder
`fileName`	No	obrigatório para document — nome exibido
`mimetype`	No	opcional (document); inferido pela extensão se ausente
`operador_pediu`	No	true SÓ quando o operador pediu, nesta conversa, este envio pra este chat. Libera a trava do autônomo de quando ele respondeu pelo celular (`operador_assumiu`); nunca a de 'é IA?' (`perguntou_ia`). Nunca use por conta própria pra contornar a trava.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it discloses the outbound side effect (message sent to a real group), the confirmation gates, the two locks it can interact with (operador_assumiu vs perguntou_ia) and the explicit warning never to set the bypass flag to work around them. It also clarifies caption text is operator-voice and gets reviewed, which an agent could not infer from 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?

Purpose is front-loaded in the first sentence, followed by the rule and the path clarification in priority order. It is dense but every clause carries operational weight; only the caption/voice sentence is somewhat long and nested, costing a point.

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?

Seven parameters, no output schema, no annotations, and a destructive real-world side effect — the description covers preconditions, the caption pipeline, and both locking mechanisms, which is most of what an agent needs. It does not describe what a successful send returns or how failures (bad path, unsupported mimetype) surface, leaving a small gap for a 7-parameter mutation tool.

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

Parameters3/5

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

Schema coverage is 100%, so every parameter including 'path', 'caption', 'fileName' and 'operador_pediu' is already documented in the schema. The description restates the path dual behavior (absolute file vs mediaPath of a received message) to frame it as a resend workflow, which adds a little intent but largely duplicates structured text. Baseline 3 fits.

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 ('envia um arquivo para um grupo no WhatsApp') and enumerates the exact supported kinds: image with caption, document/PDF, audio voice note, video. It also implicitly separates itself from 'responder' by noting the caption path mirrors that tool, so an agent can tell the two apart without opening schemas.

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 an explicit hard precondition ('só chame DEPOIS de confirmar com o usuário o destinatário e o arquivo'), a second confirmation gate for captions via the operator voice skill, and a rule for when 'operador_pediu' may be set versus never used on the agent's own initiative. This is when-to-use, when-not-to-use, and prerequisite guidance in one pass.

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