xiaohongshu-mcp 小红书 MCP 的价值不只是“让 AI 帮你发一篇小红书”。它把小红书网页版中的搜索、阅读、发布和互动操作封装成 13 个 MCP 工具，让支持 MCP 的 AI 客户端可以用自然语言调用。原本分散在浏览器、表格、文案工具和发布后台里的工作，由此有机会串成一条连续流程。
这个 GitHub 公开项目 适合内容运营、品牌账号、独立开发者和 AI 工作流爱好者。它最有吸引力的地方不是完全替代人工，而是把机械操作交给工具，让人把时间放在选题判断、内容质量和发布审核上。
它能做什么：从读取数据到执行运营动作
按照项目当前 README 与 MCP 服务源码，连接成功后可以调用 13 个工具。它们大致分成四组：
| 能力组 | 可完成的操作 | 适合的运营任务 |
|---|---|---|
| 账号与登录 | 检查登录状态、获取登录二维码、清除 Cookies | 确认任务前置条件、重置失效会话 |
| 内容发现 | 获取首页推荐、关键词搜索、读取笔记详情、查看用户主页 | 选题研究、竞品观察、达人筛选、评论洞察 |
| 内容发布 | 发布图文、发布视频、添加标签、定时发布、设置可见范围 | 内容排期、素材批量准备、多格式发布 |
| 互动执行 | 发表评论、回复评论、点赞/取消点赞、收藏/取消收藏 | 评论维护、素材归档、轻量社区互动 |
图文发布支持本地图片绝对路径和 HTTP/HTTPS 图片地址，项目更推荐本地路径；视频发布目前只接受单个本地视频文件。发布参数还包括话题标签、1 小时至 14 天内的定时发布时间、原创声明、可见范围，以及已开通商品功能账号的商品绑定。
优势一：它形成了“研究—创作—发布—复盘”的闭环
普通的小红书自动发布脚本只解决最后一步：把准备好的标题、正文和图片填进发布页。xiaohongshu-mcp 的优势是同时提供读取工具和写入工具。AI 可以先搜索一个关键词，读取高互动笔记和评论，再整理用户关心的问题，生成内容角度，最后调用发布工具。
发布后仍可继续读取笔记详情和互动数据，辅助判断标题、封面和内容结构是否需要调整。这里的“闭环”不是承诺自动涨粉，而是减少在多个工具之间复制链接、记录 ID、粘贴评论和重新整理素材的时间。
一个可落地的选题流程
- 用
search_feeds搜索目标关键词，并按最新、最多点赞、最多评论或最多收藏筛选。 - 用
get_feed_detail读取笔记正文、作者、互动数据及评论。 - 让 AI 提炼重复出现的问题、反对意见和未被充分回答的细节。
- 人工确认选题与事实，再生成标题、正文、标签和配图清单。
- 通过
publish_content发布，或者先设为仅自己可见进行检查。
这种流程尤其适合需要稳定产出系列内容的账号：美食探店可以按城市和品类整理选题，软件账号可以收集真实使用问题，电商账号则能从评论里找出用户对规格、价格和使用方式的疑问。
优势二：搜索不只是返回链接，而是带筛选条件的结构化研究
search_feeds 支持按笔记类型、发布时间、排序方式、阅读状态和位置距离筛选。与让通用搜索引擎查网页相比，它更接近运营人员在小红书站内主动调研的过程。
取得 feed_id 和 xsec_token 后，还能继续读取笔记详情，包括图片、作者资料、点赞、收藏、分享、评论数以及评论内容。评论可以设置加载数量、是否展开二级回复与滚动速度，适合做小规模的需求归纳和内容复盘。
需要控制预期的是：它不是官方数据分析平台，也不保证拿到全部历史评论。页面加载方式、账号状态和小红书前端结构都会影响返回结果，所以数据更适合用来发现方向，不适合直接当作完整统计口径。
优势三：发布能力比“填写标题和正文”更完整
项目把常见的发布参数直接做成了工具字段。除了标题、正文和素材，还可以传入标签、定时发布时间、可见范围和商品关键词。点赞、收藏等操作会先判断当前状态，避免重复执行同一动作。
对于团队来说，结构化参数还有一个好处：可以在 AI 真正发布前设置固定审核清单，例如标题长度、素材路径、标签数量、可见范围和发布时间必须逐项确认。MCP 源码也为发布、评论、点赞、收藏、清除 Cookies 等工具标记了破坏性提示，而搜索、列表和详情工具被标记为只读，这为客户端保留人工审批提供了基础。
如果你的上游流程会使用 ChatGPT 做选题拆解、标题变体和文案初稿，稳定的创作账号能减少工作流中断。V需AI 提供的 ChatGPT Plus 正规卡充订阅 采用兑换码自助方式，无需提交账号密码，并提供自动发货和 7×12 小时人工支持。完成内容审核后，再把确定的标题、正文和素材交给 MCP 执行发布，职责会更清楚。
优势四：不绑定单一 AI 客户端
xiaohongshu-mcp 通过 Streamable HTTP 提供服务，默认地址为 http://localhost:18060/mcp。项目文档给出了 Claude Code、Cursor、VS Code、Gemini CLI、Cline、OpenCode 和 MCP Inspector 的接入方式；任何支持 HTTP MCP 的客户端，也可以使用相同地址连接。
这意味着内容数据与小红书登录会话留在你运行服务的环境中，前端 AI 客户端可以按团队习惯更换。想用 Cursor 做流程调试、用 Claude Code 编排任务，或者用 Inspector 单独验证工具，都不需要重写整套小红书操作代码。
优势五：部署路径覆盖不同技术水平
开发者可以下载 macOS、Windows 和 Linux 的预编译程序，也可以使用 Go 从源码编译；需要固定运行环境时，可选择 Docker 和 Docker Compose。Docker 配置会挂载 Cookies、运行数据和图片目录，并暴露 18060 端口。
不想处理 Docker、浏览器依赖或本地服务的用户，作者还推荐同一团队的浏览器插件方案 x-mcp。它直接运行在 Chrome 或 Edge 与本地网络环境中，定位更偏向非技术用户。传统项目版则更适合需要自定义、调试和工作流集成的人。
哪些运营场景最适合 xiaohongshu-mcp？
品牌账号的评论需求整理
搜索品牌名、产品类型和竞品关键词，读取用户反复提到的价格、规格、效果和售后问题。AI 可以把评论按主题归类，运营人员再决定哪些问题值得单独制作一篇笔记。
内容矩阵的素材与排期管理
在本地提前准备图片、视频和审核后的文案，按计划调用图文或视频发布工具。定时发布和可见范围字段能减少临时手工操作，但每条内容仍应保留人工终审。
达人和同类账号研究
user_profile 可以返回用户资料、关注数、粉丝数、获赞量和公开笔记列表。它适合快速了解账号定位与内容方向，再结合具体笔记详情判断是否值得进一步研究。
系列选题的持续更新
同一关键词可以按“一天内”“一周内”或“半年内”重复搜索，并按最新或互动表现排序。比起一次性抓取大量内容，这种低频、明确范围的研究更容易人工复核，也更适合长期运营。
教学部分：最短接入路径
想快速验证项目，优先从 GitHub Releases 下载与你系统匹配的登录工具和 MCP 主程序。第一次运行会下载约 150MB 的无头浏览器。
- 先运行
xiaohongshu-login，在打开的浏览器中完成登录并保存状态。 - 再运行
xiaohongshu-mcp；排查问题时可以添加-headless=false显示浏览器界面。 - 在 MCP 客户端中添加
http://localhost:18060/mcp。 - 先调用
check_login_status，再使用只读的list_feeds或search_feeds测试。 - 确认读取稳定后，才测试“仅自己可见”的发布任务。
以 Cursor 为例，项目级配置可以写入 .cursor/mcp.json：
{
"mcpServers": {
"xiaohongshu-mcp": {
"url": "http://localhost:18060/mcp",
"description": "小红书 MCP 服务"
}
}
}保存后重启客户端，并在工具列表中确认 13 个工具是否被识别。第一次不要开启写入工具的自动批准。
真正需要重视的是账号和自动化边界
这个项目使用浏览器自动化操作真实账号。近期 GitHub Issues 中已有用户报告脚本识别、账号警告、禁言、发布按钮失效和“接口显示成功但笔记没有实际发布”等情况。这些报告不代表所有环境都会出问题，但足以说明“能运行”不等于“长期无风险”。
- 先用测试账号和低频任务验证：不要一开始就批量搜索、连续互动或高频发布。
- 写操作保留人工审批：搜索到的笔记属于不可信外部内容，可能包含提示词注入文本。读取与发布最好拆成两个步骤，禁止搜索结果直接触发评论、点赞或发布。
- 保护 Cookies 和服务端口：不要把 18060 端口无认证暴露到公网，也不要把 Cookies、二维码或登录数据提交到代码仓库。
- 发布后人工检查：确认笔记确实出现、图片顺序正确、标签和可见范围符合预期，而不是只看 MCP 返回的成功信息。
- 避免同一账号多处网页登录：项目 README 提醒，同一账号在其他网页端登录可能让 MCP 会话失效；移动 App 可用于查看账号状态。
- 遵守平台规则：自动化工具不能替代内容授权、广告合规、原创要求和账号运营规范。
如果计划二次分发或集成到商业产品，也应先确认代码授权范围；仓库根目录当前没有显示独立的 LICENSE 文件，“源码公开”不自动等于可以无限制商用和再发布。
它值得用吗？
对于愿意维护本地服务、理解 MCP，并且需要把选题研究、文案生成、素材准备与发布动作串起来的人，xiaohongshu-mcp 是目前功能覆盖较完整的小红书 AI 工具之一。13 个工具同时覆盖读取和写入，客户端选择多，发布参数也足够细，适合搭建有人审核的内容工作流。
它不适合追求“无人值守批量养号”的使用方式。小红书页面变化、账号风控、Cookies 失效和提示词注入都会让全自动方案变得脆弱。更稳妥的做法是让 AI 负责搜索、整理和生成候选内容，让人负责事实、素材、品牌表达与最终发布确认，再把 MCP 当成最后一段执行工具。
