Skip to main content
Glama
Sign In

LetsBot

by net.letsbot
OverviewDiscussionsAdmin

send_contact_card

Destructive

Send a contact card (vCard) to a WhatsApp number.

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>",
      "contact_name": "<contact_name>",
      "contact_phone": "<contact_phone>",
      "confirm": "<confirm>"
    },
    "name": "send_contact_card"
  }
}

Input Schema

NameRequiredDescriptionDefault
phoneYesWhatsApp number in international format without + (e.g. 201234567890), or the contact's phone / chat_id as listed by get_conversations_awaiting_reply (website chat, Messenger, Instagram, Telegram…)
confirmYesConsent 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 send this contact card.
contact_nameYesName on the contact card
organizationNoOptional organization name
contact_phoneYesPhone number on the contact card

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the description only needs to add context — but it adds none. It does not say the message is sent to an external party and cannot be unsent, and the important two-step confirm/preview consent gate lives only in the schema's 'confirm' parameter description, not in the tool description. Nothing is contradicted, but nothing is added either.

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?

A single lean sentence with the action and target front-loaded and no filler. It is arguably a touch too terse for a destructive external-send tool, but on the conciseness dimension it earns its place.

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?

With a 5-parameter, 4-required destructive send, no output schema, and annotations that flag the risk but not the flow, the description should at minimum echo that a preview/confirm cycle is mandatory. The schema covers it thoroughly, so the tool is usable, but an agent reading only the description would miss the consent gate.

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 description coverage is 100% and the parameter docs are unusually strong (the confirm gate, the phone format, the chat_id fallback). The description itself contributes no parameter meaning, so the baseline 3 for high-coverage schemas applies.

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?

States a specific verb ('Send') and a specific resource ('contact card (vCard)') with the target channel ('WhatsApp number'), which is enough to separate it from the many other send_* siblings (send_file, send_image, send_location). It does not explicitly name those siblings or state how it differs from them, so it lands just short of the top mark.

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 usage context is only implied by the name — an agent can infer 'use when the user wants to share a contact' — but the description never states when to choose this over send_text_message or send_file, nor does it mention prerequisites such as the recipient needing to be a valid WhatsApp-capable number. No alternatives or exclusions are given.

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

All LetsBot toolsInspect
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