Run npm registry operations from Claude Code, Cursor or any MCP client - package intelligence, security audits, dependency analysis, and the write ops that normally fight you locally.
@yawlabs/npmjs-mcp covers the npm registry HTTP surface as MCP tools: reads, writes, orgs, teams, hooks, provenance, trusted publishers and ops health. Other npm MCP servers wrap npm search and call it done; this one includes npm_deprecate, npm_dist_tag_set, npm_owner_add and npm_unpublish_version. Built and maintained by Yaw Labs, MIT licensed, published on npm.
npx -y @yawlabs/npmjs-mcp@latestGitHub · npm · Add to Yaw MCP
Two audiences, and the same server serves both. If you consume packages, this is the fastest way to ask real questions about a dependency before you take it on. If you publish packages, it is the write path that does not collapse in a non-interactive session - the registry HTTP API with your token, rather than a CLI built around an interactive 2FA prompt.
--otp hunt, no login loop.1. Add the server to your client. Reads need no credentials at all, so this config is enough to start. On macOS, Linux and WSL, a .mcp.json in your project root:
{
"mcpServers": {
"npm": {
"command": "npx",
"args": ["-y", "@yawlabs/npmjs-mcp@latest"]
}
}
}On Windows, wrap the call in cmd /c: npx is a .cmd file there, and Node 20+ refuses to spawn .cmd files directly.
{
"mcpServers": {
"npm": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@yawlabs/npmjs-mcp@latest"]
}
}
}2. Restart and approve. Restart Claude Code (or your MCP client) and approve the npm server when prompted.
3. Add a token only if you want writes. The write, auth, org, access and hook tools need NPM_TOKEN in the env block. Use a Granular Access Token scoped to just the packages and orgs you want your agent to manage.
{
"mcpServers": {
"npm": {
"command": "npx",
"args": ["-y", "@yawlabs/npmjs-mcp@latest"],
"env": {
"NPM_TOKEN": "npm_xxxxxxxxxxxx"
}
}
}
}The same JSON block works in Claude Desktop, Cursor, Windsurf and VS Code - only the config file path changes. Point at a private or enterprise registry with NPM_REGISTRY, as long as it serves the npm HTTP API shape.
Running Yaw MCP? One click adds it to your local config, and it is then available in every Yaw Terminal session.
Tools are grouped by what they touch. Search, packages, dependencies, downloads, security, analysis, registry and provenance all work anonymously; the auth, access and orgs, write operations and webhooks groups need NPM_TOKEN:
| Group | What it covers |
|---|---|
search | Search the registry with qualifiers - keywords, author, scope |
packages | Package and version metadata, all published versions with dates, README content, dist-tags, TypeScript type support |
dependencies | Prod, dev, peer and optional dependency lists, the transitive tree at a depth you choose, and a license audit of a package and its direct deps |
downloads | Totals for a period, daily breakdowns, per-version counts, and a bulk compare across many packages at once |
security | Known-vulnerability checks, a deep audit with CVSS scores, CWEs and fix recommendations, and the registry signing keys |
analysis | Side-by-side package comparison, a maintenance and health summary, maintainers with publish history, release cadence and gaps |
registry | npm-wide download totals, recent publishes from the changes feed, and the ops playbook - the tool to call first when you are unsure which path to take |
provenance | Sigstore attestations and OIDC trust relationships with CI/CD providers |
auth | Authenticated user, profile and 2FA status, token list, packages published by a user, and a one-call token capability check |
access and orgs | Package collaborators and access settings, org members and roles, org packages, teams and team membership |
workflows | An auth health check with headless publish feasibility, and a pre-publish validation checklist |
write operations | Deprecate and undeprecate, unpublish a version or a package, set and remove dist-tags, add and remove owners, set access and 2FA policy, grant and revoke team permissions, create and delete teams, manage team and org membership, revoke a token |
webhooks | Register, list, fetch, update and delete webhooks on a package, scope or user |
Two of these are worth calling first rather than last. npm_ops_playbook returns the canonical tool-versus-CLI-versus-CI decision matrix, so an agent picks the right path on the first try instead of discovering it through failures. npm_verify_token answers "what can this token actually do" in one call, which is the real question behind most write failures.
confirm: true, npm_owner_remove blocks you from locking yourself out, and npm_dist_tag_remove refuses to remove latest.readOnlyHint, destructiveHint, idempotentHint and openWorldHint let a client skip confirmation on safe ops and require it on the rest.npm_deprecate enforces the registry's 1024-character limit; punctuation is not constrained by the tool. If the registry returns a 422 anyway, the two usual causes are the message format - an em-dash and no trailing period is what has worked - and a version range that matches nothing published.npx start.Not everything belongs in an MCP tool, and the server says so itself. This is the matrix npm_ops_playbook returns:
| Operation | Preferred path | Why |
|---|---|---|
| Read - search, view, stats | These MCP tools, no auth | Fast, zero friction |
| Deprecate, dist-tag, owner, team, hook | The matching MCP tool | HTTP API, no CLI 2FA friction |
| Publish | A release script on your workstation | Not an MCP tool. Note that a workstation publish carries no sigstore provenance - --provenance needs CI OIDC |
| Unpublish | npm_unpublish_version with confirm: true | Safer than the CLI, and irreversible within 72h either way |
| CLI fallback, rarely | npm login --auth-type=web, then the CLI op | Only when the MCP tool returns a 422 |
The published command is a launcher that prefers the oam runtime and falls back to Node. If you do not have oam, nothing changes: npm has already started Node to run the launcher, so the fallback is an in-process import rather than another spawn. The server is a pre-bundled ESM file using only node: builtins, and both paths are verified against the full MCP surface - handshake, every tool, live registry calls.
Worth knowing if you are chasing startup time: oam is faster than Node, but the launcher is not. npm bin entries are Node scripts, so reaching oam through one costs Node's startup plus oam's - more than oam saves. The launcher exists so npx users get oam automatically, not because it is the fast path. If you want the speed, point your MCP host straight at oam run and skip the launcher, or pin the behaviour with NPMJS_MCP_RUNTIME.
It puts the npm registry HTTP API behind MCP tools: search, package and version metadata, dependency trees, license checks, download stats, security audits, maintainer and release-cadence analysis, provenance and trusted publishers, orgs and teams, webhooks, and the write operations - deprecate, dist-tag, owner, access, unpublish - that normally fight you from the CLI.
Not for reads. Search, package metadata, downloads, security audits, dependency trees and license checks all work anonymously. Auth is opt-in: set NPM_TOKEN in the env block of your client config to unlock the write, auth, org, access and hook tools. Use a Granular Access Token scoped to just the packages and orgs you want the agent to manage.
The write tools call the registry HTTP API directly with your token, so they skip the CLI friction that breaks agent sessions: no 2FA prompt, no --otp hunt, no ENEEDAUTH from a session-bound .npmrc. When an operation genuinely needs a human, the tools detect the non-interactive context and return the specific command to run instead of looping on an unrecoverable error.
The destructive tools are gated. Both unpublish tools require confirm set to true, npm_owner_remove refuses to lock you out of your own package, and npm_dist_tag_remove refuses to remove latest. Every tool also declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint, so your client can skip confirmation on safe reads and require it on writes.
No, and that is deliberate. The decision matrix the server ships - returned by npm_ops_playbook - routes publishing to a release script on your workstation rather than an MCP tool, and notes that a workstation publish carries no sigstore provenance because the provenance flag needs CI OIDC. Use the tools for deprecate, dist-tag, owner, team and hook operations, and the CLI for publish.
Published by Yaw Labs.