LetsBot

delete_contact

Destructive

Permanently delete one contact (a one-to-one chat) together with its whole conversation: every message and media file is erased shortly after, and this cannot be undone. Same as Delete on the contact in the LetsBot panel. Requires confirm: call with confirm=false first to get a preview (name, message count, labels, assigned team members), show it to the user, then call again with confirm=true. It does NOT block the number — the customer can still write again, which creates a new, empty contact; use block_contact to stop someone messaging, or archive_contact to just hide a chat. WhatsApp groups cannot be deleted with this tool. Exporting contacts is only available in the LetsBot panel.

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": {
      "phone": "<phone>",
      "confirm": "<confirm>"
    },
    "name": "delete_contact"
  }
}

Input Schema

Name	Required	Description	Default
`phone`	Yes	Phone number of the contact in international format without + (e.g. 201234567890), or the chat id shown by get_contact.
`confirm`	Yes	Consent gate — REQUIRED on every call. Pass false first: the tool then performs no action and returns a preview of exactly what would happen. Show that preview to the user, get their explicit approval, and only then call again with true to permanently delete this contact and erase its conversation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

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, but the description adds substantial context beyond them: the deletion is irreversible, media is erased shortly after, the number is not blocked so a new contact can reappear, and a preview is returned on the first call. This is exactly the behavioral load a destructive tool needs.

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 irreversible consequence is front-loaded in the first clause, then the confirm protocol, then the alternative-tool disambiguation. Despite its length every sentence carries decision-relevant information, with no filler.

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?

For a two-parameter destructive mutation with no output schema, the description covers consequence, reversibility, the consent workflow, alternative tools, and an explicit exclusion. Nothing an agent needs to call this safely is missing.

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 both parameters are already fully documented, giving a baseline of 3. The description adds value by specifying what the preview contains (name, message count, labels, assigned team members), which clarifies the purpose of the confirm gate beyond the schema's wording.

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 ('Permanently delete one contact'), scoped to a one-to-one chat, and explicitly excludes WhatsApp groups. It distinguishes itself from sibling mutations by naming block_contact and archive_contact as the tools for adjacent intents.

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?

Explicitly says when to use this tool versus alternatives ('use block_contact to stop someone messaging, or archive_contact to just hide a chat'), covers the when-not case (groups cannot be deleted), and prescribes the mandatory confirm=false → preview → confirm=true sequence.

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

All LetsBot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?