@uni-design-system/uni-mcp 4.7.3 → 10.2.1

package/CHANGELOG.md

@@ -1,5 +1,49 @@
 # @uni-design-system/uni-mcp
 
+## 10.2.1
+
+### Patch Changes
+
+- [`704e79b`](https://github.com/uni-design-system/uni/commit/704e79bb896bd32de17f45b4bed8e5b9e5882186) Thanks [@gaenglish](https://github.com/gaenglish)! - The published MCP server carries the index for its own release.
+
+  `uni-mcp@10.2.0` shipped a bundle whose index was stamped `meta.version:
+10.1.0`. The data itself was current, but the one field a consumer reads to
+  check which release the server describes said the previous one — the same drift
+  the version alignment had just been made to end.
+
+  The cause was ordering, not data. `tsup` **inlines** `uni-index.json` into the
+  bundle, so the dist built during the verify step was stamped before
+  `changeset version` ran; publishing then shipped that stale bundle even though
+  the regenerated index was correctly committed to the repo. `version-packages`
+  now rebuilds `uni-mcp` after regenerating the index, so the artifact and its
+  source agree.
+
+  The general rule, for anything added later: a package whose dist embeds
+  release-time data has to be rebuilt _after_ the version bump, not before.
+
+## 10.2.0
+
+### Patch Changes
+
+- [`2b8d80f`](https://github.com/uni-design-system/uni/commit/2b8d80f133c68be2cffd600aa84f601ad59f22db) Thanks [@gaenglish](https://github.com/gaenglish)! - The MCP server now shares the library's version number.
+
+  It used to release on its own `4.x` line while the library was on `10.x`, which
+  had two consequences. Pinning was impossible: the README told you to match the
+  server to your installed `@uni-design-system/uni-angular` version, but
+  `uni-mcp@10.1.0` did not exist. And staleness was silent — the index is
+  regenerated on every release, stamped with that release's version and **inlined
+  into the published bundle**, yet the package only republished when someone
+  remembered a changeset for it. Miss one and the server keeps describing the
+  previous release while reporting a version that gives no hint of it.
+
+  `uni-mcp` joins `uni-core`, `uni-react` and `uni-angular` in the changesets
+  `fixed` group, so it always shares their version and always republishes. The
+  version therefore jumps from `4.7.3` to match the current release. Nothing about
+  the server's behaviour, transport or tools changes.
+
+  `uni-mcp@<version>` now describes `uni-angular@<version>`, so pinning them
+  together does what the docs always claimed it did.
+
 ## 4.7.3
 
 ### Patch Changes

package/README.md

@@ -42,17 +42,24 @@ your client's MCP settings.
 
 ### Pin it to your installed Uni version
 
-All Uni packages release under one coordinated version number. The server
-answers from an index stamped with the release it was built from, so for
-answers that exactly match the APIs you have installed, replace `@latest` with
-the version of `@uni-design-system/uni-angular` in your `package.json`:
+All Uni packages release under one coordinated version number, this server
+included. It answers from an index stamped with the release it was built from,
+so for answers that exactly match the APIs you have installed, replace
+`@latest` with the version of `@uni-design-system/uni-angular` in your
+`package.json` — they are the same number:
 
 ```jsonc
-"args": ["-y", "@uni-design-system/uni-mcp@4.3.0"]
+"args": ["-y", "@uni-design-system/uni-mcp@10.2.0"]
 ```
 
 `@latest` is fine when you track current Uni releases.
 
+> **Versions before 10.2.0.** This server used to release on its own `4.x` line
+> while the library was on `10.x`, so pinning it to your installed version was
+> impossible and the index could go stale whenever a release did not happen to
+> bump it. It now moves with the rest of the packages, and every release
+> republishes it — so `uni-mcp@10.2.0` describes `uni-angular@10.2.0`, exactly.
+
 ### Verify and try it
 
 In Claude Code, `/mcp` should list **uni** as connected. Then ask things like: