What repeated MCP package drift looks like in the wild

A single scary release is not the whole story. The more important signal is repeated drift: a package that keeps reshaping its capability surface while consumers keep installing it unattended.

That is what the watch feed recorded for @planu/cli in April 2026. The package did not just have one score drop. It crossed the same risk boundary multiple times, recovered, then crossed it again. For a consumer using npx -y, those are not abstract scanner events. They are different tool surfaces landing in the same install path on different days.

---

1. Three material reshapes in under two weeks

The first clear event landed on 2026-04-17. @planu/cli moved from 1.68.0 to 1.69.0. Score dropped from 85 to 65. Risk moved from LOW to ELEVATED. The package gained three capability buckets that were not present in the prior version: unknown, search_index, and database_access. Two hours later, 1.70.0 returned to 85 / LOW.

The second event landed on 2026-04-22. 1.83.0 scanned at 85 / LOW. Then 1.84.0 published at 04:16 UTC and dropped to 65 / ELEVATED, adding unknown, search_index, database_access, and filesystem_read. At 05:02 UTC, forty-six minutes later, 1.85.0 returned to 85 / LOW. That is a real rollback window. If you installed in that gap, you got a meaningfully different package than the consumer who installed an hour later.

The third event landed on 2026-04-30. 2.12.0 scanned at 85 / LOW. 2.12.1 dropped to 65 / ELEVATED and added unknown, search_index, network_egress, database_access, and filesystem_read. This became advisory AGENTSCORE-2026-0018.

---

2. Scores are not enough without history

If all you look at is the latest score, you miss the shape of the package. A current score tells you what the package looks like now. It does not tell you whether the maintainer keeps introducing and retracting new surfaces, whether those changes cluster around rushed release bursts, or whether your approved version sat inside a high-risk window three days ago.

This is why time depth matters more than a single scan. A package with one score drop and a clean fix is a different trust posture from a package that repeatedly expands and contracts its surface. The latter might still recover to LOW, but the historical record tells you the maintainer is iterating in a way that should change how carefully you review future versions.

---

3. The same instability pattern shows up elsewhere

This is not unique to one package. On 2026-04-25, agent-planner-mcp published four versions in nine hours:

• 0.8.1 at 13:44 UTC
• 0.9.0 at 18:10 UTC
• 0.9.1 at 19:14 UTC
• 1.0.0 at 22:44 UTC

The score held at 75 / MODERATE across those publishes, but that is exactly the point. Score stability does not mean release stability. The package crossed a major-version boundary in a single day. If you had reviewed the morning state, by the evening you were looking at a different artifact with no guarantee that capability shape, tool manifest, or release intent matched what you had approved.

---

4. What consumers should do with this information

First, pin exact MCP package versions. Treat them like lockfile entries, not like commands you re-resolve on every install. Second, review package history, not just the latest score. The real question is not only "is this package safe today?" It is "how often does this package change shape, and how visible will that be to us when it happens again?"

Third, separate awareness from enforcement. The watch feed and package dossiers tell you what changed. The Policy Gate gives you a merge-time decision when a repo wants to absorb a new version. You need both layers if you want a repeatable process rather than reactive cleanup.

Fresh scans help. Time depth tells you whether a package keeps drifting. That is the harder signal to copy, and the one consumers actually need when MCP packages are installed as living capability grants rather than static code.