name: supply-chain-analyzer
description: Evaluates MCP server supply chain risk - wrapper scripts, typosquatting, unsigned binaries, auto-update vectors, and dependency confusion. Use when user asks to "check if this MCP server is safe", "verify MCP dependencies", "audit MCP supply chain", or "is this npm package legit".
metadata:
author: oktsec
version: 1.0.0
license: Apache-2.0

MCP Supply Chain Analyzer

Every MCP server is code that runs on your machine with your permissions. Verify it's what you think it is.

Instructions

Step 1: Identify the target

The user provides either:
- An MCP server name/package (@modelcontextprotocol/server-filesystem)
- A command from their config (npx some-mcp-server)
- A binary path (/usr/local/bin/my-mcp-server)

Step 2: Analyze the supply chain

Run these checks:

Binary verification:
1. Resolve the full path: which <command> or check the npm/pip package location
2. Check file type: file <path> - is it a compiled binary, script, or symlink?
3. If it's a shell script or wrapper, read the contents - does it download or execute anything?
4. Check if the binary is signed (macOS: codesign -v, Linux: check package manager provenance)

Package analysis (npm/pip):
1. Check package name for typosquatting:
- Compare with the official package name character by character
- Look for common swaps: - vs _, 0 vs o, l vs 1
- Check if the package scope (@org/) is the official one
2. Check version pinning:
- npx package (BAD - unpinned, auto-updates)
- npx [email protected] (GOOD - pinned)
- npx package@latest (BAD - explicit latest)
3. Check package metadata:
- Published date (newly published packages are higher risk)
- Download count (very low downloads for a "popular" server is suspicious)
- Maintainer count (single maintainer with no history is higher risk)
- Repository link (should exist and match the package name)

Configuration analysis:
1. Does the config use --allow-all or equivalent wide permissions?
2. Are there post-install scripts in the package? (npm show <pkg> scripts)
3. Does the server declare more tools than expected for its function?
4. Are there env vars being passed that the server shouldn't need?

Runtime behavior (if observable):
1. Does the server make outbound network requests beyond its stated purpose?
2. Does it read files outside its declared scope?
3. Does it spawn child processes?

Step 3: Risk assessment

Score the server:

Step 4: Output report

## Supply Chain Analysis: [server-name]

**Package:** [full package name with version]
**Transport:** [stdio / http]
**Source:** [npm / pip / binary / git]

### Checks

| Check | Status | Detail |
|-------|--------|--------|
| Version pinned | [pass/fail] | [version or "unpinned"] |
| Typosquatting | [pass/fail] | [analysis] |
| Binary type | [info] | [compiled/script/wrapper] |
| Code signing | [pass/fail/n-a] | [detail] |
| Permission scope | [pass/fail] | [what it can access] |
| Package provenance | [pass/fail] | [publisher, downloads, age] |

### Risk: [CRITICAL/HIGH/MEDIUM/LOW/CLEAN]

### Recommendations
1. [First action]
2. [Second action]

Examples

Example 1: Check a new MCP server

User: "Is @anthropic/mcp-server-fetch safe to use?"

1. Verify package scope is @anthropic (official)
2. Check npm for publish date, downloads, maintainers
3. Check if version is pinned in user's config
4. Report: CLEAN if official + pinned, MEDIUM if unpinned

Example 2: Unknown binary

User: "I found this MCP server in my config: /Users/me/.local/bin/analytics-mcp"

1. Run file on the binary
2. Check if it's a wrapper script
3. If script, read contents for downloads/execution
4. Check who owns the file and when it was modified
5. Report findings

Common Issues

Can't access npm registry

If offline or restricted, analyze what's available locally: the binary, the config, and the file metadata. Note that package verification couldn't be completed.

Server is from a private registry

For private/company registries, the supply chain risk model changes. Focus on binary verification and permission scoping rather than public package metrics.