Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@QQ MCP Check QQ status and show recent messages from allowed groups."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Independent, local stdio MCP server supporting both official QQ bots and personal QQ accounts through NapCat / OneBot v11. MIT licensed. This is an initial implementation with mocked protocol tests; live account acceptance is still required before production use.
Capability | Official bot | Personal account (NapCat) |
Account/status probe | Access-token exchange and bot profile | Login identity and OneBot status |
Targets | Explicit configured bot-scoped open IDs | Allowlisted subset of friend/group lists |
Context | Signed webhook messages received since setup | Bounded on-demand NapCat history extension |
Send | Plain-text reply to a received group/C2C message | Plain-text message to an allowlisted group/friend |
Authentication | App ID + AppSecret; Ed25519 inbound verification | Bearer access token; loopback HTTP or explicit HTTPS remote |
The official bot is a separate identity: it cannot read your personal account's past conversations. Official group IDs and user IDs are bot-scoped open IDs, not ordinary QQ numbers. NapCat is an unofficial personal-account bridge that you install and operate separately. Its history is not guaranteed complete and depends on the QQ client/session.
Related MCP server: NapCat MCP Server
Python 3.11 or newer and uv are required for the commands below.
git clone https://github.com/BK927/qq-mcp.git
cd qq-mcp
uv sync --frozen --extra dev
uv run qq-mcp --helpUse uv sync --frozen --no-dev for runtime installation (the dev extra is only included with --extra dev). The checked-in uv.lock pins the resolved dependency set. pip install . also works, but does not consume this lockfile.
Copy .env.example to .env, edit the values locally, and start with uv run --env-file .env qq-mcp. Environment files are never loaded implicitly; --env-file is a uv option. Never put credentials in tool arguments, prompts, Git, or screenshots.
Example MCP client configuration (replace the directory; set environment through your client or secure launcher):
{
"mcpServers": {
"qq": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/qq-mcp", "--env-file", "/absolute/path/qq-mcp/.env", "qq-mcp"]
}
}
}Windows directory values can use D:/repo/qq-mcp. Both providers can be enabled in the same instance. Keep the same absolute QQ_STATE_PATH for the MCP process and webhook process. Run one webhook worker; SQLite coordinates the separate MCP and webhook processes.
Register your own bot in QQ Open Platform. Enable the required group/C2C capabilities and obtain AppID/AppSecret. This repository does not register bots or obtain permissions for you.
Set QQ_ENABLE_OFFICIAL=true, QQ_APP_ID, QQ_APP_SECRET, QQ_OFFICIAL_GROUPS, and/or QQ_OFFICIAL_USERS. Empty lists grant no conversation access. Obtain bot-scoped IDs from your trusted QQ developer integration; this server deliberately does not enumerate unsolicited events from all chats to discover IDs.
Run uv run --env-file .env qq-mcp webhook. It binds 127.0.0.1 only, on QQ_WEBHOOK_PORT (8787 by default), and serves /qq/webhook.
Place an HTTPS reverse proxy in front of that endpoint and configure its public URL in QQ's callback settings. Forward the raw body and X-Bot-Appid, X-Signature-Ed25519, X-Signature-Timestamp unchanged. QQ currently permits public callback ports 80, 443, 8080, and 8443. Configure proxy body and rate limits too.
Subscribe to C2C_MESSAGE_CREATE, GROUP_AT_MESSAGE_CREATE, and/or GROUP_MESSAGE_CREATE as your bot's permission scope permits. The receiver handles the official unsigned op:13 URL challenge separately, verifies signatures and timestamp freshness for all ordinary events, drops conversations outside the allowlist, and acknowledges with op:12.
Run the MCP process, call qq_status with probe=true, and inspect qq_context after a user messages the bot in an allowed conversation.
Official sends require reply_to identifying a message already received through the signed webhook for that target. The server advances msg_seq for multiple replies. QQ enforces permissions, message quotas and reply windows; their current documentation has conflicting C2C window values, so this project does not promise a fixed window. No proactive official messaging, media uploads, guild administration, or personal-account history is claimed by this version.
Install NapCatQQ, sign in locally, and enable its OneBot v11 HTTP server. Set a strong access token in NapCat. This project does not install NapCat, manage QR login, or extract session credentials.
Set QQ_ENABLE_PERSONAL=true, QQ_NAPCAT_URL=http://127.0.0.1:3000, and QQ_NAPCAT_TOKEN to the same token. The port is whatever you configured in NapCat.
Add numeric QQ group IDs to QQ_PERSONAL_GROUPS and numeric friend QQ IDs to QQ_PERSONAL_USERS. Unlisted conversations are rejected. There is no wildcard or automatic monitoring of every chat.
Call qq_status, qq_targets, and qq_context. Context fetches at most 100 messages per call using NapCat's get_group_msg_history / get_friend_msg_history extension. This is an on-demand snapshot, not a realtime listener. Unsupported extensions fail explicitly.
Remote NapCat requires both QQ_ALLOW_REMOTE_NAPCAT=true and HTTPS with a valid certificate. Loopback must be a literal address (127.0.0.1 or [::1]), preventing hostname rebinding. TLS verification cannot be disabled. Redirects, ambient proxy settings, raw arbitrary API calls, credential-fetching endpoints, moderation and account actions are not exposed.
qq_status(probe=false): configuration and provider capability status; probe=true makes read-only authentication/status requests.
qq_targets(provider, kind): configured official targets or the allowlisted personal target list.
qq_context(provider, kind, target, limit=20, message_cursor="", reverse_order=false): bounded context, labelled as untrusted chat content. Personal history accepts a returned message_id as message_cursor (including negative IDs); direction and available history depend on NapCat. There is no promise of complete or gap-free pagination.
qq_send(provider, kind, target, text, idempotency_key, reply_to=""): explicit plain-text send; requires QQ_ENABLE_SEND=true.
qq_forget(provider, kind, target): delete that target's locally retained webhook context; does not delete upstream messages or the send ledger.
Sending is disabled by default. Enabling it is an operator decision; the MCP host must also obtain the user's intent to send the exact text to the exact recipient. Incoming chat text is untrusted data and must never authorize another tool call. No send happens on startup or from webhook receipt.
Use a unique idempotency_key for each intentional message and reuse that exact key when retrying the same request. A SQLite reservation is committed before dispatch. Successful repeats return the saved message ID. Failed, timed-out or interrupted dispatches remain unknown and are not resent automatically. Check delivery manually before using a new key. Guarantees apply to this shared database for seven days; separate databases or keys do not deduplicate each other. The ledger stores a payload hash and bounded result, not the message text. It rejects new sends if its 10,000-entry limit is reached until entries expire. Official reply sequence tracking is retained for 24 hours.
Official webhook context is stored locally for up to 24 hours and 2,000 messages by default (QQ_RETENTION_SECONDS, maximum seven days; QQ_MAX_MESSAGES, maximum 10,000). Messages are limited to 8,000 characters. Personal history is returned on demand and is not persisted by this server. The MCP host may keep its own conversation logs. Names and messages in every result are untrusted content.
The default SQLite path is ~/.local/share/qq-mcp/state.sqlite3; prefer an explicit absolute path. Protect the containing directory with operating-system permissions. On POSIX, the database file is set to mode 0600; on Windows, restrict its directory's ACL to your user. SQLite WAL and filesystem snapshots can retain deleted bytes; forgetting is logical deletion, not guaranteed forensic erasure. Stop both processes and securely remove the database directory if you need to retire all state. Retention cleanup runs on reads/writes and periodically while either process runs.
All outbound requests have finite timeouts and 1 MiB response limits. Webhook bodies are limited to 256 KiB. HTTP redirects and automatic mutation retries are disabled. Errors do not return credentials, raw provider responses or request bodies. The server does not log chat text. Keep your machine clock synchronized for the five-minute webhook replay window.
uv sync --frozen --extra dev
uv run pytest
uv run ruff check .Tests use mock HTTP transports and signed synthetic events, not user accounts. They cover denied scopes, token reuse, send payloads and idempotency, timeout/unknown sends, webhook signatures/challenges, replay/tamper rejection, bounded retention, and MCP tool discovery. Real QQ developer approval, live callback delivery, platform quotas, and NapCat compatibility must be checked in your own staging accounts. No live message has been sent as part of repository validation.
Verified against these sources on 2026-09-17:
공식 QQ 봇과 개인 QQ 계정(NapCat)을 둘 다 지원합니다. 하나의 MCP 인스턴스에서 함께 켤 수 있습니다. 공식 봇은 별도 봇 계정이며 개인 계정의 기존 대화를 읽을 수 없습니다. 개인 계정은 사용자가 설치하고 로그인한 NapCat에 연결합니다.
uv sync --frozen --extra dev로 설치하고 .env.example을 .env로 복사합니다.
공식 봇은 QQ_ENABLE_OFFICIAL=true, AppID/AppSecret, 허용할 봇 전용 그룹/사용자 open ID를 설정합니다. uv run --env-file .env qq-mcp webhook을 별도로 실행하고 HTTPS 프록시를 통해 QQ 콜백을 연결합니다.
개인 계정은 QQ_ENABLE_PERSONAL=true, NapCat 주소·토큰, 허용할 숫자 QQ 그룹/친구 ID를 설정합니다.
uv run --env-file .env qq-mcp를 MCP 클라이언트의 로컬 서버로 등록합니다. 웹훅과 MCP는 같은 QQ_STATE_PATH를 사용해야 합니다.
qq_status, qq_targets, qq_context로 상태와 허용된 대화를 확인합니다. 빈 허용 목록은 모든 대화를 차단합니다.
발송은 기본적으로 꺼져 있습니다. QQ_ENABLE_SEND=true 설정 후에도 대상·본문·중복 방지 키를 명시해야 합니다. 공식 봇은 서명 검증된 수신 메시지의 reply_to로만 답장합니다. 재시도 시 같은 idempotency_key를 사용하세요. 결과가 unknown이면 전달 여부를 먼저 확인하고 새 키를 발급해야 합니다. 웹훅 수신만으로 자동 발송하지 않습니다.
공식 봇 수신 기록은 기본 24시간/2,000개만 로컬에 보관합니다. 개인 계정 기록은 필요한 대상에 대해 최대 100개씩 조회하며 이 서버에 저장하지 않습니다. NapCat의 기록이 전체 과거 대화를 보장하지는 않습니다. 이 버전은 모의 API 및 서명 이벤트로 검증했으며, 실제 계정·권한·QQ 콜백·NapCat 버전별 실연동은 별도 확인이 필요합니다.
Read scoped context (untrusted). Official: retained verified events. Personal: on-demand NapCat history; message_cursor accepts a known returned message_id, with backend-dependent direction.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| limit | No | ||
| target | Yes | ||
| provider | Yes | ||
| reverse_order | No | ||
| message_cursor | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'untrusted' and explains that official data is retained verified events while personal is on-demand NapCat history, with cursor direction being backend-dependent. This goes beyond the annotations to clarify data freshness and reliability.
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?
The description is two sentences, front-loaded with the core purpose and provider distinctions. Every word adds value, with no redundancy or fluff.
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?
With 6 parameters, 0% schema description coverage, and an output schema that may clarify returns, the description covers the most important aspects (provider semantics and cursor behavior) but leaves other required parameters like target and optional parameters like limit and reverse_order without explanation. An agent might struggle to correctly populate all fields without additional context.
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 0%, so the description must compensate. It adds meaningful context for message_cursor (accepts known returned message_id, backend-dependent direction) and clarifies provider/kind semantics. However, it does not explain limit, target, or reverse_order, leaving those to schema defaults and enums. The description partially compensates but is incomplete for all parameters.
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?
The description clearly states the tool reads scoped context and explicitly distinguishes between official and personal providers, each with specific semantics. This makes the purpose unambiguous and differentiates it from sibling tools like qq_send or qq_status.
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?
The description implies when to use the tool (reading context) and explains the two provider modes, but does not explicitly state when to prefer this over alternatives or when not to use it. The guidance is indirect and leaves some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete locally retained incoming context for one allowed target; upstream chats stay intact.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| target | Yes | ||
| provider | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds that deletion is local-only and upstream chats stay intact, which is useful behavioral context beyond the annotations. However, it doesn't disclose what exactly gets destroyed (e.g., message history, cached context) or whether the operation is reversible. No contradiction with annotations.
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?
One sentence, front-loaded with the action and scope, and includes a clarifying clause about upstream chats. Every word earns its place; no fluff.
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?
The tool has 3 required parameters, no schema descriptions, and an output schema. The description explains the core behavior but leaves parameter semantics unexplained. Given the destructive nature and the need to select the right target, the description is not fully complete for an agent to invoke it correctly without additional inference.
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 0%, so the description must compensate for parameter meaning. The description mentions 'one allowed target' but does not explain what 'provider', 'kind', or 'target' mean or how they relate. The enums for kind and provider are in the schema, but the description adds no semantic value for these parameters.
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?
The description states a specific verb ('Delete') and resource ('locally retained incoming context for one allowed target'), and distinguishes it from upstream chats staying intact. It doesn't explicitly name sibling tools, but the scope is clear enough to differentiate from qq_send, qq_status, qq_targets, and qq_context.
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?
The description implies when to use it: when you need to delete locally retained incoming context for a target. It does not explicitly state when not to use it or mention alternatives like qq_context for viewing context. The 'upstream chats stay intact' clause gives some usage context but no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send explicitly requested plain text to an allowlisted target, if enabled. Use a unique key per intended send and reuse for retries; never retry unknown delivery with a new key without checking. Official replies need a retained received message's reply_to ID.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| text | Yes | ||
| target | Yes | ||
| provider | Yes | ||
| reply_to | No | ||
| idempotency_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-readonly, idempotent operation with open-world effects aid idempotency. The description adds meaningful behavior beyond this: allowlist enforcement, 'if enabled' gating, exact retry guidance, and the reply_to requirement for official replies. It does not contradict the annotations.
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?
Three sentences with no filler. The core purpose is front-loaded, and the retry and reply guidance are packed into terse, actionable clauses.
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 mutating send tool with an output schema and annotations, the description covers the most important operational nuance: idempotent retries and reply_to handling. It could add a little more about the allowlist/provider split, but it is largely complete for invoking the tool correctly.
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 0%, so the description must compensate. It explains idempotency_key semantics and reply_to usage, but it leaves provider, kind, and target largely to the enum values and titles in the schema. Partial compensation only, so a mid-range score is appropriate.
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?
The description opens with a specific verb and resource: 'Send explicitly requested plain text to an allowlisted target, if enabled.' This clearly distinguishes qq_send from its siblings (qq_status, qq_targets, qq_context, qq_forget), none of which perform sends.
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?
It conveys concrete usage constraints: use a unique key per intended send, reuse it for retries, and avoid retrying unknown deliveries with a new key. It also states that official replies require a retained received message's reply_to ID. It does not name alternatives, but the sibling tools do not appear to be sending alternatives, so this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show provider capabilities/scopes. probe=true checks upstream credentials and account status.
| Name | Required | Description | Default |
|---|---|---|---|
| probe | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnlyHint=true and openWorldHint=true, so the safety profile is established. The description adds useful behavioral context by explaining that probe=true checks upstream credentials and account status, which is beyond what annotations convey.
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?
Two short sentences with no filler. The core purpose is front-loaded)Skip
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?
The tool is simple: one optional boolean parameter confirmed by the input schema trick, an output schema exists, and annotations declare read-only safety. The description covers the main behavioral nuance, leaving little that an agent needs in order to invoke it correctly.
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 0%, but the description meaningfully explains the only parameter: 'probe=true checks upstream credentials and account status.' This adds value beyond the bare boolean field name and default value.
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?
The description states a clear verb-resource pair: 'Show provider capabilities/scopes.' This distinguishes it from sibling tools like qq_send or qq_forget, which clearly perform actions, though it is less explicit about how it differs from qq_targets and qq_context.
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?
The description provides no guidance on when to use this tool instead of its siblings. The probe=true note explains one behavioral aspect, but does not help an agent decide between qq_status and qq_targets/qq_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List only allowlisted official bot open IDs or visible NapCat friends/groups.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| provider | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds behavioral context by specifying 'only allowlisted' and 'visible', indicating filtering behavior. It doesn't describe side effects (none expected) or authentication, but for a read-only list tool this is sufficient. No contradiction with annotations.
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?
The description is a single concise sentence with no filler. It front-loads the action and clearly states the scope. Every word earns its place, and it avoids redundancy with the schema.
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?
The tool is simple with two enum parameters and an output schema (present but not shown). The description covers the core behavior—listing allowlisted/visible targets. It doesn't mention return format or error cases, but the output schema likely covers that. For a listing tool with such clear enums, this is adequate. A 5 would require more nuance, but a 4 is appropriate.
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 0%, so the description carries the burden. It mentions 'official' and 'personal' implicitly via 'official bot' and 'NapCat', and 'group' and 'user' via 'friends/groups'. However, it doesn't explicitly map the parameters or explain their meaning beyond the enum names. The enums themselves are self-explanatory (kind: group/user, provider: official/personal), but the description could have linked them more directly. It adds partial value but doesn't fully compensate for zero schema coverage.
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?
The description clearly states the verb 'List' and the resource: 'allowlisted official bot open IDs or visible NapCat friends/groups'. This is specific and distinguishes from siblings like qq_send (sending) or qq_status (status). The enums for provider and kind map directly to the two categories, making the purpose unambiguous.
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?
The description implies usage context: when you need to know available targets (allowlisted IDs or visible friends/groups). It doesn't explicitly mention alternatives or exclusions, but the sibling names (qq_status, qq_context, qq_send, qq_forget) make it clear this is the listing tool. The context is clear enough without explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0qq_contextqq_forgetqq_sendqq_statusqq_targetsScored across 5 tools
Each tool targets a distinct concern: status checks provider capabilities, targets lists allowed destinations, context reads scoped history, send transmits messages, and forget deletes retained context. There is no meaningful overlap between tool purposes.
All tools share a consistent qq_ prefix and lowercase snake_case style, making them recognizable as a set. The pattern mixes resource nouns (status, targets, context) with action verbs (send, forget), but the naming remains predictable and readable.
Five tools is a well-scoped count for a QQ MCP server covering capability checking, target discovery, context reading, sending, and local deletion. Each tool earns its place without redundancy or bloat.
The tool surface covers the core workflow of inspecting status, listing targets, reading context, sending messages, and forgetting local context. Minor gaps exist such as no explicit sent-message management or target modification, but these are likely outside the server's intended scope.
Telegram bridge for your MCP-compatible agent. Bidirectional, no LLM in our stack.
Drive WhatsApp from any MCP client: pair devices, send text and media, manage contacts and groups.
Synap (pool.linkrra.com/v1), Linkrra's OpenAI-compatible LLM API, as an MCP server.
Command your AI agents by voice: PTT rooms, channels, E2EE DMs, agent email, private recall.