Skip to main content
Glama

List chats

list_chats
Read-onlyIdempotent

Retrieve and browse WhatsApp chats from a local archive, sorted by recent activity or name, with filters and cursor-based pagination.

Instructions

List WhatsApp chats (people and groups), most recently active first or by name, optionally filtered by a name, JID or contact. Paginated by cursor.

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": "list_chats"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNopage size (default 20, max 200)
queryNofilter by chat name, JID, or contact name/number
cursorNonext_cursor from the previous page
sort_byNolast_active (default) or name
include_last_messageNoinclude the latest message of each chat (default true)

Output Schema

NameRequiredDescriptionDefault
chatsYes
has_moreYes
next_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the default ordering (most recently active first) and cursor pagination, but says nothing about result size behavior, whether all chats or only synced ones are returned, or token/scope requirements.

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?

A single tight sentence that front-loads the resource, then scope, ordering, filtering and pagination. No filler and nothing superfluous.

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

Completeness4/5

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

With a full schema, rich annotations and an output schema, the description only needs to convey scope, ordering, filtering and pagination, and it does. The only shortfall is that it does not situate the tool relative to neighboring retrieval tools.

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 does add connective meaning: it explains that filtering works on name, JID or contact, and that sorting is either recent activity or name, framing how query and sort_by interact. It does not cover limit or include_last_message, which the schema already documents.

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 and resource (list WhatsApp chats) plus scope (people and groups), with ordering, filtering and pagination noted. It does not distinguish itself from siblings such as get_contact_chats or search_contacts, which an agent could easily confuse with a filtered chat list.

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?

Usage is only implied: the reader infers this is the enumeration tool to call when browsing chats. There is no explicit statement of when to prefer it over get_contact_chats, get_chat, or search_contacts, and no exclusions.

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