Skip to main content
Glama
uk-kd

operbots-mcp

by uk-kd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Список диалогов

dialogs_list
Read-onlyIdempotent

List bot conversations with filters by bot, chat type, mode, and text. Shows unread messages and operator-handled chats, including communities, groups, and channels.

Instructions

Переписки ботов дела с отбором по боту, виду чата, режиму и подстроке. Показывает, где есть непрочитанное и какие диалоги ведёт оператор. Сообщества — группы и каналы, где состоит бот, — это те же диалоги с kind=community; в панели они в разделе «Сообщества».

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
botNoОтобрать по боту: название, @username или идентификатор.
caseNoДело: название или идентификатор. Если не указать, берётся дело по умолчанию, иначе последнее открытое в панели.
kindNoВид чата: private — личная переписка, community — все сообщества, group — только группы, channel — только каналы. Без него — всё вместе.
modeNobot — ведёт сценарий; operator — перехвачен человеком.
limitNoСколько записей вернуть, максимум 200. По умолчанию 40.
queryNoПоиск по имени, нику и последнему сообщению.
offsetNoСколько записей пропустить.
only_unreadNoТолько с непрочитанными сообщениями.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.17
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "Вид чата: private — личная переписка, community — все сообщества, group — только группы, channel — только каналы. Без него — всё вместе.",
+  "enum": [
+    "private",
+    "community",
+    "group",
+    "channel"
+  ],
+  "type": "string"
+}
  2. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

The description adds behavioral context beyond the annotations: it reveals that the result shows unread status and operator-led dialogs, and clarifies that communities are represented as the same dialog entities with kind=community. This aligns with readOnlyHint=true, openWorldHint=true, and idempotentHint=true, with 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The core filtering purpose is front-loaded, and the community clarification earns its place because it is a non-obvious semantic rule. The UI section mention is minor but adds practical orientation.

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

Completeness4/5

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

For a list operation, the description plus a fully documented parameter schema and read-only/idempotent annotations cover the main behaviors, filters, and community semantics. It does not specify the full return shape or sorting order, but it gives enough hints about unread and operator fields to be workable.

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 description adds meaning by explaining that groups and channels are the same dialog objects as communities and that filtering can be done by substring. This clarifies the intent behind the kind and query parameters beyond the raw schema 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 clearly identifies the resource ('Переписки ботов дела') and the action (list dialogs with filtering by bot, chat kind, mode, and substring). It also explains that communities are the same dialogs with kind=community. However, it does not explicitly differentiate this tool from sibling dialogs_get, dialogs_history, or dialogs_export.

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 description makes the primary use case obvious: retrieving and filtering case dialogs, including unread and operator-handled conversations. It gives useful context about community/group/channel semantics, but it never says when to prefer this tool over alternative dialog tools or when not to use it.

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

Deploy Server

Other Tools