Skip to main content
Glama

List threads

threads_list
Read-onlyIdempotent

List threads

Threads in inbox order, filtered by folder and by contact CRM state.

Input Schema

NameRequiredDescriptionDefault
qNoSearches profile display names, usernames and the activity preview. Results follow `order`, not relevance.
tagNoThreads whose contact has one of these tags. Repeat the key to match any of several.
limitNoPage size, from 1 to 100. Defaults to 50.
orderNoSort direction by inbox order: `activity.at`, or `createdAt` for a thread with no activity. A reminder or an accepted message request moves a thread up until its next message, without changing `activity.at`. Defaults to `desc`, newest first.
cursorNoThe previous page's `nextCursor`. Opaque, and valid only with the filters it was issued for.
expandNoRelated resources to embed next to their ID field, one path per key, at most 4.
folderNoDefaults to `inbox`, threads that are neither archived nor requests. `noReply` is the `inbox` threads whose latest activity is inbound. `requests` holds unarchived threads where `isRequest` is true. `archived` includes requests. `all` spans every folder. Every other filter narrows the folder.
statusNoThreads whose contact has one of these statuses. Repeat the key to match any of several.
platformNoRepeat the key to match any of several.
contactIdNoThreads with these contacts. With `accountLinkId`, finds the thread between an account and a contact. Repeat the key to match any of several.
assigneeIdNoThreads whose `assigneeId`, the thread's own assignee or else its contact's, is one of these members. Repeat the key to match any of several.
campaignIdNoThreads these campaigns sent a message in. Campaign sends archive the thread, so pair it with `folder=archived` or `all`. Repeat the key to match any of several.
unassignedNo`true` keeps threads with no assignee, including through their contact. Not combinable with `assigneeId`.
accountLinkIdNoThreads of these account links. Repeat the key to match any of several.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / $defs / Platform / description
      Previous value: -"The platform. Every team can use twitter, linkedin; a team may have others enabled."New value: +"The platform. Every team can use twitter, linkedin, whatsapp; a team may have others enabled."
    • changedInput schema / $defs / Platform / examples
      Previous value: -[
      -  "twitter",
      -  "linkedin"
      -]New value: +[
      +  "twitter",
      +  "linkedin",
      +  "whatsapp"
      +]
  2. Changed2 schema fields changed
    • changedInput schema / $defs / Platform / description
      Previous value: -"The platform. Every team can use twitter; a team may have others enabled."New value: +"The platform. Every team can use twitter, linkedin; a team may have others enabled."
    • changedInput schema / $defs / Platform / examples
      Previous value: -[
      -  "twitter"
      -]New value: +[
      +  "twitter",
      +  "linkedin"
      +]
  3. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds 'inbox order' and scoping by folder/CRM state, but it omits pagination semantics and result shape; no contradiction.

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?

Two short sentences, front-loaded with the action and ordering; no filler.

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

Completeness3/5

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

For a 14-parameter list tool with no output schema, the description is quite sparse; it does not explain pagination, filter interactions, or default behavior. Rich schema and annotations compensate, but the description itself is only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema documents all 14 params, including folder, cursor, and expand. The description only generically mentions folder and CRM state and adds no parameter-level meaning beyond the schema.

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?

The description uses 'List' with 'threads' and specifies inbox ordering plus folder/CRM-state filtering, so the operation is identifiable. It does not explicitly differentiate from siblings such as threads_get or messages_list, so it falls short of a 5.

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?

The phrase 'filtered by folder and by contact CRM state' implies when this tool is useful—when browsing or filtering threads—but no explicit when-to-use, when-not, or alternative (e.g., threads_get or messages_list) is provided.

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