MCP Dependency Review

2. Parse without executing

Read JSON or configuration text and identify each configured MCP server. For package-runner invocations such as npx, npm exec, bunx, bun x, pnpm dlx, or yarn dlx, isolate every package selector from command-line flags.

Package-valued flags count as package selectors too. For example, in npx --package ecc-universal ecc, classify ecc-universal as the package selector and treat ecc as the executable. If multiple package-valued flags are present, review every supplied package selector.

For docker run and docker container run, isolate the image separately from Docker options and the in-container command. For example, docker run --rm -i example/server:1.2.3 serve selects example/server:1.2.3, not serve. Account for option values before the image; do not treat a volume, environment value, or option argument as the image. Inspect an explicit image field in equivalent configuration as an image reference too.

For uvx (including uv tool run), classify the package from --from; for pipx run, classify the package from --spec. For example, uvx --from example-tool==1.2.3 example-command and pipx run --spec example-tool==1.2.3 example-command both select example-tool==1.2.3; example-command is the executable. Accept both separated flag values and --from=SPEC / --spec=SPEC forms. Without those flags, isolate the tool/package selector (uvx example-tool@1.2.3 or pipx run example-tool) from subsequent executable arguments. Review additional package-bearing options such as uv's --with separately when their syntax is clear.

If the invocation, option boundaries, or selector syntax is unsupported or ambiguous, report REVIEW and never omit the configured server, guess a selected package, or execute the command to resolve uncertainty. Editable installs, direct URLs, VCS sources, shell wrappers, and uncertain executable-to-package mappings require REVIEW.

Never execute the discovered command to learn what it does.

3. Classify the selector

Apply the static classification table above. Treat any npm distribution tag, not only latest, as HIGH. If the syntax is ambiguous, return REVIEW rather than guessing.

4. Recommend a reproducible fix

For mutable selectors, recommend an exact package version that the team has actually reviewed.

Do not invent a pin by substituting today's latest registry version. If the reviewed version is unknown, say so. A registry-history lookup is a separate network operation and should only be performed when the user asks for it.

5. Produce a bounded report

Use a compact table:

End with these boundaries:

• No MCP servers were executed during this review.
• Mutable dependency references are reproducibility/review signals, not breach claims.
• SAFE means the direct selector is exact; it does not establish full transitive dependency reproducibility.
• A clean result here is not a complete MCP security assessment.

Example

Given:

{
  "mcpServers": {
    "browser": {
      "command": "npx",
      "args": ["-y", "example-browser-mcp@latest"]
    }
  }
}

Report:

.mcp.json | browser | example-browser-mcp@latest | HIGH
Reason: @latest can resolve to different package code later without a config diff.
Next: pin the exact version the team reviews and update it deliberately.

Anti-Patterns

Calling every mutable reference a vulnerability

Wrong: @latest means the MCP package is compromised.

Better: @latest means the configuration does not fully determine which package version will run later. Establish actual security impact separately.

Pinning whatever is latest today

Wrong: replace a mutable selector with the current registry version and call the review fixed.

Better: pin a version the team has reviewed. If that evidence is unavailable, record the uncertainty.

Expanding scope silently

Wrong: a repo review automatically scans user-level Claude, Cursor, or VS Code configuration.

Better: remain workspace-scoped unless machine-wide review is explicitly requested.

Treating a clean drift review as complete MCP security

Exact direct dependency pins do not prove full transitive reproducibility, safe authorization, prompt-injection resistance, package provenance, secure implementation, or runtime isolation.

Related Skills

• mcp-server-patterns — MCP server design, tools, resources, prompts, and transports.
• security-review — broader application-security checklist.
• security-scan — broader security scanning workflow.

Further Reading

A public reference implementation and reproducible research methodology for this narrow review class are available in MCP Drift Check. The external project is optional; this ECC skill does not require it to perform the static review.