Four servers, opened one by one. Two talk HTTP to the registry, one drives the npm CLI, one scores packages in Go -- and the split decides which one you want.
Searching npm from an agent is the easy half. Every server in this post can tell you what version of fastify is current. The half that separates them is what happens when you ask for something that changes state -- deprecate a package, move a dist-tag, add a maintainer, publish -- because that is where the npm CLI's auth model starts fighting a subprocess that has no terminal. This post opens four npm MCP servers, says what each one covers, and names the cases where ours is the wrong pick. Inline code is styled like npx -y @yawlabs/npmjs-mcp.
Worth settling first, because it changes how you should read every option below. The npm GitHub organization publishes no MCP server -- as of September 2026 there is no repository in it whose name contains "mcp". npm is also not among the Model Context Protocol project's reference servers, which are Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time. Everything in this category is community-built, including ours, so the only useful evaluation is reading the source.
The npm CLI authenticates from ~/.npmrc, and npm login defaults to an auth-type of web -- a browser flow. On an account with two-factor authentication, npm's own docs for npm owner say changing ownership means going through a second-factor flow or passing --otp on the command line, and npm access says the same for permission changes. A subprocess with no terminal and no browser can supply neither, so an agent that shells out to one of these gets an auth error it cannot fix, retries, and burns your turn budget.
There are two ways out, and the servers below split cleanly along them. Either drive the CLI and pass a one-time password through as a tool parameter, or skip the CLI and call the registry's HTTP API with a token. Our server takes the second route -- deprecation is a read-modify-write of the package document, dist-tags go to /-/package/{name}/dist-tags/{tag}, access changes go to /-/package/{name}/access, all with a bearer token and no CLI in the path:
{
"mcpServers": {
"npm": {
"command": "npx",
"args": ["-y", "@yawlabs/npmjs-mcp@latest"],
"env": { "NPM_TOKEN": "npm_xxxxxxxxxxxx" }
}
}
}Leave the env block off entirely and the server still starts -- reads do not authenticate. A live probe of version 0.15.1 returns 64 tools, 42 of them annotated read-only, and those 42 work anonymously.
Counts below are the tool rows in each project's own README, except ours, which is a tools/list call against the published package on 11 September 2026. Where a project's README and its repo description disagree, the README wins: the mikusnuz repo description says 32 tools, while its README tables list 38. Download figures are the 30 days ending 2026-09-10.
| Capability | @yawlabs/npmjs-mcp |
@mikusnuz/npm-mcp |
@pinkpixel/npm-helper-mcp |
npm-registry-mcp |
|---|---|---|---|---|
| How it reaches npm | Registry HTTP API | npm CLI subprocess | npm-check-updates + page fetch | Registry HTTP API |
| Tools | 64 | 38 | 10 | 4 |
| Runtime | Node, bundled, no deps | Node, needs npm on PATH | Node | Go binary |
| Reads without a token | Yes, 42 tools | Needs a working npm | Yes | Yes |
| Publish | No, by design | Yes, with 2FA passthrough | No | No |
| Deprecate, dist-tag, owner | Yes, over HTTP | Yes, via the CLI | No | No |
| Org, team, access, hooks admin | Yes, 22 write tools | access, owner, token | No | No |
| Dependency upgrade loop | No | outdated, update | Yes, including test-and-revert | No |
| Local project ops (install, ci, scripts) | No | Yes | Partial | No |
| Health verdict scoring | Metrics, no verdict | No | No | Yes, weighted score |
| License | MIT | MIT | MIT | MIT |
| Downloads, last 30 days | 859 | 179 | 142 | Not on npm |
Twenty-two of our 64 tools write, which is the part worth being nervous about. The guards, read from the source rather than the marketing copy: npm_unpublish_version, npm_unpublish_package, npm_team_delete and the two org-membership tools take a literal confirm: true that is re-checked at runtime, so a model that omits it gets a refusal instead of an irreversible call. npm_owner_remove refuses the call that would leave a package with zero maintainers, which is the one owner mistake you cannot undo yourself. Every tool carries MCP annotations, so a client can skip the confirmation prompt on the 42 reads and insist on one for the rest.
One correction to our own README while we are here: it claims the deprecate tool validates message punctuation. It does not. The registry limit the tool enforces is 1024 characters, and the tool's own description says a semver range matching no published version -- not message format -- is the usual cause of a rejected deprecation. If you hit one, check npm_versions first.
@mikusnuz/npm-mcp publishes, and ours never will. It imports execFile, runs the npm binary from NPM_PATH, and writes your token into a temp npmrc, which sounds like a workaround until you notice what it buys: publish, version, install, ci, run-script, pack, sbom and link. Those touch your working tree and your lockfile. An HTTP client cannot reach any of it. If the sentence you want to say is "bump the version and publish this", that is the server, and it takes an OTP parameter for 2FA accounts. It ships no MCP tool annotations, so your client will prompt on reads too.
@pinkpixel/npm-helper-mcp owns the chore you actually do weekly. Six of its ten tools wrap npm-check-updates, and runDoctor iteratively installs upgrades, runs your tests, reverts the ones that break and keeps the ones that pass. We have nothing comparable -- not a smaller version of it, none of it. For "get my dependencies current without breaking the build", it is the better tool and it is not close.
npm-registry-mcp is four tools and one static binary. Sixty-four tool definitions are not free -- they sit in context on every turn, which is a real cost we have written about at length. This one ships a Go binary with no Node runtime, and its should-i-install tool returns a verdict of yes, caution or no from a weighted score over publish recency, download trend, outdated dependencies, commit activity, maintainer count and known vulnerabilities. Ours hands back metrics and makes the model do the judging. If you want one opinionated answer and a tiny context footprint, take the Go one.
All three are MIT, same as ours. There is no licensing argument here, only a fit argument.
Registry administration that is not publishing. Deprecating a renamed package and pointing the message at its replacement, rotating a dist-tag after a bad release, auditing who can publish to an org's packages, granting a team, revoking a token, wiring a webhook, or checking provenance and trusted-publisher relationships before you trust a dependency -- the supply-chain questions that start with "who published this, when, and from what CI". Those are HTTP-API operations, they do not want a terminal, and they are what the 22 write tools and the provenance pair exist for.
Add it to any MCP client, or let Yaw MCP fan one config out to every client on the machine:
npx -y @yawlabs/npmjs-mcpSource: github.com/YawLabs/npmjs-mcp, MIT, version 0.15.1 at the time of writing. The card on our MCP servers page has the one-click install.
No. As of September 2026 the npm GitHub organization publishes no repository containing an MCP server, and npm is not among the Model Context Protocol project's reference servers, which are Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time. Every npm MCP server you can install today is community-built, so judge them on their source rather than on a vendor badge.
Not for reads. In a live tools/list probe of version 0.15.1, 42 of the 64 tools in the Yaw Labs server are annotated read-only and they work anonymously against the public registry: search, metadata, versions, downloads, audits, dependency trees and license checks. Writes need an npm token with write scope, and a granular access token scoped to only the packages your agent should touch is the safer choice.
One of these can. The mikusnuz npm-mcp server shells out to the npm CLI, so it exposes publish, version and pack, and it forwards a one-time password for accounts with two-factor authentication. The Yaw Labs server deliberately has no publish tool: it talks to the registry over HTTP, and its own decision matrix routes publishing to a release script run from your workstation, where provenance and CI signing belong.
Jeff Yaw, Yaw Labs. Follow along at tokenlimit.news for weekly notes on AI infrastructure.
Published by Yaw Labs.