Skip to main content
Glama

Disconnect WhatsApp

disconnect_whatsapp
DestructiveIdempotent

Unlink this computer from WhatsApp and stop the background service. Optionally delete stored messages, attachments, and logs while keeping send-folder files.

Instructions

Unlink this computer from WhatsApp (it disappears from Linked devices on the phone) and stop the background service; with delete_archive, also delete the stored messages, downloaded attachments and logs. Use it when the user wants to stop using WhatsApp here or before uninstalling the extension. Files in the send folder are never deleted.

Safety: with confirm=false (the default) NOTHING is changed; the tool returns the list of steps. Show it to the user and call again with confirm=true only after they approved. Never set confirm=true on the first call.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "disconnect_whatsapp"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNofalse (default) only describes what would happen; true does it, after the user approved
delete_archiveNoalso delete the message archive, downloaded attachments and logs from this computer

Output Schema

NameRequiredDescriptionDefault
doneYestrue once everything listed in steps was carried out
stepsYeswhat is (or would be) done, in plain words
accountNo
messageYes
needs_confirmationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds what is actually destroyed (messages, attachments, logs) and a non-obvious exclusion (send folder files are never deleted). It also discloses the dry-run semantics of confirm=false and that it returns the list of steps, which an agent could not infer from annotations alone.

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?

Front-loads what the tool does, then the when-to-use, then a clearly headed Safety block. Every sentence carries distinct information — no restatement of the title or schema.

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

Completeness5/5

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

An output schema exists, so return values need no explanation beyond the noted 'returns the list of steps' dry-run behavior. For a destructive, two-parameter tool the description covers effects, exclusions, and the approval gate completely.

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%, so the baseline is 3; the description earns more by adding the approval protocol around confirm and the scope boundary (send folder untouched) that the schema does not state. It stops short of explaining the interaction between confirm=false and delete_archive, which would have made it a 5.

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 — 'Unlink this computer from WhatsApp' — plus the secondary effect of stopping the background service and the optional archive deletion. The parenthetical about it disappearing from Linked devices makes the effect concrete and clearly distinct from connect_whatsapp.

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 conditions ('when the user wants to stop using WhatsApp here or before uninstalling the extension') and a hard when-not ('Never set confirm=true on the first call'). The mandated two-step approval flow is spelled out step by step, leaving nothing to inference.

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