Loading ToolBench
QQ Bot MCP defines 7 tools with basic structure, but exhibits significant gaps in parameter schema completeness, output documentation, and error handling guidance. Tool names follow verb conventions (e.g., qqbot_status, qqbot_reply_event), and descriptions exist for all tools. However, most parameters lack type definitions in visible schema, output structures are undocumented, and error recovery guidance is absent. The codebase shows tool registration via FastMCP decorators with inline parameter definitions, but these are inferred from Python function signatures rather than explicit JSON Schema declarations visible in the source. Per-tool assessment reveals inconsistent schema quality: reply_event has reasonable parameter coverage; wait_event and list_* tools have minimal schema documentation. No security checks, input validation, or error classification patterns visible.
查询 QQ Bot 支持的消息类型、场景、交互方式及平台限制说明
丢弃指定的消息事件，不做任何回复
列出最近收到的历史消息记录
列出当前待处理的消息事件（尚未回复或丢弃的消息）
回复指定的消息事件。支持纯文本、图片URL、Markdown、Ark、Embed 等消息类型。频道/私信场景直接传 content/image 等参数；群聊/C2C 场景需设置 msg_type（0文本 1图文 2markdown 3ark 4embed 7media）
获取 QQ Bot 当前运行状态，包括是否在线、待处理消息数、总接收消息数
阻塞等待新的消息事件到达，超时后返回空结果。事件中包含 content（文本）和 attachments（附件列表）
Output schemas not documented. No return type declarations visible for any tool. LLMs cannot plan downstream tool calls or extract data from responses without documented output structure.
Input parameter schema completeness inconsistent. qqbot_list_pending and qqbot_list_history document 'limit' parameter with type and description; qqbot_status has no parameters documented; qqbot_wait_event timeout_seconds lacks explicit min/max bounds. Python function signatures inferred rather than explicit JSON Schema visible.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
qqbot_reply_event accepts many optional parameters (markdown, ark, embed, media, keyboard) but lacks validation logic or mutual exclusivity constraints documented. At-least-one-required check exists in code ('if not kwargs'), but error message is only returned to function output, not surfaced as validation constraint. LLM cannot infer which parameter combinations are valid.
No error recovery guidance. Tools return bare dict/list results on success (e.g., 'await runtime.status()' returns dict, 'await runtime.hub.list_pending(limit)' returns list) with no error structure defined. Failure modes and actionable recovery steps not documented. LLM cannot distinguish success from failure or determine retry strategy.
No permission gates or security audit trails visible. qqbot_reply_event and qqbot_discard_event are write operations (WRITE risk) with no permission check before execution. No logging of who called which tool or when. Sensitive state changes not gated.
List tools (qqbot_list_pending, qqbot_list_history) lack pagination metadata. No total_count, next_cursor, or has_more returned. Default limit=20 hardcoded with no min/max bounds documented. Large result sets could blow context window with no guidance.
qqbot_reply_event description mentions 'msg_type codes' but uses Chinese labels ('文本', '图文混排') in description. Enum values not formally declared in schema; LLM must infer valid codes (0-7) from free-text description.
qqbot_wait_event blocks caller with no timeout context. 'timeout_seconds' parameter default=15, but no documentation of what happens on timeout (e.g., 'returns empty dict', 'raises exception', 'returns null'). Blocking operations need explicit timeout contracts.
qqbot_capabilities returns a hardcoded dict; not a discovery tool that queries actual bot state. If QQ Bot is offline or capabilities change, stale data returned. Capability querying should query runtime, not return static definition.