Skip to main content
Glama

Search WhatsApp

query
Read-onlyIdempotent

Query WhatsApp data: conversations, contacts, messages, transcriptions, labels, and communities. Supports listing, searching, filtering, and looking up by ID.

IMPORTANT: Multiple WhatsApp accounts may be connected (e.g. personal + business). Always query entity="session" FIRST to see all connected accounts and their session IDs. Then use target_session to route queries to the correct account. Each account has different conversations, contacts, and messages.

HOW TO READ MESSAGES: To get messages from a specific conversation, pass its id (e.g. "5491157390064@c.us"). This returns the conversation info WITH its messages. Use limit to control how many. Do NOT use entity="messages" for this — that is for global text search only.

AUDIO TRANSCRIPTIONS: To get audio transcriptions, use entity="transcriptions" with an optional query. Or pass a conversation id to see messages (audio messages include transcription text).

Examples: List sessions: { entity: "session" } List conversations: {} Target specific account: { entity: "conversations", target_session: "sess_abc123" } Read messages: { id: "5491157390064@c.us" } Read last 100 msgs: { id: "5491157390064@c.us", limit: 100 } Search globally: { query: "meeting" } Search in chat: { id: "5491157390064@c.us", query: "meeting" } Unread conversations: { unread: true } Search contacts: { query: "Alice", entity: "contacts" } List labels: { entity: "labels" } Filter by label: { label: "Important", entity: "conversations" } List communities: { entity: "communities" } Filter by community: { community: "My Community", entity: "conversations" } Find which groups a contact is in: { id: "5491157390064@c.us", entity: "contacts", include_participants: true } List members of a group: { entity: "contacts", group: "120363421729019499@g.us" }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoLook up a specific conversation, contact, or label by ID
listNoFilter conversations by list name or ID (Personal accounts)
afterNoReturn messages after this ISO 8601 datetime (e.g. "2026-03-01T12:00:00.000Z") for incremental sync
groupNoFilter contacts by group ID — only return contacts that are members of this group
labelNoFilter conversations by label name or ID (Business accounts)
limitNoMax results (default 25, max 5000)
queryNoText to search for (names, messages, transcriptions)
beforeNoReturn messages before this ISO 8601 datetime (e.g. "2026-03-01T12:00:00.000Z") for cursor-based pagination backward
entityNoEntity type to query. Defaults to "conversations" when listing, or all when searching. Use "session" to list all connected WhatsApp accounts.
unreadNoOnly return conversations with unread messages
communityNoFilter conversations by community name or ID
exclude_mutedNoExclude muted conversations from listings (default false)
target_sessionNoSession ID to target a specific WhatsApp account. Get session IDs from entity="session". If omitted, routes to the most recently active account.
exclude_archivedNoExclude archived conversations from listings (default true)
include_participantsNoInclude group participants in results. Useful when looking up a contact by ID to see which groups they belong to, or when querying a group to see its members.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNoThe JSON-compatible result returned by the Kaption extension

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-structured behavior: multiple accounts may be connected, queries default to the most recently active account when target_session is omitted, and id-lookup returns conversation info WITH its messages. It stops short of describing pagination/return shape, but that is largely handled elsewhere.

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?

Well front-loaded — purpose, then the critical session-routing caveat, then usage sections. The example block is long and slightly redundant (several read-message variants), but each example demonstrates a distinct call shape and the structure is scannable.

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?

With an output schema present, return values need not be explained. The description covers the multi-account complexity, entity selection, ID-vs-search distinction, and transcription access — everything an agent needs to invoke this broad 15-parameter tool correctly.

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 baseline is 3, but the description adds real meaning beyond the schema: entity="session" is positioned as the mandatory first step, target_session's default routing behavior is explained, and the id+limit interaction ('use limit to control how many') clarifies semantics not spelled out per-parameter.

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 (Query) and enumerates the exact resources (conversations, contacts, messages, transcriptions, labels, communities) plus the supported operations (listing, searching, filtering, lookup by ID). An agent can distinguish this from siblings like get_contact, list_contacts, and summarize_conversation without opening a schema.

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 routes the agent: query entity="session" FIRST for multi-account routing, then target_session. It names the alternative and the exclusion ('Do NOT use entity="messages" for this — that is for global text search only'), and the example block maps intents to calls.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources