Enables interaction with Linux native WeChat, providing tools for searching contacts and groups, querying bounded chat history, sending private and group text messages, managing shared service lifecycle, and deduplicating sends. Planned capabilities include media messages, contact management, group management, Moments, and UI screenshots.
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., "@weskill 查找测试群，然后发送：会议改到下午三点"
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.
weSkill 让 Agent 直接操作 Linux 原生微信：查找联系人、理解聊天记录、发送消息与文件、管理好友和群聊、使用表情、读写朋友圈。一个总入口、五个协作 Skill、32 个 MCP 工具，让多步任务自然衔接。
底层通过原生调用执行，不抢鼠标、不占键盘焦点、不切换窗口。各个 Skill 复用本机服务与原生连接，服务空闲一小时自动退出，再次调用自动启动。原生操作统一串行，结束后持锁随机冷却 1–3 秒，再允许下一次操作；同时共享每用户任意连续 60 秒最多 20 次的提交额度，分页逐次计入，超出时等待；条数仍由调用方选择。
项目采用 REA（Reverse Engineer Anything） 工作流逆向 Linux 微信，将 ELF 静态分析与 Frida 动态验证所得的原生能力封装成 MCP，再由 Skill 编排任务。
把项目介绍和这张图片发给我指定的联系人，再整理最近 5 条聊天记录。
在指定群发布公告，@两位成员，并把指定消息置顶。
找一个开心的表情发给指定好友，再把这张图发为仅自己可见的朋友圈。
Skill | 职责 |
| 总入口、完整能力目录、搜索、历史与普通消息/媒体 |
| 好友资料、备注、添加好友与申请处理 |
| 群成员、建群、邀请、管理设置与群协作 |
| 系统表情、个人收藏与在线搜索表情 |
| 朋友圈时间线、个人动态与文字/图片发布 |
Related MCP server: mcp-wechat-server
联系人与群搜索：按关键词、自定义条数和排序查找，支持只搜索群。search_contacts
聊天历史：批量读取会话，默认 20 条；自定义条数，或用 0 / null 读取全部本机可读记录；可返回原始 XML。get_messages
私聊与群聊文本：共用原生发送接口。send_text_message
本地图片与文件：按本机路径发送到好友或群。send_image / send_file
客户端与能力识别：读取 ELF 架构、SHA-256、Build ID 和当前会话可用能力。get_client_identity / get_capabilities
共享服务：启动、续期、查看状态或在空闲时停止。ensure_service / get_service_status / stop_service
好友与群成员资料：读取本地可用昵称、微信号、备注、签名、地区、头像、电话列表、标签与来源。get_friend_info
修改备注：设置或清空好友备注。set_contact_remark
搜索新联系人：使用原生网络搜索获取添加对象。search_new_contact
主动添加好友：指定验证文字和备注。add_friend
查看好友申请：分页或全量读取，区分申请方向与当前联系人关系。list_friend_requests
接受好友申请：使用申请记录处理指定请求。accept_friend_request
群资料与成员：查询公告、邀请确认状态、成员角色、群昵称及可用好友资料。get_group_info / get_group_members
发起群聊：用指定好友创建群聊并设置名称。create_group
邀请入群：向指定好友发起群聊邀请。invite_group_members
移出成员：群主或管理员移出指定成员，提交前刷新本人角色。remove_group_members
真实 @：向指定成员、多个成员或全体成员发送带原生提及元数据的消息。send_group_mention
群公告：发布、编辑或清空完整纯文本公告。set_group_announcement
消息置顶：按服务器消息 ID 置顶或取消。pin_group_message
邀请确认：开关“入群需要群主或管理员同意”。set_group_invitation_confirmation
系统表情：发现客户端识别的表情代码，通过文本接口发送。list_system_emojis / send_text_message
个人收藏：浏览收藏表情并选择素材。list_saved_stickers
在线搜索：按关键词搜索，支持分页续读。search_stickers
发送自定义表情 / GIF：复用微信原生下载与发送链路。send_sticker
读取动态：时间线、指定联系人的个人动态、游标分页与置顶内容。get_moments
发表动态：纯文字或本机图片，明确指定公开或仅自己可见。publish_moments
工具参数与返回值见 工具参考，真实客户端验证范围见 能力说明。
推荐通过 npm 安装，一份包包含 CLI、五个 Skill 和 Python 原生执行层。准备 Node.js 22+、Python 3.12+（含 venv）与 GCC。原生操作适配 Linux ARM64、微信 4.1.13.26 的指定构建；本机微信位于 /opt/wechat/wechat 并已登录。构建识别方式见 兼容性说明。
npm install -g weskill
weskill setupsetup 在用户目录创建独立 Python 环境、安装依赖并编译原生桥，不连接微信、不发送消息。
weskill install codex自动注册本机 MCP，并安装五个 Codex Skill。
weskill install claude自动以用户范围注册 stdio MCP，并安装五个 Claude Skill。
支持本机 stdio MCP 的平台可直接使用执行层：
weskill config将输出中的 command 和 args 按宿主格式填入 MCP 配置。输出使用绝对路径，方便图形界面启动。支持 SKILL.md 的平台还可安装操作流程：
weskill skills --dir /path/to/agent/skills新开会话或重新连接 MCP，再调用 $weskill 或直接描述微信任务。原生模式提供 32 个工具；Agent 平台支持与微信原生构建适配是两个独立条件。详细安装、npx 接入与源码开发见 安装指南。
客户端返回 client_success 即按发送成功处理，结果未知时不自动重发。npm 安装的运行与幂等记录保存在用户数据目录，升级包时保留；服务管理和路径选项见 安装指南。
we-Agent 是基于 weSkill 的 Agent 流程管理项目，面向常驻响应、流程编排、知识库与行为控制。
如何探索与构建原生工具：从入口线索、ABI 和线程到回调生命周期、幂等与测试。
.venv/bin/python -m unittest discover -s tests -v
.venv/bin/python scripts/check_release.py原始研究、帐号数据与实验报告保留在本地忽略目录。工具使用本机 stdio 和同用户 Unix socket；查询结果会交给调用它的 AI 客户端。weSkill 是采用 MIT License 的非官方项目，与腾讯、微信、OpenAI 或 Anthropic 无隶属关系。
REA · Frida · MCP Python SDK · Pillow · OpenAI 插件规范 · Claude Code 插件规范。协议字段研究的更多参考见 开发指南。
觉得有用，欢迎给 weSkill 点一颗 Star ⭐，也欢迎贡献新能力、兼容适配与使用反馈。
Return verified/experimental/planned features and the tools available in this session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing the status taxonomy of the returned features (verified/experimental/planned), which tells the agent what kind of data to expect.
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?
A single sentence that front-loads the verb and the most important return content. Every clause earns its place with no redundancy.
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 an output schema present, the description need not enumerate return values, and annotations cover the safety profile. For a zero-parameter introspection tool, the description supplies everything an agent needs to decide to call it.
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?
The tool takes zero parameters, so there are no parameter semantics to document; the baseline for a parameterless tool is 4. Nothing in the description misleads about inputs.
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?
States a specific verb ('Return') and resource ('verified/experimental/planned features and the tools available in this session'), so the agent knows exactly what comes back. It is implicitly distinct from get_client_identity, but the description never names or contrasts that sibling, so it falls short of a 5.
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 phrase 'the tools available in this session' implies this is a discovery/introspection call, but there is no explicit when-to-use trigger, no when-not guidance, and the sibling get_client_identity is never referenced as an alternative. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read configured client ELF hash, Build ID and architecture without executing or attaching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds the notable nuance that no execution or target attachment occurs, plus what identity fields are surfaced, but does not cover prerequisites (e.g., a client must be configured) or failure behavior.
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?
A single front-loaded sentence with no filler; the subject of the read and the non-invasive constraint are both packed into one clause.
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 rich annotations, an output schema, and no parameters, the description carries little additional burden and covers the essentials. It could still note the precondition of an already-configured client to be fully complete, but nothing critical for correct invocation is missing.
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?
The tool takes zero parameters, which is the baseline-4 case; there is no parameter surface for the description to explain. The description's mention of 'configured client' implicitly tells the agent which client the result pertains to, but no argument semantics are needed.
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?
States a specific verb ('Read') and a concrete resource set ('configured client ELF hash, Build ID and architecture'), so an agent knows exactly what data comes back. It is distinguishable from the sibling get_capabilities by resource, though it never names or contrasts that sibling explicitly.
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 phrase 'without executing or attaching' implies the safe, passive-read scenario where this tool applies rather than an active debug/inspection path. However, there is no explicit when-to-use guidance and no comparison to the sibling get_capabilities, leaving selection to inference.
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.0get_capabilitiesget_client_identityScored across 2 tools
The two tools have clearly distinct purposes: one retrieves client binary identity (ELF hash, Build ID, architecture), the other reports server capabilities and available tools. There is no overlap or ambiguity in what each tool returns.
Both tools use a consistent snake_case get_ prefix followed by a noun phrase (get_client_identity, get_capabilities). The pattern is predictable and readable.
Two tools is borderline thin for a server, even if the scope is narrow. The tools are well-defined, but the set feels minimal and may leave agents wanting more surface area.
The surface covers client identity and capability introspection, which appear to be the core informational needs. However, related operations like retrieving session details or client configuration are missing, leaving minor gaps.
WhatsApp for Claude, ChatGPT or any AI agent: search, reply and send. Personal or Business API.
Read, search and reply to your WhatsApp chats from your AI, using your own number.
WhatsApp for your AI agent, sent from your own number. Source-available (Elastic License 2.0).
Persistent memory, hybrid search and a goal graph for AI agents, over stdio or remote HTTP.
