Skip to main content
Glama

List conversations

list_conversations

Lists threads, most recently updated first, with the contact, the subject of the mail and the one the team gave the thread ("team_subject", null until rename_conversation gives one), the ticket number of a helpdesk case (what the client quotes, null on somebody's mailbox), the status, where the thread stands in the pipeline, who is handling it, whether a draft is waiting for review, the folder each sits in and whether you have read it. Each thread also says since when its contact has been waiting for our answer ("waiting_since", their oldest message still unanswered, null when nobody waits), and when the last reply came and from which side ("last_reply_at", "last_reply_by"): the two figures a helpdesk queue is watched by, to tell which tickets drag. Name a "box" to read ONE mailbox exactly as its screen shows it: its Inbox by default, another folder on demand, and "unread" for the bold rows alone. Without a "box" it lists the whole account by pipeline status instead, which is a different question: a thread sitting unread in a mailbox has a status like any other, so a list by status is not the list of what is waiting to be read.

Input Schema

NameRequiredDescriptionDefault
boxNoThe address of the mailbox to look in, for example "simon@sonentreprise.com": call list_sender_addresses to find it. A support queue is not a mailbox and has no folders.
teamNoNarrows to the threads handed to one team, by its slug (list_teams gives it), taken by one of its members or not. Narrows the account list, so it does not go with "box".
brandNoThe slug of a brand, to narrow to that subdivision of the account: call list_brands to find it.
limitNoHow many threads to bring back, 1 to 200. Defaults to 100.
beforeNoOnly the threads updated before this instant, as an ISO 8601 timestamp such as "2026-08-31T09:00:00Z". This is how you read past the first page: take the "updated_at" of the last thread the answer gave you and ask again with it.
folderNoWhich folder of the box to list: one of inbox, sent, drafts, spam, trash, archive, or the id of a folder a person made (list_folders gives them). Defaults to the Inbox, like opening the mailbox does. Needs "box".
statusNoWhere the thread stands: "open" for one nobody has taken, "customer_reply" when the contact has written back, "answered" once we replied, "delivery_failed" when our reply bounced, "in_progress" while someone works on it, "closed" when it is over.
unreadNoOnly the threads you have not read: the bold rows of the screen, and the same count its Inbox shows. Needs "box". A key that acts for no person has no read state and is told so rather than answered with a list built for nobody.
channelNoThe channel the thread runs on. Email is the usual one; "portal" carries the messages written from a client space.
assigneeNoNarrows to the threads one person is handling, by the email address they sign in with, which list_people gives. The word "none" answers with what nobody has taken yet, which is the queue waiting to be shared out (a thread handed to a team has been shared out). Narrows the account list, so it does not go with "box".
external_refNoNarrows to the threads of one contact identified by the reference a consumer app gave them, for example "epovest:account:42".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses ordering, defaults, null semantics for team_subject/ticket/waiting_since, and an operational quirk ('A key that acts for no person has no read state and is told so rather than answered with a list built for nobody'). It does not mention pagination ceilings beyond limit or performance/rate characteristics, keeping it short of a 5.

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?

Front-loaded with purpose, then the default-box behavior, then the box-less alternative – a sensible order. The first sentence is a long run-on enumerating returned fields, which is justified given there is no output schema, but it costs readability.

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?

Eleven optional parameters, two modes, and no output schema – the description compensates by describing the returned fields, the pagination cursor trick via updated_at, defaults, and null cases. An agent has everything needed to call this correctly and to know what it will get back.

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 prose adds real meaning beyond the schema: it explains the box/folder/unread interaction as a single viewing mode versus the status-driven account mode, and it frames waiting_since/last_reply_at as the pair a helpdesk queue is watched by. That context is not derivable from the individual property descriptions alone.

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?

Opens with a specific verb and resource ('Lists threads, most recently updated first') and enumerates the shape of what comes back. It separates the two listing modes clearly, though it never names the closest sibling (search_conversations) so the agent must infer that this is the browse-all tool.

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 states the when-and-how: name a 'box' to read one mailbox screen-by-screen, omit it to read the whole account by pipeline status, and explains why these are different questions ('a thread sitting unread in a mailbox has a status like any other'). It also names the helper tools for finding inputs (list_sender_addresses, list_teams, list_brands, list_folders, list_people) and flags mutual exclusions with 'box'.

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