MatrixMedia: bulk video publishing to eight Chinese platforms

What the application does

MatrixMedia is a desktop application for people who publish the same content to many accounts, which is the business model usually called a content matrix. It is built with Electron, it ships a graphical interface and a command line tool, and it runs on Windows and macOS. The video platforms it automates are Douyin, Kuaishou, Baijiahao, Bilibili, Toutiao, WeChat Channels, Xiaohongshu and Fanqie, and the README states that all eight are fully automated for publishing. The input is either a local file path or a remote address, in which case the tool downloads it and cleans up the temporary file after the upload. The interface opens on a project details page, which is where the integration instructions for the HTTP API, the MCP server and the command line live, and the README calls the tool suitable for scripting and for agent orchestration. The licence is GPL-2.0-only, declared both in the package manifest and in the licence file at the root of the tree.

The command line contract, and why it is designed that way

The CLI is described as deliberately independent of any particular AI tool or framework, and the mechanism is simple. If the argument vector contains the word cli, the process runs without a graphical interface, and the subcommands are login, publish, publish-article, accounts and history, each of which takes a help flag. The exit codes are specified rather than left to chance, with zero for success, one for an exception, two for a bad argument and three for a business failure such as a login that did not succeed or an upload that was rejected. Two of the subcommands produce stable JSON when given a json flag, so an upstream tool can consume the result without parsing human text. Login by QR code in the terminal is currently supported for Douyin and WeChat Channels, and for Douyin there is also a headless mode driven by Puppeteer, while the other platforms need one login through the graphical interface first.

Session sharing, the HTTP API and the MCP server

Three details make the tool usable from a scheduler. First, the command line and the graphical interface share a session partition named after the phone number and the platform, so the two do not interfere and a login performed in one is visible to the other. Second, once the graphical application is running, a local HTTP endpoint accepts a publish request on a loopback port, which is what the project details page documents, and it is the simplest way to trigger a publish from another program. Third, the repository contains an MCP subpackage that implements the Model Context Protocol server, so a tool that speaks MCP does not need to call a shell at all. The server is built with a short sequence of commands in its own directory:

cd mcp && npm install && npm run build

and then pointed at from the AI tool with the absolute path of the repository passed in an environment variable. The seven tools it exposes cover listing accounts, listing history, publishing a video, publishing an article, and reading or refreshing statistics.

The real browser mode, and why it exists

One platform forced a change of approach, and the README explains it well enough to be worth reading. Xiaohongshu increasingly detects automation inside the embedded window that Electron provides, and the symptom is a warning that the account is under AI management. The response is a publishing mode that uses the real browser instead. The tool drives the Chrome or Chromium already installed on the machine with Puppeteer Core, a light library that does not bundle a browser of its own, and it copies the login state from the embedded window into the real browser before publishing. The path to the browser is a global setting shared by all Xiaohongshu accounts, stored in a configuration file under the user data directory, the first switch-on detects the installed Chrome automatically, and there is a connection test to confirm the browser launches. If no browser is found or the launch fails, the tool falls back to the embedded window, so the mode degrades rather than breaks.

Where the automation is brittle

Every part of this design depends on a web interface that the platform owns and can change at any time, and the Xiaohongshu case shows what that looks like in practice. The login story is also uneven, because the terminal QR code flow works for two platforms while the rest require the graphical interface, and the MCP server cannot help at all there because it runs headless over standard input and output with no way to display a scan. Publishing videos has a length limit of 35 minutes in the MCP tool, and article publishing is aimed at a single article platform, so the eight platform claim is about video. The tool also schedules publishing, which means a failed upload at a scheduled time is discovered later, and the local publish history is the only record of what happened. None of this makes the project worse than any other automation in the same area, but it is the shape of the risk a user takes on.

The agent integration design

The project treats discoverability by automation tools as a first-class concern, which is unusual and useful to see in a repository. An HTML comment at the top of the README carries a marker with an identifier, a version, a platform and the argument marker that tells a discovery tool how the command line is entered, and the README explains that other platforms can add their own equivalent marker without conflicting. The stated philosophy is that any tool which can call a shell, read an exit code or read JSON on standard output can use the application, and the list of named integrations is long, from coding agents and IDE assistants to workflow and multi-agent orchestration frameworks. The design consequence is that the tool has to keep its command line stable and its output machine-readable, which is the same discipline that makes a CLI pleasant to script by hand.

The build, the packaging and the state of the project

The build is the electron-vue toolchain with electron-builder producing the installers, and the package manifest spells out the matrix of targets, a Windows build, macOS builds for both architectures, and Linux builds as a deb package, an AppImage and a tarball, with combined targets as well. The scripts are orchestrated with yarn, and two of them run a generator for a telemetry secret before the development server and before a directory build, which is the kind of detail that only appears in a project that has a release process. The tree is broader than a single application, with directories for the platform automation scripts, for skills, for a workbuddy package, for the MCP subpackage, for the documentation, for the website and for the shared library code, alongside agent instruction files and a script that verifies the CLI. The releases move quickly, v0.12.9, v0.12.8 and v0.12.7 within a few days in October 2026, with the last push on 2026-10-17, and the downloads are published on both GitHub and a Gitee mirror with the documentation hosted on the project site and mirrored to a Gitee wiki.

Editorial conclusion

MatrixMedia fits an operator who runs many accounts across Chinese platforms and wants one publish action instead of eight, and it fits a team that wants to drive publishing from a scheduler, a workflow tool or an AI assistant rather than from a window. It does not fit a creator who posts to one account, and it should be used with the platforms rules in mind, because automating a web interface is exactly the kind of use that platform detection is built to stop. Before deploying it, log in on the GUI for every platform you intend to use, because the headless paths cannot show a QR code, and check the per-platform notes, since the CLI login support covers only two of the eight platforms.

Frequently asked questions

Official sources

1. hanliang97/MatrixMedia on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases