跪拜 Guibai
← Back to the summary

Open Wot 1.0.5 Replaces MCP Config Guessing with Two Commands

Hello everyone, I'm Buru Moyuqu, the initiator of wot-ui. Welcome to my AI Coding sharing column.

Some time ago we released Open Wot, organizing the component APIs, demos, CSS variables, and changelogs of wot-ui v2 into an offline knowledge base, then delivering it to developers and AI through CLI, MCP, and Skills.

We originally thought that once the knowledge was ready, AI could happily get to work. But after the tools were actually put into everyone's hands, new problems immediately arose:

How exactly do you configure MCP into Cursor? Why does Codex use TOML? The configuration is written in, so why can't I see it in the client?

The good news is, AI no longer has to guess component APIs.

The bad news is, humans have started guessing MCP configurations.

So what Open Wot 1.0.5 does is very direct: it turns wot-ui's AI integration from "please manually modify the configuration file" into a complete process that can be initialized, checked, diagnosed, and uninstalled.

The Shortest Answer First: Two Commands

Install or update to 1.0.5:

npm install -g @wot-ui/[email protected]

If you are using Cursor, execute in the project root directory:

wot agent init --client cursor
wot agent doctor --client cursor

The first command handles integration, the second handles verification.

After initialization is complete, the current project gains three types of capabilities:

MCP Server       AI can call 8 wot-ui tools on demand
wot-ui-v2 Skill  AI knows when and how to select and use components
Instructions     AI proactively queries real component knowledge before generating code

This isn't just packaging three trendy terms together. They solve three different problems:

Installing just one piece can certainly work, but combining all three gets us closer to the desired experience: AI queries before writing code, and checks again after writing.

Four Clients, No Need to Memorize Four Configurations

1.0.5 initially supports four common AI coding clients:

Client client id Project Configuration File
Claude Code claude .mcp.json
Cursor cursor .cursor/mcp.json
VS Code vscode .vscode/mcp.json
Codex codex .codex/config.toml

When using other clients, just replace the client id:

wot agent init --client claude
wot agent init --client vscode
wot agent init --client codex

If a project uses multiple AI clients simultaneously, you can also handle them all at once:

wot agent init --client all
wot agent doctor --client all --timeout 30000

--client all in project-level configuration handles Claude Code, Cursor, VS Code, and Codex. User-level configuration only handles clients that support the user scope.

This might seem like just writing a few fewer lines of JSON and TOML, but what's really saved is the time spent looking up configuration paths, confirming field names, handling different scopes, and repeatedly restarting clients to troubleshoot.

After all, our goal is to let AI help write business logic, not to make every developer first earn a certificate in "Mainstream AI Client Configuration File Formats."

init Does More Than Configure MCP

wot agent init is the recommended integration entry point for 1.0.5.

It defaults to preparing a change plan, which includes:

  1. Writing the wot-ui MCP Server for the target client.
  2. Installing the wot-ui-v2 Skill in the project.
  3. Writing Agent Instructions managed by Open Wot.

If you are cautious about automatically modifying files, you can dry-run first:

wot agent init --client cursor --dry-run

The CLI will list out the files and fields it intends to modify completely:

Initialize wot-ui Agent integration
write-file: .cursor/mcp.json
  Add or update mcp server "wot-ui" under mcpServers
  + mcpServers.wot-ui
    command: npx
    args: -y @wot-ui/cli mcp
write-file: .agents/skills/wot-ui-v2/SKILL.md
  Install bundled Skill file SKILL.md
write-file: .agents/skills/wot-ui-v2/references/overview.md
  Install bundled Skill file references/overview.md
write-file: AGENTS.md
  Update only the open-wot managed instructions block
Dry run: no files were changed.

After confirming there are no issues, remove --dry-run to execute formally.

You can also integrate only the parts you need:

# Only integrate MCP
wot agent init --client codex --with mcp

# Only install Skill and Instructions
wot agent init --client claude --with skill,instructions

Automation shouldn't mean "silently modifying files." So 1.0.5 first calculates a ChangePlan, then requests confirmation or execution; non-interactive environments like Agents and CI must explicitly pass --yes, and won't default to agreeing just because no one typed n.

Configuration Written In Doesn't Mean It Actually Works

This is a point I care a lot about in 1.0.5.

When doing MCP integration, it's easy to see a block of JSON added to the configuration file and declare the task complete. But in real environments, many other things can happen:

So we didn't treat "file write successful" as the final result. Instead, we added doctor:

wot agent status --client cursor
wot agent doctor --client cursor

status checks whether MCP, Skill, and Instructions exist and whether the configuration matches.

doctor goes further to complete a real MCP handshake: starting the Server, executing initialization, and confirming the existence of the 8 wot-ui tools.

For clients that provide stable query capabilities, it also checks the client-side registration status. Currently, Claude Code and Codex can do this automatically; Cursor and VS Code temporarily lack stable CLI registration query interfaces, so it will prompt you to restart the client and confirm in the MCP panel.

In other words, 1.0.5 tries its best to turn:

"Looks like it's configured"

into:

"Configuration is correct, Server can start, tools do indeed exist"

For the remaining project trust and approval steps that must be done through the client interface, it will also clearly tell you what to do next.

Why Auto-Configuration Defaults to Using npx

If @wot-ui/cli is already installed globally, the most intuitive MCP configuration might be:

{
  "mcpServers": {
    "wot-ui": {
      "command": "wot",
      "args": ["mcp"]
    }
  }
}

But the environment variables a desktop application gets at startup are often different from the terminal's. Just because you can run wot in the terminal doesn't mean Cursor or other clients can find it.

Therefore, the auto-configuration defaults to using:

{
  "mcpServers": {
    "wot-ui": {
      "command": "npx",
      "args": ["-y", "@wot-ui/cli", "mcp"]
    }
  }
}

This choice isn't particularly cool, but it prevents a batch of "I clearly installed it, why does the client say command not found" problems.

If you want to pin a version, you can also use --pin:

wot mcp init --client cursor --pin
wot mcp init --client cursor --pin 1.0.5

Auto-Modifying Configurations: How to Avoid Damaging User Content

When a tool starts modifying .mcp.json, AGENTS.md, and .codex/config.toml, the safety boundary becomes more important than "whether the command can run."

1.0.5 implements these restrictions in the write process:

Simply put: When the safety boundary can be confirmed, only the minimum scope is modified; when it cannot be confirmed, it's better to stop than to "guarantee success" by overwriting files.

The full lifecycle can be managed like this:

wot agent list
wot agent init --client cursor --dry-run
wot agent init --client cursor
wot agent status --client cursor
wot agent doctor --client cursor
wot agent remove --client cursor

MCP Also Has Complete Management Commands

Before 1.0.4, wot mcp was mainly responsible for starting the stdio Server.

1.0.5 retains the original usage while adding a set of complete management commands:

wot mcp list
wot mcp init --client cursor
wot mcp status --client cursor
wot mcp doctor --client cursor
wot mcp remove --client cursor
wot mcp print --client cursor
wot mcp serve

If you only want to use MCP and don't need Skill and Instructions, you can directly use this set of commands.

Among them, print only prints the configuration snippet for the target client without modifying files, suitable for those who prefer to maintain configurations themselves:

wot mcp print --client codex

serve is a semantically clearer way to start the Server. The original wot mcp remains compatible, so existing configurations don't need to be changed.

A Few Small but Very Practical Changes

Besides Agent and MCP integration, 1.0.5 also patches several daily usage experiences.

wot list Supports Keyword Search

Previously, viewing the component list:

wot list

Now you can search directly:

wot list button

Output looks like:

- Button 按钮 (wd-button): Used to trigger an action, such as submitting a form or opening a link.
- SortButton 排序按钮 (wd-sort-button): Used to display a sort button, supporting ascending, descending, and reset states.

Keywords match component names, Chinese names, tags, categories, and descriptions.

MCP Returns More Concise Results

Previously, when an Agent called wot_list, the list result might carry complete data for each component. Although informative, the Agent, at the stage of "first finding a suitable component," doesn't actually need all the props, demo source code, and full documentation at once.

1.0.5 changes to summary-first:

Discover first, then expand, and finally fetch the source code. The context for tool calls is cleaner and better aligns with the Agent's progressive query approach.

New starter-cleaner Skill

If you use wot-starter v2 to start business development but don't need the documentation site, demo sub-packages, and monorepo configuration in the repository, you can install Open Wot Skills:

pnpx skills add wot-ui/open-wot

Among them, starter-cleaner will first preview the cleanup scope, then organize the template into a minimal developable state while retaining Wot UI, uni-echarts, and echarts capabilities.

It should be noted here: starter-cleaner is an independent Skill, not content installed by default with wot agent init. Agent initialization defaults to installing the wot-ui-v2 Skill, which is aimed at component users.

We Also Built a Website for Open Wot

1.0.5 also integrates the official website into the Open Wot repository as a Monorepo sub-package:

Website address:

https://cli.wot-ui.cn

Regarding documentation synchronization, we ultimately chose the simplest method: Don't copy.

The root README continues to serve as the data source for CLI documentation, and the website is responsible for rendering it into a more readable page. This way, after a CLI update, there's no need to remind someone to "remember to copy it over to the website."

How Much Did 1.0.5 Actually Change

From 1.0.4 to 1.0.5, a total of 89 files were involved, with 19,741 lines added and 649 lines deleted.

This includes Agent integration, ChangePlan, MCP client adapters and real handshakes, as well as the website, Chinese documentation, and the starter-cleaner Skill.

Current test results:

Test Files  33 passed | 1 skipped
Tests       177 passed | 1 skipped

Tests cover scenarios like JSONC and TOML configuration modification, idempotent writes, rollbacks, client detection, MCP handshakes, registration status judgment, and command output.

Numbers themselves don't represent quality, but for a CLI that modifies user configuration files, writing more boundary tests is always better than letting users test the rollback process for us after it goes live.

Try It Now

Requires Node.js 20 or higher:

npm install -g @wot-ui/[email protected]

Choose a client id based on the client you are using:

# Claude Code
wot agent init --client claude

# Cursor
wot agent init --client cursor

# VS Code
wot agent init --client vscode

# Codex
wot agent init --client codex

Then execute:

wot agent doctor --client <client-id>

After configuration is complete, restart the client. If a "Trust Project" or "Approve MCP Server" prompt appears, follow the client's guidance to confirm.

Next, you can directly give this requirement to the AI:

Use wot-ui v2 to implement a login page,
including phone number, password, agreement checkbox, and login button.
Query the APIs and Demos of related components before writing code,
and check the usage of wot-ui in the project after completion.

We can't guarantee that AI will write all business logic correctly in one go, but at least component properties, events, and examples no longer need to be improvised on the spot.

One less API guess means one less problem to fix.

Finally

Wot UI v2's slogan is "Lightweight, Beautiful, AI-Friendly."

Our understanding of AI-friendly isn't just preparing a Prompt or llms.txt. Component knowledge needs to be structured, versions need to be aligned, Agents need to know when to query, and the integration process needs to be installable, diagnosable, and rollback-able.

Open Wot 1.0.5 is just one step on this path. We will continue to supplement client adapters, project check rules, and more specific Agent Skills later.

If you are using wot-ui v2, welcome to try 1.0.5. If you encounter problems, you can submit an Issue. Ideas for new Skills or client integrations are also welcome for contribution.

If you find the project a bit interesting, please also help us by giving it a Star.

The joy of open-source projects is sometimes just this simple.

Related Resources

Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

集成显卡

Great UI library. It would be even better if it weren't limited to running on uni-app.