QQbot-MCP
Related Servers
Alternatives to QQbot-MCP
No user-submitted related servers found.
Related Servers
- AlicenseAqualityAmaintenanceEnables AI agents to control and monitor QQ accounts through the NapCatQQ OneBot 11 protocol, covering private/group messaging, forwards, group administration, file transfer, OCR, friend and profile management, and real-time message listening. It also handles QR-code login, hot-switching between multiple QQ accounts, and one-click self-check, deployment, and updates.206MIT
- AlicenseAqualityCmaintenanceExposes NapCat/OneBot v11 QQ-bot APIs as MCP tools for any MCP client, and includes an LLM-driven QQ bot with memory, knowledge base, tool calling, web search, multimodal recognition, and permission controls.45MIT
- AlicenseNot gradedqualityDmaintenanceA MCP server that exposes QQ bot capabilities over Streamable HTTP, enabling clients to query bot status, read group and friend info, fetch chat history, and send group/private text messages.3MIT
- AlicenseAqualityCmaintenanceAn MCP server that enables AI clients to send and receive QQ messages through NapCatQQ (OneBot v11) for both private and group chats. It supports message context management, real-time WebSocket listening, and human-like typing simulation.726MIT
- AlicenseAqualityCmaintenanceEnables interaction with QQ through official bot APIs or personal accounts bridged via NapCat/OneBot v11, including status checks, target listing, bounded context retrieval, and plain-text sending to allowlisted conversations.5MIT
- AlicenseNot gradedqualityBmaintenanceA QQ toolbox MCP server that lets an agent manage Qzone posts (publish, list, like, comment, delete, set visibility), friend feeds, visitors, confession-wall submissions and scheduled posts, while also editing the bot's profile (avatar, nickname, signature, online status, status lookup) via OneBot/SnowLuma. It additionally sends images and text-to-speech voice clips into private or group chats and manages tool whitelists.1MIT
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.