How slima-mcp versions work

In one line: how slima-mcp versions work — the server does not block old ones, an old one simply has fewer tools to call, and here is how to tell which one you are running.

The current version

slima-mcp 0.3.0, published 2026-09-09. The version before it, 0.2.0, is from 2026-04-24 — more than four months earlier, so "one patch behind" is misleading here.

0.2.0 had the book, file and Beta Reader tools. What 0.3.0 added:

• The structured editing tools (update_beat_board / update_timeline / update_script / update_relationship_map / update_world_map)
• The teaching set (get_capabilities / list_guides / load_guide / list_writing_skills / load_writing_skill)
• Notes, comments and semantic_search
• view_relationship_map
• get_reader_test, for collecting a Beta Reader report that took longer than the wait window

How the server sees your version

Every call carries the client's version in its User-Agent. The server compares it against two thresholds:

Threshold	Currently	Meaning
Recommended	0.3.0	Below this you get an upgrade nudge, and everything still works
Hard floor	0.1.0	Only below this are you turned away. That line is reserved for security or breaking changes

So being behind is never a refusal of service. An old client's tools still work. What it lacks is tools to call — the server is not hiding anything; those tools simply do not exist in the copy of the package you have.

When you are behind, two signals show up:

• Every response carries an X-Slima-MCP-Upgrade-Hint header naming the recommended version and yours
• Error messages get an extra paragraph explaining the upgrade

Why 0.3.0 in particular is worth taking

Finding out which version you run

Web connectors (claude.ai, ChatGPT): nothing to check and nothing to do. The remote server is always current, and your next conversation is on the new version.

Local (Claude Desktop, Cursor, Gemini CLI, VS Code):

# the version you actually get
npx -y slima-mcp@0 --version

# the newest version on npm
npm view slima-mcp version

# any leftover global install — the usual culprit
npm ls -g slima-mcp

If the first two disagree, something is pinning you to the old one.

Upgrading

If your config uses npx: remove the global install first, then restart the client.

npm uninstall -g slima-mcp

That step is not tidiness, it is required. npx pkg@<range> will satisfy the range from a package already on your PATH and never contact the registry. Measured on 2026-09-09, with a global 0.2.0 present and 0.3.0 on npm:

Command	Resolved to
npx -y slima-mcp@0	0.2.0 — used the global install
npx -y slima-mcp	0.2.0 — same
npx -y slima-mcp@latest	0.3.0 — a dist-tag forces a registry lookup
npx -y [email protected]	0.3.0 — the global copy cannot satisfy an exact newer version

So a stale global install makes the npx form stop upgrading forever, while the server keeps telling you to upgrade.

⚠️ Check every place you might have installed it. A global install can exist once per Node version-manager environment and once per operating system. On WSL it is common to have one under nvm and another under Windows' AppData/Roaming/npm, at different versions, with only one of them on the PATH your MCP client actually uses.

If you want to stay on a global install: remember to run this yourself now and then.

npm install -g slima-mcp@latest

Why configs say @0 and not @latest

That is a separate question, about breaking changes at the major version: Why slima-mcp@0. The full move from a global install to npx is in Migrate from a global install.

Related

• Docs: Why slima-mcp@0: version-pinning explained
• Docs: Migrate from global install to npx
• Docs: slima-mcp CLI commands reference
• Docs: Guides and writing skills
• Docs: Structured editing tools