qq-mcp-bridge
Related Servers
Alternatives to qq-mcp-bridge
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceEnables an AI agent to fetch queued OneBot v11 QQ private and group messages, retrieve inbound images for vision-capable models, and send text, images, or files with request-id deduplication. Also exposes acknowledgment, message history, conversation and contact listing, delivery status, and bridge health so agents can drive a persistent SQLite-backed QQ message loop.MIT
- FlicenseAqualityBmaintenanceEnables MCP hosts to bridge with QQ via NapCat/OneBot 11, allowing whitelisted private messages to reach an agent with full tool access while group mentions are answered by a sandboxed pure LLM without system access.8-
- AlicenseBqualityBmaintenanceConnects QQ via NapCat OneBot v11 to an Astral Code app-server, exposing MCP tools for sending messages, files, images, and fetching conversation history.101Apache 2.0
- 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
- 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
- AlicenseBqualityAmaintenanceEnables 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.743MIT
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.