@kenwea/mcp weekly downloads statistics

@kenwea/mcp

Notarize what an npm package does when you install it — a signed record you can forward, in one command, with no account.

npx -y @kenwea/mcp check debug

Resolved debug → debug@4.4.3
  https://registry.npmjs.org/debug/-/debug-4.4.3.tgz

Kenwea notary — https://registry.npmjs.org/debug/-/debug-4.4.3.tgz

  verdict     MANUAL_REVIEW (no_install_steps)
  why         nothing of this package's own runs when it is installed: it declares
              no preinstall, install or postinstall script and ships no binding.gyp.
              We executed nothing, so this is not a pass; it is the fact a gate on
              install scripts reads
  sha256      89c1ac9c946ee8905a875837114528e97eeae35e03be3190584b2216af43e4a7
  size        13449 bytes
  at install  nothing runs
  executed    no

  signed      ed25519, key 322a2536e0d5ec8e
  verified    here, against the published key 322a2536e0d5ec8e (active)
  keys        https://www.kenwea.com/.well-known/kenwea-attestation-keys.json

That is a real run of 0.3.0 against mcp.kenwea.com on 8 October 2026, not an illustration (long lines wrapped, the attestation paragraph left out). Give it a package name (debug, debug@4.4.3, @scope/pkg@1.2.3) or any https URL; it resolves the exact tarball npm install would fetch, checks those bytes, and verifies the signed record before showing it.

Why this is worth anything

You can already run code. Most agents have a sandbox of their own, and if you don't, Docker is right there. Running the artifact is the commodity part, and it is not what this gives you.

What you cannot mint for yourself is a third-party record others can verify. "I ran it and it's fine" from the party that wrote it is circular, and every reviewer knows it. The value is not the run — it is the notarized result: a verdict signed under a published Ed25519 key and bound to the sha256 of the exact bytes, so anyone you forward it to can check it without trusting you or us.

And it is a record that outlives the artifact. When a registry pulls a compromised version — as npm did with the chalk and debug tombstones — the bytes are gone and the incident becomes unauditable. A signature minted while the version was live is the one thing that survives: a permanent, forwardable statement that these exact bytes did this, at this time, under these constraints. Which is why it has to run at the moment you pull, not as something you remember to do afterward.

So this is not an execution service. It is a notary: an independent party fetched those exact bytes, ran them under stated constraints, and signed what happened — including when the answer is unflattering, and including when the answer is "we could not read it, so we are not offering a verdict."

What it actually does

A whole dependency tree: check-tree (0.7.0, workspaces 0.7.1)

npx -y @kenwea/mcp@0.7.1 check-tree --fail-on network,credentials --wait 600

Your lockfile is read on your machine. Only the packages it marks hasInstallScript (usually a few percent of a tree) and your project's own direct dependencies are sent to the notary, by name and version; the names of the rest never leave your machine. Since 0.7.0 the tree is checked through those direct dependencies, each with its whole tree, because a step runs under the package that pulled it in: @scarf/scarf reports install telemetry only for the package that depends on it, so checked alone it looked quiet. A package under a direct dependency comes back UNDER, answered by that dependency's record, and a gate reads what ran in a record's dependency tree, not only the package's own steps. The direct dependencies come from the root of a package-lock.json, every importer of a pnpm-lock.yaml (in a workspace each package is a project of its own; before 0.7.1 only . was read, so a monorepo whose root declares few dependencies was checked package by package), or, for a yarn.lock, the package.json beside it; without one, each package is checked on its own and the output says so. Each comes back with its stored signed record, made by the same sandbox run with decoy credentials, or is queued and checked in the background, about two a minute. Every record is verified here: the signature under the key it names, and the tarball matched against your lockfile's integrity and the record's sha256. A gate cannot pass on a package that has no record yet; --wait <seconds> asks again until it has. It reads package-lock.json (version 2 or 3), pnpm-lock.yaml (v5, v6, v9) and yarn.lock (v1 and berry), and with no path it uses whichever of them is in the current directory. pnpm up to v6 marks the packages that run something (requiresBuild); pnpm v9 and yarn do not, so those versions are asked of the npm registry from your machine, as an install does, and their names still do not go to Kenwea. A package that could not be classified is said, and a gate cannot pass on it. Integrity is checked with the strongest algorithm your lockfile lists, sha1 for old yarn entries included.…