npm name reservations — ADO #2823

This package is not the TATER MCP server. It exists to hold two names so that nobody else can.

TATER Security's help documentation instructed administrators to run npx -y @tater-security/mcp-server. That name was unregistered, and npx -y installs and executes whatever the registry serves for a name — with TATER_API_KEY and TATER_ORG_ID in the process environment. The docs have since been fixed; publishing this reservation is what removes the exposure, because a fixed doc does nothing about cached configs, bookmarks and blog posts.

The two names, and why they are not equally urgent

| name | why | |---|---| | @tater-security/mcp-server | Closes a real exposure. This is the name live npx -y instructions actually used. | | tater-mcp | Defensive. No current instruction names it, but older docs did, and tater-mcp/package.json in this repo is literally named that. |

Measured 2026-09-11: both still return 404 from the registry, so neither has been taken.

Publishing

Prerequisites, both yours:

1. The tater-security org must exist on npm. Create it at https://www.npmjs.com/org/create. There is no npm org create command — npm org only has set, rm and ls. Publishing a scoped package into a scope that does not exist fails.
2. This machine must be logged in — npm login. The publish script will not handle credentials and refuses to run without a login.

Then:

cd tools/npm-name-claim
./publish-claims.sh              # dry run — shows exactly what would be published
./publish-claims.sh --publish    # for real

The script publishes the same content under both names, generating the second into a temp directory so the repo is never mutated. It re-checks availability immediately before publishing and stops, naming the owner, if either name has been taken by someone else — at that point it is a supply-chain incident, not a publishing hiccup.

2FA, and the Enter OTP: prompt that never resolves

If your 2FA is a security key, there is no code to type, and waiting for one is the trap. npm's otplease (lib/utils/auth.js) has two branches:

• web — when the registry answers EOTP with authUrl and doneUrl, npm opens a browser and the WebAuthn ceremony happens there. This is the path a security key needs, and it covers npm publish, not just npm login.
• classic — otherwise it falls back to Enter OTP: and blocks on a TOTP code. If the account has no TOTP method enrolled, nothing will ever arrive.

auth-type defaults to web on npm 9+, so normally the first branch is taken. If you land on the prompt anyway, force it:

npm login --auth-type=web

If no browser can be opened, npm prints the URL to paste into one (lib/utils/open-url.js: "attempt to open URL in web-browser, print address otherwise").

Fallback for a headless box or CI: create a Granular Access Token on npmjs.com with write access to the scope and put it in ~/.npmrc yourself. Automation tokens bypass the per-publish 2FA prompt entirely — that is what they are for.

Either way, run the publish yourself: this script will not touch a credential.

Publishing is effectively irreversible. npm's unpublish window is narrow and the name stays burned afterwards either way. The dry run is the default for that reason.

Afterwards

npm view @tater-security/mcp-server maintainers
npm view tater-mcp maintainers

Then run the misuse path itself, which is the check that matters — a stale config or old doc will do exactly this:

npx -y @tater-security/mcp-server     # must print the reservation message, exit 1
npx -y tater-mcp                      # same

Exit 1 is deliberate: a script that invokes it fails loudly rather than continuing as though a server started.

Testing a LOCAL tarball before publishing: use a file: spec — npx --yes file:/path/to/pkg.tgz. A bare absolute path is NOT parsed as a package spec; the shell tries to execute the .tgz itself and fails with exit 126, Permission denied. That reads exactly like a broken package and is not — it cost a false alarm on 2026-09-11, caught only by printing the raw output instead of a filtered grep that came back empty.

Then close ADO #2823.

If this is ever replaced by the real server

Publish from CI with npm publish --provenance, and update tools/check-doc-npm-packages.js so the docs gate recognises the publishing account as TATER-owned. Note tater-mcp/package.json carries "private": true (also #2823) so a stray npm publish in that directory cannot ship the real server — libnpmpublish refuses unconditionally. Removing that flag should be a deliberate decision, not a step in a hurry.