WACrew

transcrever

Transcribe WhatsApp audio and video messages from a group—single media by path or message ID, or up to eight pending items per call—and return cached text for reuse.

Instructions

Transcreve áudio/vídeo (MLX local, large-v3) e devolve o texto; reusa cache. UMA mídia específica: passe mediaPath (campo 'midia' de ler_mensagens) OU id (campo 'id' da mensagem) — os dois funcionam; qualquer outro nome de parâmetro é ignorado. SEM os dois: transcreve um lote dos pendentes do grupo (até 8 NOVOS por chamada; o que já tem transcrição não ocupa vaga e vem em em_cache; os que só estão na nuvem baixam em paralelo). Se sobrar além do teto, o retorno traz restantes — chame de novo e o lote AVANÇA. Em modo remoto a transcrição é publicada na nuvem, então ler_mensagens passa a trazer transcricao.

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

Input Schema

Name	Required	Description
`id`	No	id da mensagem (campo 'id' de ler_mensagens) de UMA mídia — alternativa ao mediaPath
`grupo`	Yes	slug do grupo
`mediaPath`	No	mediaPath relativo (campo 'midia') de UMA mídia

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it discloses the per-call cap (up to 8 NEW), that already-transcribed items don't consume a slot and return in `em_cache`, that cloud-only items download in parallel, and the side effect that in remote mode the transcription is published to the cloud so ler_mensagens later exposes `transcricao`. That is exactly the kind of mutation/pagination context annotations would otherwise supply.

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, then single-media mode, then batch mode, then the retry rule, then the remote-mode effect — a sensible order. It is dense with semicolons and parentheticals in one long block, which costs a little readability, 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 a 3-parameter tool with no annotations and no output schema, the description is unusually complete: modes, cap, cache reuse, batch advancement, and return-field names (`em_cache`, `restantes`) are all covered. Gaps are secondary — no guidance on failure cases (missing/corrupt media, unsupported format) or expected latency for a large-v3 local run.

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% and the schema already labels `id` as an alternative to `mediaPath`, so the baseline is 3. The description still adds real meaning: the two parameters are equivalent single-media selectors, unknown parameter names are silently ignored, and omitting both flips the tool into batch mode over `grupo` — a semantic switch not expressible 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?

Opens with a specific verb+resource+output: "Transcreve áudio/vídeo (MLX local, large-v3) e devolve o texto; reusa cache." It also names the model/backend and the cache behavior, so an agent knows exactly what capability it is invoking and what it gets back.

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 states explicitly when to use each mode: pass `mediaPath` (from ler_mensagens 'midia') OR `id` (from message 'id') for ONE specific media, and with neither it transcribes the group's pending batch. It also gives a retry rule: if `restantes` comes back, "chame de novo e o lote AVANÇA", plus the caveat that any other parameter name is ignored.

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