wps-skills wires an AI assistant to WPS Office through MCP

An MCP server with a skills layer on top

wps-skills is positioned as an MCP server plus a skills framework, so that an AI assistant such as Claude Code, Cursor or Augment can operate WPS Office. The mechanism is natural language driving a tool set rather than a script that runs unattended.

The scale is stated as 231 MCP professional tools plus 12 built-in tools, 243 in total, broken down by application as 82 tools for Excel, 28 for Word, 112 for PPT and 9 general tools, alongside the 12 built-in ones. The built-in group covers connection checks, a universal method call and data caching.

The skills layer sits above that as natural language guidance in SKILL.md files, and the four skill directories are wps-excel, wps-word, wps-ppt and wps-office. So the design is a large programmatic surface with a thin instruction layer on top, where the skill tells the assistant which sequence of tools a person would use for a given task.

The project also states a working rule that is unusual to see written down in a README: any change to features or architecture must be followed by an update to the relevant documentation, described as part of their contract. For a project whose product is instructions to an agent, that rule is load bearing, since stale documentation is a broken feature.

Two execution backends, macOS over HTTP and Windows over COM

The architecture diagram in the README has three layers. The skills layer holds the natural language guidance and Claude Code calls into it. The MCP server layer, shown as 239 tools, then calls wpsClient.executeMethod(). Below that sits the execution layer, and this is where the platform split happens.

On macOS the execution layer is wps-claude-assistant, with 227 actions reached over HTTP with polling. On Windows it is wps-com.ps1, with 231 actions reached through the COM interface. Linux is supported by the project as a platform, and the troubleshooting table has a separate entry for the Linux case where the plugin cannot be found, pointing to the Linux specific guide in INSTALL.md, but the diagram names only the macOS and Windows executors.

The numbers do not agree with each other, and that is worth noticing before you rely on them. The headline count is 231 plus 12, which is 243. The architecture diagram says the MCP server layer has 239 tools. The two executors are described as having 227 and 231 actions respectively. Four different numbers for the same surface suggests the counts were taken at different times as the tool set grew, and a reader who is trying to work out what a specific client will see exposed should count the tools rather than trust the headline.

The COM route on Windows is worth a note on its own. Driving a desktop office suite through COM means the automation runs inside the application process, which is why the add-on install requires a human and why WPS has to be restarted for a change to take effect.

Cloning, building and registering the MCP server

The prerequisites are WPS Office itself, Node.js 18.0.0 or newer, and Git. The clone is a standard one:

git clone https://github.com/lc2panda/wps-skills.git
cd wps-skills

Then the MCP server is installed and built, since the build lives in the wps-office-mcp subdirectory:

cd wps-office-mcp
npm install
npm run build
cd ..

The third step is registering the server with whichever assistant you use, and the README gives a configuration block per client. Claude Code writes an mcpServers entry into ~/.claude/settings.json, Cursor writes one into .cursor/mcp.json in the project root, and OpenAI Codex CLI writes a [mcp_servers.wps-office] table into ~/.codex/config.toml. In every case the command is node and the argument is the absolute path to the built wps-office-mcp/dist/index.js. Codex CLI also has a command line form, codex mcp add wps-office -- node with the same path.

The server is described as a standard stdio implementation against spec 2025-11-25, compatible with first class MCP clients including Claude Code, Cursor, Codex CLI, GitHub Copilot CLI and Windsurf. Other MCP compatible editors are pointed at their own configuration documentation with the same command and arguments.

The add-on install needs a human, and the skills are Claude Code only

The fourth step is the one the agent cannot do, and the README marks it as requiring human interaction because the AI cannot operate the WPS application itself. The add-on install scripts are per platform:

# macOS
bash scripts/auto-install-mac.sh

# Windows (PowerShell)
powershell scripts/install.ps1

# Linux
bash scripts/install.sh

After the install, WPS Office must be restarted for the change to take effect, which the README states explicitly. A local add-on means the automation runs with the privileges of the person who installed it, and a restart of a running office suite is the kind of step that cannot be deferred.

The fifth step installs the skills, and the README says this is needed only for Claude Code. The four skill directories are symlinked into the Claude skills directory:

mkdir -p ~/.claude/skills
ln -sf "$(pwd)/skills/wps-excel" ~/.claude/skills/wps-excel
ln -sf "$(pwd)/skills/wps-word" ~/.claude/skills/wps-word
ln -sf "$(pwd)/skills/wps-ppt" ~/.claude/skills/wps-ppt
ln -sf "$(pwd)/skills/wps-office" ~/.claude/skills/wps-office

Symlinks rather than copies is a deliberate choice for a project that is still moving, since the assistant then always reads the current instructions from the working tree.

Verifying the install and the five failures worth knowing

The last step of the automatic install is a check that the server starts, and the expected sign is a log line saying the MCP server started successfully.

node wps-office-mcp/dist/index.js &
kill %1 2>/dev/null

The troubleshooting table is the more useful part for anyone running this in anger, and it lists five situations.

If the MCP connection fails, the answer is to confirm that npm install and npm run build were run and that dist/index.js exists. If WPS does not respond, the answer is to restart WPS Office and confirm the add-on is installed. An arguments error means rerunning the install script and restarting WPS, which points at a version mismatch between the built server and the installed add-on. If the plugin cannot be found on Linux, the answer is the Linux specific guide in INSTALL.md. And if a tool call returns null, the answer is to confirm that a document of the matching type is open in WPS.

Those five cover the interesting failure modes of a bridge like this one, and three of them are about state rather than code. The add-on and the server have to agree, the office suite has to be running, and the document has to be open before a tool can act on it.

The alternative is scripting the office suite itself

The realistic alternative is to script WPS Office directly with its own macro facility, or to generate documents with a library that writes files without an application in the loop.

The macro route has one clear advantage: it runs inside the office suite, so it has access to exactly the features the suite offers, and it is the approach an existing WPS user is most likely to have. Its limitation is that it is not conversational. A macro is written once for one known task, it runs the same way every time, and someone has to trigger it. wps-skills inverts that, letting the assistant decide at conversation time which sequence of tools to call, with the skills layer supplying the knowledge of how a person would drive the application.

The file generation route is different again. Writing a spreadsheet with a library produces a file and stops, with no application involved, no rendering, and no interaction with the document that is already open on someone's screen. If the goal is to produce a deliverable, that is often enough and it is much lighter. If the goal is to have an assistant operate a document the user is working in, the bridge approach is the one that works.

The trade is deployment weight. This project needs WPS Office, an add-on inside it, a Node process, an MCP client and a configuration file. The macro route needs only the add-on.

MIT terms, a private root package, and two repository details to check

The licence is MIT, stated in the README and in the package metadata, with the LICENSE file at the repository root.

The root package.json is named wps-skills at version 1.0.0 and is marked private, so it is a workspace shell rather than a published package, and its scripts just delegate into the wps-office-mcp subdirectory for build, test, start and the install and clean tasks. The engines field requires Node 18.0.0 or newer, and the keywords are wps, office, mcp, claude, ai and automation.

Two details in the metadata deserve a check before you rely on them. The repository field points at a different owner, listing the URL under laowang while the project itself lives under lc2panda, and the author field names an author with a laowang contact address. And the repository has no GitHub releases, so there is no version marker to install and no changelog to read beyond the README.

The last push was on 2026-06-30, which is more than six months before the present date, so the project is not currently receiving updates. Given the project's own contract that documentation must be updated alongside changes, that gap is worth taking seriously: the instructions, the tool list and the add-on may have moved apart, and the check to run first is the verification step that starts the server and looks for the startup log.

Editorial conclusion

wps-skills fits a team that already lives inside WPS Office and wants an assistant to act on real spreadsheets, documents and presentations rather than to produce a file and hand it over, and the skills layer means the assistant is told how each application is meant to be driven. It does not fit a workflow that wants headless document generation, and it does not fit a machine without WPS Office installed, since the assistant has nothing to talk to there. Before deploying it, confirm the add-on installs cleanly on your platform, check that the tool count the README claims matches what the server actually exposes, since the two figures differ, and pin the commit, because the repository has no releases and the last push was on 2026-06-30.

Frequently asked questions

Official sources

1. Issues
2. lc2panda/wps-skills on GitHub
3. License: MIT
4. README