Skip to main content
Glama
Sign In
askmywa

askmywa

by Ruwad-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

Search contacts

search_contacts
Read-onlyIdempotent

Search WhatsApp contacts by name or phone number using case- and accent-insensitive matching, returning names, phone numbers, LIDs, and JIDs needed to list messages or send.

Instructions

Search WhatsApp contacts by name or phone number. Matching is case- and accent-insensitive ("elodie" finds "Élodie"). Each result gives the best known name, the phone number and/or LID, and the JID to pass to list_messages (chat_jid) or to the send tools (recipient).

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": {
      "query": "<query>"
    },
    "name": "search_contacts"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNomaximum number of results (default 20, max 200)
queryYespart of a name, or digits of a phone number
cursorNonext_cursor from the previous page

Output Schema

NameRequiredDescriptionDefault
contactsYes
has_moreYes
next_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral detail beyond them: matching is case- and accent-insensitive, and each result carries best-known name plus phone and/or LID plus JID. Pagination behavior is only implied via the schema's cursor field.

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?

Three tight sentences with no filler: capability first, matching semantics second, result shape and chaining third. Nothing is repeated from the schema or annotations.

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 three-parameter read-only search with an output schema, the description covers everything an agent needs: what it searches, how matching behaves, and which returned field feeds which downstream tool. No relevant decision input 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 the baseline is 3, but the description adds real meaning about how the query parameter matches (accent- and case-insensitive substring of a name, or digits of a phone number). It does not restate limit or cursor semantics, which the schema already documents.

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?

The description opens with a specific verb+resource ("Search WhatsApp contacts") and immediately scopes the search key to name or phone number, which cleanly separates it from message/chat siblings like list_messages, list_chats and get_chat. An agent can tell what it retrieves and what it is not 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 Guidelines4/5

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

It gives concrete usage context by stating exactly what each result field is for: chat_jid for list_messages and recipient for the send tools. It stops short of explicit exclusions, so it never says when to prefer a sibling such as get_direct_chat_by_contact or get_contact_chats instead.

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

Deploy Server

Other Tools