Appearance
Why It Matters
Committed MCP configs are executable setup, not just prose. When a config launches a server through npx, uvx, pnpm dlx, yarn dlx, or pipx run, the repo does not fully describe what code will run. The package can resolve differently on another machine, after a registry update, or when @latest moves.
What Triggers
SEC329 applies to committed MCP configuration JSON and triggers when command/args analysis finds a dynamic package launcher such as:
npxuvxpnpm dlxyarn dlxpipx run
Examples that trigger:
json
{"command":"npx","args":["@cloudbase/cloudbase-mcp@latest"]}json
{"command":"uvx","args":["demo-mcp"]}Examples that stay clean:
json
{"command":"./scripts/run-mcp.sh","args":[]}json
{"command":"node","args":["./vendor/mcp-server/index.js"]}False Positives
False positives should be low because the detector is structural and gated on parsed MCP config. The practical tradeoff is not "did the pattern exist", but whether a team intentionally accepts runtime package resolution in committed config. The rule stays useful because it points at real execution posture, not generic documentation advice.
Remediation
Replace the dynamic package launch with a vendored script, pinned local binary path, or another reproducible execution path that does not resolve packages dynamically at runtime.