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

TableJSON Schema
NameRequiredDescriptionDefault
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. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, and the description still adds substantial behavior: ordering rules, the fact that status/read/flag/assignee changes do not refresh `last_message_at`, platform-timestamp skew, caption-less media not counting, deleted conversations never appearing, and `422 invalid_request` for a bogus cursor.

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?

Long and dense, but front-loaded with purpose and the polling workflow before edge cases, and nearly every clause carries operational meaning (timestamp skew, caption-less messages, window rules). It leans on heavy parentheticals and a single sprawling paragraph rather than headings, which slightly hurts scannability.

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 covers the return shape itself (last message, author, timestamp, read state, attention flags, AI state, assignee), plus pagination, dedupe and error behavior. For a 12-parameter read tool this is as complete as the format allows.

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 75% and several undescribed params (status, is_read, contact_id) get no individual explanation. However, the description adds real semantics beyond the schema: that filters without `active_since`/`contact_id` are bounded to 90 days, that `active_since` follows `last_message_at` only, and that `search` is limited to name and last message.

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+resource ("List an agent's conversations") and goes on to define exact scope: most recently active first, removed/empty conversations excluded, and what each item carries. It also distinguishes itself from siblings by naming `getConversation` for message-less conversations and clarifying that `search` never reaches inside message 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`) and states exactly when to reach for `getConversation`. It also explains the default 90-day window for filtered lists and the condition (sending `active_since`) that lifts it.

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