crux mcp add: no package validation before registration

[kaushalpaneri]

Bug Report

Description

crux mcp add registers MCP servers with a ✅ success message even when the underlying package doesn't exist, is broken, or has never been verified to actually install and run.

Two Distinct Failures

Failure 1: Package doesn't exist on registry

crux mcp add foo --npx nonexistent-package-xyz
# Output: ✅ Registered MCP 'foo'
# But `npx -y nonexistent-package-xyz` fails with E404 — package not on npm

crux mcp add jobspy --uvx jobspy-mcp-server
# Output: ✅ Registered MCP 'jobspy'
# But `uvx jobspy-mcp-server` fails — only version was yanked from PyPI

Expected: Crux should check the package exists on the registry before saying ✅.

Failure 2: npx/uvx never actually runs at registration time

Even for packages that DO exist, crux mcp add --npx <pkg> only writes the package name to registry.json. It never actually runs npx -y <pkg> to:

• Download and cache the package
• Verify it installs without errors
• Verify the binary/entrypoint exists

This means the first time the package actually runs is when an agent invokes it — and if it fails (wrong Node version, missing native deps, incompatible platform), the agent fails mid-task.

Similarly, crux mcp add --uvx <pkg> never runs uvx <pkg> to pre-install and validate.

Steps to Reproduce

# Register a real npm package
crux mcp add playwright --npx @playwright/mcp
# Output: ✅ Registered MCP 'playwright'
# But @playwright/mcp is NOT actually downloaded/cached yet
# First real download happens when an agent uses it

# Register a real uvx package
crux mcp add postgres --uvx postgres-mcp
# Output: ✅ Registered MCP 'postgres'
# But postgres-mcp is NOT actually installed yet
# First install attempt happens at runtime — and in this case,
# it FAILS because pglast C extension doesn't compile on Python 3.14

Expected Behavior

crux mcp add --npx <pkg> should:

1. Run npx -y <pkg> --help (or equivalent dry-run) to verify the package downloads and the entrypoint exists
2. If it fails, report the error and don't register
3. If it succeeds, cache the package and register

crux mcp add --uvx <pkg> should:

1. Run uvx <pkg> --help (or equivalent) to verify installation
2. If it fails (yanked version, build error, incompatible Python), report and don't register
3. If it succeeds, register

Actual Behavior

Registration is purely a write to registry.json. No validation, no download, no installation. All failures are deferred to runtime.

Impact

During a real setup session:

• jobspy-mcp-server via --npx: registered ✅, but npm package doesn't exist (E404)
• jobspy-mcp-server via --uvx: registered ✅, but only PyPI version was yanked
• postgres-mcp via --uvx: registered ✅, but pglast fails to compile on Python 3.14

All three showed ✅ at registration. All three were broken. Discovered only through manual testing.

Environment

• crux-cli version: latest
• macOS (Apple Silicon)
• Node.js v25.8.1
• Python 3.14

[raye-deng]

Great bug report — this is exactly the kind of silent failure that causes headaches in production.

We ran into the same class of problem with AI-generated code: Claude Code would add npx @playwright/test-utils to a project, the build passes, tests pass locally with mocked imports, then CI explodes because the package doesn't exist on npm. The difference from your case is that there's no crux mcp add step to blame — the AI just fabricates the dependency directly in the source code.

The root cause is the same though: blind trust in package names without registry validation. Whether it's a tool registering MCP servers or an AI writing import statements, the fix is always "actually try to resolve the package before accepting the name."

For crux specifically, a pragmatic approach:

1. Registry check at registration — npm view <pkg> for npx, pip index versions <pkg> for uvx. Fast, catches obvious typos and non-existent packages.
2. Dry-run install — npx -y <pkg> --help (with a short timeout). Catches broken/yanked packages and incompatible platforms.
3. Fail loudly, not silently — If step 1 or 2 fails, the user needs to know why, not just see ✅ and discover the problem later.

We built Open Code Review specifically to catch this category of AI-specific defects (hallucinated packages, deprecated APIs, phantom imports). It scans for packages that look like real dependencies but don't resolve on any registry. Worth a look if you want an automated safety net beyond the registration-time check:

npx @opencodereview/cli scan . --sla L1

The MCP ecosystem is growing fast and package quality varies wildly. Having validation at the tool level would prevent a lot of broken agent setups.