qq-mcp-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QQ_BOT_APPID | No | The AppID of your QQ official bot, obtained from the QQ Open Platform (bot.q.qq.com/open). Equivalent to the "appId" field of the config file. | |
| QQ_CONFIG_FILE | No | Path to the config file (JSON) containing appId, clientSecret, appToken, and apiBase. Read order: QQ_CONFIG_FILE, then config.local.json in the package root, then %USERPROFILE%\.qq-mcp-bridge\config.local.json. This is the most reliable way to provide credentials, since DSH strips parent environment variables containing SECRET/TOKEN when launching the MCP subprocess. | |
| QQ_BOT_APP_TOKEN | No | Optional AppToken for the QQ official bot. Equivalent to the "appToken" field of the config file; may be left empty. | |
| QQ_BOT_CLIENT_SECRET | No | The ClientSecret of your QQ official bot (used for WebSocket authentication; this is not your QQ password). Equivalent to the "clientSecret" field of the config file. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_private_messageA | 向指定 QQ 用户发送单聊消息。既可用于被动回复（传入刚才收到的 msg_id），也可用于主动推送（不传 msg_id，例如任务完成或定时提醒）。user_openid 与 msg_id 都来自 fetch_messages 或 bot_info 的返回值。 |
| fetch_messagesA | 取出 QQ 用户发给机器人的待处理单聊消息。消息由后台 WebSocket 网关接收并排队，本工具只读取队列。队列为空是正常情况，说明当前没有新消息。 |
| bot_infoA | 查询 QQ 机器人自身信息与桥接状态：机器人身份、是否处于 mock 模式、网关连接状态、待处理消息条数。用于排查配置问题。 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools cover three clearly distinct roles: sending a message, draining the inbound message queue, and inspecting bot/bridge status. There is no plausible way to confuse send_private_message with fetch_messages or bot_info, and the descriptions reinforce the send/receive/observe split.
send_private_message and fetch_messages both follow a consistent snake_case verb_noun pattern and pair naturally as outbound/inbound counterparts. bot_info breaks the pattern by using a bare noun with no verb, which is a minor deviation but a readable one.
Three tools is lean but appropriate for a thin WebSocket-to-MCP bridge whose job is just relay plus status. The surface is not padded, though it sits near the lower bound where an agent might want one or two more capabilities.
The core poll-then-reply loop is covered, but the surface stops at private chat: there is no group/conversation messaging, no media or non-text sending, no history or message-lookup beyond the live queue, and no acknowledgement semantics for processed messages. These are notable gaps for a general QQ bot bridge even if private-only was intentional.