Skip to main content
Glama

List an agent's conversations

list_conversations
Read-onlyIdempotent

List an agent's conversations

The agent's conversations, the most recently active first (pinning is a dashboard view and doesn't change the order). Each one carries its last message, who wrote it and when, whether the team has read it, its attention flags, the AI's state and its assignee, so you can tell which ones have new messages without reading them: poll with active_since set a few minutes before the newest last_message_at you have seen (messages sent from the WhatsApp or Meta apps carry the platform's earlier time), page while has_more, and drop messages you already have by id. active_since follows last_message_at only: a change of status, read state, flags or assignee doesn't bring a conversation back, and neither does a customer's photo, voice note, sticker or file sent without a caption until a later message, such as the AI's answer, moves last_message_at. A conversation with no message yet (such as a website chat the visitor opened but hasn't written in) isn't listed; getConversation reads it. search matches the customer's name or the last message only; nothing searches inside message history. Deleted conversations never appear. Filtered by status, channel, is_read, urgent or assigned_to without active_since (and without contact_id), the list covers the last 90 days of activity before active_before or now; send active_since to reach further back.

Input Schema

NameRequiredDescriptionDefault
ad_idNoOnly conversations whose latest touch was on this ad (a conversation's `latest_ad_id`; an id from `listAds`).
limitNoPage size, 1 to 100 (values outside are clamped). Default 20.
cursorNoOpaque cursor from the previous page's `next_cursor`. Omit for the first page. A cursor the API didn't return is `422 invalid_request`.
searchNoPart of the customer's name or of the last message, 3 to 128 characters, without `, ( ) " * %` or a backslash.
statusNo
urgentNoThe `urgent` flag exactly. The dashboard's "Needs Attention" filter also counts an unhappy `sentiment`.
channelNoOne channel, or several comma-separated, case-insensitive: the values of a conversation's `channel`.
is_readNo
agent_idYesThe agent the resource belongs to. Another company's agent, or the nil UUID, is `404 agent_not_found`; an agent outside the key's agent list is `403 agent_not_authorized`.
contact_idNo
assigned_toNoA teammate's `user_id`, or `unassigned`. Not `me`: a key isn't a person.
active_sinceNoOnly conversations whose last message is at or after this instant (ISO 8601 with an offset, such as `2026-10-15T09:00:00Z`). Sending it also lifts the 90-day window of a filtered list.
active_beforeNoOnly conversations whose last message is before this instant.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / ad_id
      Added value: +{
      +  "description": "Only conversations whose latest touch was on this ad (a conversation's `latest_ad_id`; an id from `listAds`).",
      +  "format": "uuid",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: pinning does not affect order, media-only messages don't move `last_message_at`, search is shallow, and the filtered-list time window defaults to 90 days. These are exactly the non-obvious traits an agent needs to poll correctly.

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?

Purpose and ordering are front-loaded, and nearly every clause carries operational information. However, the body is one dense, run-on paragraph mixing return-value description, polling strategy, and filter semantics, which makes it harder to scan than a short structured split would be.

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 no output schema, the description carries the burden of the return shape and does so: last message, author and time, read state, attention flags, AI state, assignee, plus `has_more`/`next_cursor`/`id` for paging. Combined with the window and edge-case rules, an agent has everything needed to call this 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 77%, so many parameters are already documented. The description still adds meaning the schema lacks: the interaction between `active_since` and the 90-day window, the fact that `active_since` tracks only `last_message_at`, and the limited scope of `search`. It does not add per-parameter syntax beyond that, so a 4 rather than a 5.

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?

Opens with a specific verb and resource ('List an agent's conversations') and immediately establishes ordering ('most recently active first'). It distinguishes itself from siblings by naming `getConversation` for the unlisted no-message case and by scoping `search` to name/last-message only, versus `list_conversation_messages` which reads history.

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?

Gives an explicit polling recipe (set `active_since` a few minutes before the newest `last_message_at`, page while `has_more`, dedupe by `id`), states which mutations do and do not bump `active_since`, and clarifies the 90-day default window plus how `active_since` lifts it. It also states what is never returned (deleted conversations, message-less conversations).

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