Retrieve and list marketplace chat conversations, enrich them with recent messages, and sort by latest activity to track buyer or seller discussions.
会话列表：HTTP + 默认短时 WS 发现，最近消息补齐并按活动时间倒序
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | ||
| fetch_num | No | ||
| watch_secs | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.5.3Input schema / properties / timeoutAdded value: +{
+ "default": 30,
+ "title": "Timeout",
+ "type": "number"
+}Input schema / properties / watch_secs / defaultPrevious value: -0New value: +5v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose non-obvious behavior beyond the schema — that the call touches HTTP and briefly opens a WebSocket by default, and that recent messages are backfilled (implying extra network work and latency). However it says nothing about permissions, rate limits, blocking duration, or whether the WS phase can be suppressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single tight line with the resource front-loaded, so there is no wasted text. The density borders on cryptic, but every clause carries information about mechanics and ordering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but the rest is thin: three undocumented parameters, no annotations, no guidance on choosing this over message_history or message_watch, and no statement of what the WS discovery phase costs or requires.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters (timeout, fetch_num, watch_secs) whose names alone are ambiguous. The phrase 短时 WS 发现 hints at the short watch window but never maps to watch_secs, and timeout and fetch_num are entirely unaddressed, so the description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and action (会话列表 = chat list) and adds scope detail: discovery over HTTP plus a default short-lived WebSocket, recent-message backfill, and activity-time descending order. That is clear enough for an agent to know what it returns, though it never distinguishes itself explicitly from siblings like message_history or message_watch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. An agent choosing between message_list_chats, message_history, and message_watch gets nothing beyond an implicit hint from the mention of a short WS discovery phase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.