When an MCP package outlives its repository

Not every important supply-chain signal looks like a malicious publish or a scary scanner finding. Sometimes the signal is quieter: the code is still installable, but the public repository behind it has effectively gone dark.

That matters in MCP because these packages are not passive libraries. They grant capabilities to agents: file access, network access, database access, browser control, or service credentials. A package that is no longer being actively stewarded can still be landing in fresh installs every day.

---

1. The Shortcut example

As of 2026-05-01, GitHub reports useshortcut/mcp-server-shortcut as archived. The npm package behind that repo is still present as @shortcut/mcp, latest version 0.24.0, with the registry showing its last publish on 2026-03-16.

That is not a vulnerability claim. It is a trust-state claim. The code still exists. The package still installs. But the public maintenance posture has changed. Anyone evaluating the package today should treat that as part of the security picture.

---

2. Why archive state changes the trust model

An archived repository changes the expected response loop. New issues are less likely to get triaged. Security reports are less likely to get patches. Dependency updates are less likely to land. Documentation tends to drift away from reality. Consumers can still install the package, but they are no longer inheriting an actively maintained trust relationship. They are inheriting a static artifact.

That is very different from "stable and quiet." A quiet package with an active maintainer is one thing. A quiet package with an archived repo is another. The second case means that if the ecosystem changes around the package, the package may not change with it.

---

3. npm keeps serving the last artifact

The registry does not care that a repository is archived. If the tarball is still published, the install path still works. A consumer using npx -y @shortcut/mcp is not warned that the maintainer posture changed. The package will continue to resolve, and the agent will continue to receive whatever capabilities that package exposes.

This is why abandonment is a supply-chain state, not just a maintainer biography. The package remains part of the live tool surface even if the project that produced it no longer behaves like an active project.

---

4. What consumers should check

• Is the upstream repository archived?
• When was the last publish to npm?
• When was the last meaningful commit or issue response?
• Is the package using provenance or trusted publishing?
• If this package stopped moving today, what would replace it in your stack?

None of these checks require a dramatic incident. They are governance checks. They answer whether you are depending on a living project or a frozen artifact.

---

5. What should happen next

For consumers, the immediate answer is simple: pin versions and track replacements for archived upstreams. For tools like AgentScore, the better answer is to surface abandonment explicitly as part of package posture. An archived repo should not be invisible just because the package still installs cleanly.

This is where public security memory matters. Fresh scans tell you what the package looks like now. Historical memory tells you whether the package is still situated inside an active maintenance loop. In MCP, where packages translate directly into agent capabilities, that is not peripheral metadata. It is part of the trust model.