Loading ToolBench
Telegram Bot API Rich Message integration for MCP hosts. Provides tools to send formatted messages, edit messages, manage stickers, and handle interactive button-based choice questions via Telegram.
Server has 6 tools with schemas and descriptions present, but quality is significantly below production baseline. Descriptions are in Chinese and often vague/colloquial (e.g., 'tg_rich_send': '发一条正式富消息…' lacks clarity on what 'rich message' means to an LLM). Parameter descriptions exist but are minimal (avg ~40 chars vs baseline 72). No output schemas documented. Parameters lack type constraints (enums, ranges). Error handling is present in code (secret_redaction.py, tg_ask.py) but not surfaced in tool definitions. Tool names are verb-prefixed (good), but descriptions don't explain WHEN to use each tool vs alternatives (e.g., send vs edit vs draft). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Composition is reasonable (6 focused tools), but parameter relationships undocumented (e.g., 'blocks' vs 'markdown' vs 'html', which takes precedence?).
发带按钮的选择题并同步等答案——对方点哪个，工具就返回哪个。⚠️ 实验性；需要专用 bot（getUpdates 独占）
推一帧流式草稿（30 秒临时预览，私聊限定，不进聊天记录）。⚠️ 草稿活跃期间会锁死 Telegram Android 的发送框
原地改一条已发出的富消息——持久进度窗靠它，不受草稿 30 秒限制、留在聊天记录里、编辑不响铃
发一条正式富消息（进聊天记录，永久保留），返回 message_id；markdown 正文里的（emoji）标记会剥成真贴纸（库非空时）
收到的贴纸下载归档→看图起标题配标签→认领入库（贴纸车道见 COOKBOOK）
从贴纸库挑一张真贴纸直发（emoji 交集 / id / query；无参＝馆藏清单）
Descriptions are in Chinese and lack LLM-optimized English clarity. 'tg_rich_send' description ('发一条正式富消息…') does not explain what 'rich message' means, when to use it vs edit/draft, or what it returns. Baseline: descriptions should be 50 - 200 chars in clear English.
No output schemas documented. LLMs cannot plan downstream calls or extract return values. E.g., 'tg_rich_send' returns 'message_id' but schema is not declared, LLM must guess the field name and type.
Parameter relationships undocumented. 'tg_rich_send' accepts 'markdown', 'html', and 'blocks', which takes precedence? Are they mutually exclusive? LLMs will pass multiple formats, causing ambiguous behavior.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). 'tg_rich_send', 'tg_rich_edit', 'tg_sticker_send', 'tg_ask_choice' are all destructive (write to Telegram), but LLM cannot infer this from definitions. Agents cannot reason about side effects or retry safety.
'tg_ask_choice' has complex parameter constraints (layout enum, timeout range 0 - 3600, columns 1 - 5) documented in code but NOT in parameter descriptions. LLMs cannot see these constraints and will pass invalid values.