Sends text, CQ-code, or message-segment messages to a specified QQ group through OneBot 11, with optional plain-text escaping for CQ content.
向指定 QQ 群发送群聊消息 (OneBot 11: send_group_msg)。 支持文本、CQ 码或 OneBot 消息段数组；纯文本 @全体成员 不会产生真实提醒。 :param group_id: 目标 QQ 群号 :param message: 要发送的群消息内容 :param auto_escape: 是否作为纯文本发送 (不解析 CQ 码)，默认 False
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | 要发送的群消息内容 | |
| group_id | Yes | 目标 QQ 群号 | |
| auto_escape | No | 是否作为纯文本发送 (不解析 CQ 码)，默认 False |
Changes observed during successful MCP inspections.
v1.1.0Input schema / additionalPropertiesAdded value: +falseInput schema / properties / message / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+]Input schema / properties / message / typeRemoved value: -"string"v1.0.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 one genuinely useful behavioral caveat — that a plain-text @全体成员 will not produce a real mention — and explains auto_escape's CQ-parsing effect. However, it says nothing about permission requirements, rate limits, failure modes, or what the call returns on success.
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?
Purpose is front-loaded in the first sentence, followed by the supported content formats and the @全体成员 caveat, then per-parameter notes. Efficient overall, though the trailing :param lines duplicate schema wording and add little.
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?
For a mutation tool with no annotations and no output schema, the definition should at least hint at success/failure behavior or required preconditions. It covers message format well but leaves the safety and response profile entirely undocumented.
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 100%, so the schema already documents all three parameters and the baseline is 3. The description largely repeats the same parameter text verbatim, adding only the clarification that message may be CQ code or an OneBot message-segment array, which is a marginal gain over the schema's anyOf string/array typing.
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?
States a specific verb and resource ('向指定 QQ 群发送群聊消息') plus the underlying OneBot action name send_group_msg, so its function is unmistakable. It does not explicitly name sibling alternatives such as send_private_msg or send_msg, so the agent must infer the group-vs-private routing from the name alone.
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?
Usage is implied by the scope (target a QQ group), but there is no explicit statement of when to prefer this over send_msg or send_group_forward_msg, nor any prerequisite such as the target group requiring membership or the bot being online.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.