WACrew

alertar_chat

Enable or disable Mac desktop notifications for incoming client messages in a WhatsApp group or DM by slug, alerting the human operator without waking the agent.

Instructions

Liga/desliga a NOTIFICAÇÃO NO MAC (pro humano) quando chega mensagem de cliente num chat — grupo OU DM — por slug. NÃO acorda o agente nem faz o Claude reagir sozinho: é só um aviso de tela pro operador. (Pra o AGENTE ser acordado por mensagem nova — modo monitor/autônomo — arme um Monitor no data/<slug>/messages.jsonl, ver CLAUDE.md.) Opt-in por conversa. Depois de notificado, use novidades pra puxar o que chegou.

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

Input Schema

Name	Required	Description	Default
`grupo`	Yes	slug do grupo ou DM (de listar_grupos; DM = dm-<id>)
`ativar`	Yes	true = passa a te notificar; false = para

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations supplied, the description carries the burden and does so well: it clarifies the effect is only an on-screen warning to a human, that it does not wake the agent, that it is opt-in per conversation, and that ativar toggles persistent notification state. It stops short of saying whether a confirmation/return is produced or what happens if the slug is invalid, so a full 5 is not warranted.

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-loads the core action and uses caps/parentheses to make the human-vs-agent distinction unmissable, with the follow-up tool named last. It is information-dense rather than padded, though the parenthetical cross-reference to CLAUDE.md adds minor clutter.

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 two-parameter toggle tool this covers purpose, negative scope, the alternative for agent wake-up, and the next step after notification — enough to call it correctly and to choose against alternatives. The only gap is post-call behavior (no confirmation or error semantics), which is small given there is no output schema.

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% and already defines grupo (slug from listar_grupos, DM = dm-<id>) and ativar (true/false semantics). The description restates the slug-scoped, per-conversation nature of grupo but adds no new format or edge-case detail beyond the schema, so baseline 3 applies.

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 concrete verb pair (liga/desliga) and resource (notificação no MAC para o humano) scoped per chat via slug, covering grupo OU DM. It explicitly separates itself from agent-waking behavior, so an agent can tell it apart from monitor-mode alternatives 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?

Gives explicit when-to-use (avisar o operador humano), explicit when-NOT (não acorda o agente nem faz o Claude reagir) plus the alternative route for that goal (arme um Monitor em data/<slug>/messages.jsonl) and the follow-up tool (novidades). Also notes opt-in por conversa, which sets the expectation that state must be enabled per chat.

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