Skip to main content
Glama

Inboxapp

by com.inboxapp.mcp
OverviewDiscussionsAdmin

List threads

threads_list
Read-onlyIdempotent

List threads

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

Input Schema

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

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about default inbox ordering and folder/CRM filtering, but it omits pagination behavior, return shape, and any auth or rate-limit notes.

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?

The description is short and front-loaded, with the core action stated first and the filtering/order context immediately after. The repeated first line "List threads" duplicates the title, so it does not fully earn its place, but there is no other excess wording.

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 very sparse. Annotations cover safety and the schema covers parameters, but the description does not mention pagination, default page size, cursor behavior, or the basic shape of the returned thread list, leaving it only minimally adequate.

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 14 parameters are already thoroughly documented in the schema. The description adds only "filtered by folder and by contact CRM state", which does not meaningfully expand on the schema's detailed folder, contactId, status, tag, and other filter descriptions.

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 states a specific verb and resource: "List threads", then adds scope with "Threads in inbox order, filtered by folder and by contact CRM state." This distinguishes it from thread mutation or single-thread tools like threads_get/update/delete, but it does not explicitly name or compare against any sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It implies that the tool is for listing threads with folder and CRM-state filters, but it never says when to choose threads_list over threads_get or messages_list.

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

All Inboxapp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources