# This Xiaohongshu MCP toolkit is abandoned, and the readme says so first > xhs-toolkit wraps browser automation for a Chinese social platform behind an MCP server so an AI client can publish notes and pull creator analytics, and the most useful line in its readme is the one at the top: the author stopped work about a year ago and does not plan to maintain it. What remains is a well-documented architecture built on a foundation that a platform can invalidate in an afternoon. **aki66938/xhs-toolkit** — 📕 小红书创作者MCP工具包 - 支持与AI客户端集成的内容创作和发布工具 - Repository: https://github.com/aki66938/xhs-toolkit - Stars: 1,349 · Forks: 181 - Language: Python - License: MIT - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/aki66938-xhs-toolkit ## The readme's first section is a discontinuation notice Before the badges and the feature list, the document opens with a project discontinuation notice. It says that for personal reasons the project stopped progressing roughly a year ago, that no further maintenance is planned, and it thanks supporters. It then adds a sentence that is more useful than a farewell: the project did some design work in automation and in interface request signing, and anyone interested is welcome to fork it and continue building their own MCP tools. That framing changes how you should read everything after it. This is not a project waiting for a pull request; it is a snapshot offered as a starting point, and the author's own recommendation is to fork. It also tells you the two hard parts of the design, which are exactly the two parts a fork inherits and cannot avoid: driving a real browser session, and reproducing the signed requests the platform's own client makes. Both are brittle in the same way. A browser automation script breaks when a selector changes. Request signing breaks when the platform changes its algorithm. Neither failure is visible until you run the tool against production. The rest of this article is about what was built well, and about why a well-built tool in this category has a short shelf life by construction. ## Six MCP tools, and the table is the whole API surface The tool list is a table with six rows, and reading it tells you what the author considered the right granularity. There is a connection test that takes no arguments. There is a publish tool that takes a title, content, images, videos, tags and topics, and accepts both local paths and network URLs, and is marked as the main one. There are two status tools that take a task identifier: one to check progress, one to fetch a finished result. That split matters. A browser-driven publish takes tens of seconds and involves scrolling, uploading files and waiting for the platform, so it cannot be a synchronous request-response call inside a chat turn. Returning a task identifier and letting the client poll is the correct shape, and the author got it right. The login tool takes a force-relogin flag and a quick mode, and its note says it is an MCP-specific non-interactive login, which is the capability that makes unattended operation possible and also the one that makes the cookie question urgent. The analytics tool takes no arguments and is described as being for AI data analysis, and the readme explains that the data comes back with Chinese column headers so a model can read it without a translation step. That is a small, thoughtful design decision that anyone building a similar tool should copy. ## The browser layer is Selenium, and the driver match is the fragility The dependency list names selenium, and the readme spends more words on browser setup than on any feature. The environment requirements are Google Chrome, latest version recommended, and a matching driver, with the driver version stated as having to match the Chrome version exactly. The readme calls a version mismatch the most common cause of problems, in a warning with an alert marker on it, and offers three ways to get a driver: a package that manages them automatically, a manual download from a Chrome for Testing page, and installation through the system package manager on each of the three major desktop systems. There is a documented way to check your Chrome version from inside the browser, which is a small courtesy that removes the most common confusion. This is a real limitation of the design rather than of the implementation. A driver-coupled browser automation stack means every Chrome release is a potential breakage, and the readme is candid that the manual path requires finding an exactly matching build. The remote browser option is the more interesting engineering. You can point the tool at an already-running Chrome instance over a debugging port, which avoids launching a browser per operation and lets you keep a logged-in session. The trade-offs are stated: no new browser starts in remote mode, the target must have remote debugging enabled, and some operations such as window resizing may not work. A container configuration is provided with a shared memory setting, a volume for the profile directory, and a no-password VNC flag, which is a complete answer to running this on a server. ## Scheduled collection and CSV storage, with a database idea left half-built The data collection side is the part that runs unattended, and it has three pieces. A scheduler dependency is declared, and the readme describes scheduled collection using cron expressions, so analytics can be gathered on a schedule without anyone opening a terminal. Storage is CSV locally by default, and the readme has a parenthetical that SQL is currently retained but not being developed, which is an honest disclosure of an unfinished feature rather than a claim. A data structure detail is worth naming: the readme says the collected data uses Chinese column headers specifically so an AI client can understand and analyse it directly. That is a deliberate choice about the data contract, and it has a consequence. It makes the tool much easier to drive from a model with no schema translation, and it makes the output harder to consume from a typed application expecting conventional field names, so a team integrating this would need a mapping layer. The collection targets are the creator centre dashboard, per-note performance data such as views and likes, and follower growth data. Content search is the one item in the feature checklist that is unchecked, marked as in development, so the tool can publish and report but cannot yet find existing content. ## Three install paths, and a version number that disagrees with itself The quick start offers a shell wrapper, a Python-based install wizard, and two source workflows. The wrapper is a shell script on Unix and a batch file on Windows, which installs dependencies on first run, and the alternative is a Python install script followed by launching the wrapper. The interactive menu that results is a six-item text menu covering data collection, browser operations, data management, cookie management, MCP server, and system tools. The source workflows are the more interesting ones. The recommended path uses a fast Python package manager: clone, then sync dependencies, then run a status subcommand that verifies the tool works: ```bash git clone https://github.com/aki66938/xhs-toolkit.git cd xhs-toolkit ``` ```bash uv sync uv run python xhs_toolkit.py status ``` The traditional path creates a virtual environment, activates it, installs from the requirements file and runs the same status check. Note that the readme tells you every Python command in the documentation can be prefixed with the package manager runner instead. Configuration is a copied example file edited in place, and the two required entries are the path to the Chrome binary and the path to the driver, both of which are machine-specific absolute paths, which is why the driver problem is unavoidable. The version numbers, though, are inconsistent in a way that matters for a fork. The packaging metadata says 1.2.0. The newest published tag is 1.2.1. The readme's own menu screenshot prints 1.3.0. And there is a separate version file in the repository. Three or four sources of truth for a version is a small thing that will bite whoever maintains this, and it is a reasonable example of the kind of bookkeeping that accumulates when a project is not released deliberately. ## The MCP configuration is the part to copy The client configuration section is the most reusable artefact in the repository, because it is tool-agnostic and specific enough to be correct. The recommended form invokes the package manager runner with a directory argument, telling it which project to work in, then runs a module under a source package with a standard input and output flag: ```json "command": "uv", "args": [ "--directory", "/path/to/xhs-toolkit", "run", "python", "-m", "src.server.mcp_server", "--stdio" ] ``` The alternative form uses a system Python interpreter with a working directory and an environment block setting the module search path, which matters because the module is invoked from inside the source tree rather than installed as a package. Both forms are the same idea: a server process speaking the protocol over standard input and output, launched by the client, with the project directory fixed at configuration time. The readme gives the config file locations for two desktop platforms and notes that the client must be restarted after a change, and it also describes configuring the same server in two other hosts, one of them a workflow automation tool where the MCP server is added to an agent node's tool list. That last point is the strategically interesting one. A publishing tool is most valuable inside an automated pipeline, where a workflow decides what to publish and the AI client calls the tools. If you build something in this category, the tool contract should be designed for that caller rather than for a human at a menu, and this repository's six-tool table is a reasonable shape to start from. ## Conclusion Read xhs-toolkit if you want to understand how a browser-driving content tool gets wrapped in an MCP server, because the packaging is the transferable part and the code is a worked example of it. Do not adopt it for production content work, since the author states in the readme that work stopped roughly a year ago and no further maintenance is planned, and the last published release predates the last commit. Four things to check if you are still considering it. That your platform account automation is permitted under the terms you are held to, because the toolkit drives a real browser session with your own login cookies and the author notes the design work was in automation and request signing. That your Chrome and driver versions match exactly, which the readme calls the most common cause of failure. Where your login cookies are stored and who can read them, since a cookie for a creator account is a full session and the tool is designed to let an AI client log in without interaction. And which version you actually have, because the packaging says 1.2.0, the newest tag is 1.2.1, and the readme's own menu prints 1.3.0. The licence is MIT. ## FAQ ### Is xhs-toolkit still maintained? No. The readme opens with a discontinuation notice saying the project stopped progressing about a year ago for personal reasons and that no further maintenance is planned. The author invites interested developers to fork it and continue building their own MCP tools. ### What MCP tools does xhs-toolkit expose? Six: a connection test, a note publishing tool taking title, content, images, videos, tags and topics, two task tools for checking status and fetching results by task identifier, a non-interactive login tool, and a creator analytics tool. Publishing returns a task identifier rather than blocking, because the browser work takes long enough that a synchronous call would not fit a chat turn. ### What are the system requirements for xhs-toolkit? Google Chrome, with the matching driver, and the readme states the driver version must match the Chrome version exactly and calls a mismatch the most common cause of problems. It also supports connecting to an already-running remote Chrome instance over a debugging port. The packaging requires Python 3.10 or later. ### How do I configure the xhs-toolkit MCP server in a client? Add an entry to the client's MCP server configuration that launches the server module with a standard input and output flag, pointing at your project directory. The readme gives both a package-manager-runner form and a system Python form with a working directory and module search path, and notes the client must be restarted after the change. ### How does xhs-toolkit store collected data? CSV locally by default, with SQL retained but not under development. The readme says collected data uses Chinese column headers so an AI client can read and analyse it directly, and scheduled collection is supported through cron expressions. ### What licence is xhs-toolkit released under? MIT, declared in the packaging metadata. The project metadata lists it as beta status, and the version numbers disagree: the packaging says 1.2.0, the newest published tag is 1.2.1 from 2025-06-17, and the readme's menu prints 1.3.0. ## Sources - [aki66938/xhs-toolkit on GitHub](https://github.com/aki66938/xhs-toolkit) - [Issues](https://github.com/aki66938/xhs-toolkit/issues) - [License: MIT](https://github.com/aki66938/xhs-toolkit/blob/main/LICENSE) - [README](https://github.com/aki66938/xhs-toolkit/blob/main/README.md) - [Releases](https://github.com/aki66938/xhs-toolkit/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aki66938-xhs-toolkit