QQbot-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QQBOT_APP_ID | Yes | QQ bot AppID from the QQ Open Platform robot development settings. | |
| QQBOT_MCP_QR | No | Set to "off" to skip displaying the QR code on startup, equivalent to --no-qr. | |
| QQBOT_MCP_MODE | No | MCP mode for the server; the README example uses "read". | |
| QQBOT_APP_SECRET | Yes | QQ bot AppSecret from the QQ Open Platform robot development settings. | |
| QQBOT_MCP_QR_URL | No | Custom invitation URL to use in the QR code instead of the default QQ bot creation/login entry. |
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_apisA | List QQ bot APIs from the local catalog (103 endpoints, 21 categories). Filter by category, keyword or read/write. This is the first call to discover what the bot can do. |
| get_apiA | Get the full documentation for one API: path/query/body schemas, response fields, error codes, rate limits and examples. Call this before invoke_api for non-trivial bodies. |
| search_apisA | Search APIs by Chinese/English keywords and return ranked matches with method, path and read-only flag. |
| list_categoriesA | List catalog categories with endpoint counts. |
| list_event_typesA | List QQ gateway/webhook event types (53), optionally filtered by intent or category. Use get_event_type for payload fields. |
| get_event_typeA | Get one event payload schema, required intents and examples (e.g. C2C_MESSAGE_CREATE, GROUP_AT_MESSAGE_CREATE). |
| bot_statusA | Show local runtime status: mode, credential/token presence (never the token), catalog version, event buffer, gateway/webhook state. Optionally probe QQ with get_gateway_bot. |
| query_apiA | Call a read-only QQ API (GET endpoints such as get_gateway_bot, list_groups, get_group_member). Read mode or higher. For writes use invoke_api. |
| poll_eventsA | Read buffered gateway/webhook events. Consumes returned events by default; pass peek=true to keep them. Requires event transport to be running. |
| wait_eventsA | Long-poll for new events (default 30s, max 5min). Returns buffered matches immediately, otherwise waits for a gateway/webhook event. Cancelled when the client aborts. |
| clear_eventsA | Drop all buffered events without stopping the transport. Useful after testing. |
| event_stream_statusA | Show event transport configuration plus gateway, webhook and buffer status. |
| download_attachmentB | Download an attachment URL (message image/file, media URL) into QQBOT_MCP_DOWNLOAD_DIR with size cap and SSRF guard. Returns a local path for further processing. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| QQ bot API catalog | All 103 curated QQ OpenAPI endpoints with method, path, read-only flag and category. |
| QQ bot event catalog | All 53 gateway/webhook event types with categories and required intents. |
| Recent buffered events | The last 50 events currently buffered by the event transport (peek, does not consume). |
| Runtime status | Mode, catalog version, token presence, event transport and buffer status. |
TDQS
Scored across 13 tools
Most tools have clearly distinct targets: catalog discovery (list_apis/get_api/search_apis/list_categories), event handling (poll_events/wait_events/get_event_type), and runtime status (bot_status/event_stream_status). The closest pair is poll_events vs wait_events, but descriptions clarify consume-vs-long-poll. A real ambiguity is introduced because query_api tells agents to 'use invoke_api' for writes, yet invoke_api is not in the set.
All names are snake_case and most follow a verb_noun pattern (query_api, list_apis, get_api, search_apis, poll_events, wait_events, download_attachment, clear_events). The two status tools (bot_status, event_stream_status) are noun-only, a minor but consistent deviation for state-readers.
13 tools is a reasonable scope for a catalog-plus-event-transport gateway server covering 103 endpoints and 53 event types. It is slightly heavy on event tools (six of thirteen), and the four catalog lookups (list_apis, search_apis, list_categories, get_api) border on redundant, but each earns a place.
The surface is read-only: query_api exists for GET calls and explicitly defers writes to invoke_api, which is absent, so the documented write path is a dead end. There is also no direct send-message or event-acknowledgement operation, leaving a major lifecycle gap for a bot API server.