Skip to main content
Glama
prodmeevan

whatsapp-mcp-free

by prodmeevan

newsletter_mute

Mute or unmute a WhatsApp channel by providing its JID and setting muted to true or false; requires confirm=true to apply.

Instructions

Mute/unmute a channel. Requires confirm=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jidYes
mutedNotrue=mute, false=unmute
confirmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It discloses the confirmation gate ('Requires confirm=true') and implies a mutating toggle, which is useful, but it does not describe side effects, idempotency, or reversibility. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short sentence with the action front-loaded and the critical prerequisite appended. Every word contributes; there is no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter toggle, the description plus schema gives an agent enough to call it: jid, muted, and confirm=true. But with no annotations or output schema, a bit more context about the effect of muting and the confirmation failure mode would make it fully self-sufficient.

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 only 33%, and the description helps by mapping 'mute/unmute' to the muted boolean and by flagging confirm as required. It adds no meaning for jid, which is the only required parameter and is left as a bare string in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Mute/unmute') on a clear resource ('a channel'), which is more than a tautology and aligns with the tool name newsletter_mute. It doesn't explicitly contrast with sibling tools like newsletter_follow or newsletter_unfollow, but the action itself is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description names the operation and the prerequisite 'Requires confirm=true', so it tells the agent how to invoke it correctly. However, it doesn't specify when to choose this over sibling tools such as newsletter_unfollow or list_newsletters, leaving selection largely to inference from the tool name.

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