Package Provenance Checks Before Installing MCP Servers
Verify MCP server package provenance before Claude Code installation: registry publisher match, repository ownership, release artifact checksums, maintainer history, and rollback when supply-chain signals fail review.
Open the source and read safety notes before installing.
Safety notes
- Unverified packages execute with user privileges in stdio mode—provenance review is not optional for production repos.
- Registry listings describe intent but do not replace maintainer security audit.
- Typosquat package names can mimic popular servers—verify exact publisher coordinates.
Privacy notes
- Provenance notes may reference private registry URLs—keep internal hostnames out of public tickets.
- Checksum logs should not include OAuth tokens or .env contents.
- Vendor privacy policies apply when servers phone home—review before enterprise rollout.
Prerequisites
- Target MCP server registry entry or repository URL identified.
- Access to npm, PyPI, or git release artifacts for checksum verification.
- Isolated Claude Code test profile with non-production credentials.
- Team policy defining acceptable third-party publishers.
Schema details
- Install type
- copy
- Reading time
- 8 min
- Difficulty score
- 52
- Troubleshooting
- Yes
- Breaking changes
- No
Full copyable content
Before claude mcp add, compare registry metadata to upstream repo, verify publisher identity, record checksum or commit SHA, test in an isolated profile, then commit pinned .mcp.json only after provenance review passes.About this resource
TL;DR
Verify MCP package provenance and publisher trust before adding servers to Claude Code.
Prerequisites & Requirements
- {"task": "Check", "description": "Target MCP server registry entry or repository URL identified."}
- {"task": "Check", "description": "Access to npm, PyPI, or git release artifacts for checksum verification."}
- {"task": "Check", "description": "Isolated Claude Code test profile with non-production credentials."}
- {"task": "Check", "description": "Team policy defining acceptable third-party publishers."}
Core Concepts Explained
Registry entry vs upstream repo
Registry metadata links to intended packages; provenance review confirms the linked repository, npm scope, or binary publisher matches expectations.
Checksum and commit pins
Record npm package integrity, git tag SHA, or release artifact hash before
adding the server to shared .mcp.json.
Trust is operator responsibility
Official security documentation places verification on the operator installing third-party MCP servers.
Step-by-Step Implementation Guide
Collect discovery artifacts. Save registry URL, README install command, and declared tools/resources list.
Verify publisher identity. Match npm scope, GitHub org, or vendor domain to your allowlist policy.
Fetch release artifact. Download the pinned version locally; record SHA256 or git commit.
Compare install command. Ensure
claude mcp addargs reference the verified artifact, not a floating@latestalias.Run threat-model checklist. Cross-check with
threat-model-mcp-servers-before-installation.Test in isolated profile. Start server under MCP_TIMEOUT; exercise one read-only tool.
Commit pin and provenance note. Document publisher, version, checksum, and reviewer in team docs or PR.
Plan rollback. Revert
.mcp.json, clear OAuth, and delete local server state.
Troubleshooting
Registry publisher differs from npm scope
Stop install; open issue with upstream or pick an alternate server.
Checksum mismatch on re-download
Treat as supply-chain alert; do not install until maintainer explains drift.
Teammate skipped provenance step
Block merge until provenance fields exist in .mcp.json PR template.
Source Verification Notes
Verified against official documentation on 2026-06-16:
- MCP quickstart docs describe adding servers via CLI and .mcp.json project sharing.
- MCP registry catalogs servers with publisher metadata for discovery.
- Claude Code security docs state Anthropic does not security-audit third-party MCP servers.
- Teams should verify publisher, repository, and release artifact before install.
- Rollback removes .mmp.json entries and revokes OAuth via /mcp when applicable.
Duplicate Check
Complements pinning-mcp-server-packages-before-installation (version pins) and threat-model-mcp-servers-before-installation (trust boundaries). This guide focuses on publisher and artifact provenance before first install.
References
- Primary documentation - https://code.claude.com/docs/en/mcp-quickstart
Source citations
Add this badge to your README
Show that Package Provenance Checks Before Installing MCP Servers is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/guides/package-provenance-checks-before-installing-mcp-servers)How it compares
Package Provenance Checks Before Installing MCP Servers side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Package Provenance Checks Before Installing MCP Servers Verify MCP server package provenance before Claude Code installation: registry publisher match, repository ownership, release artifact checksums, maintainer history, and rollback when supply-chain signals fail review. Open dossier | Pinning MCP Server Packages Before Installation Pin MCP server package versions before adding them to Claude Code: registry verification, lockfile discipline, npx package pins, supply-chain review, and rollback steps aligned to MCP quickstart and registry documentation. Open dossier | Auditing MCP Client Configuration Before Team Rollout Source-backed checklist for reviewing Claude Code MCP client configuration before a team rollout, covering scopes, transports, commands, secrets, allowlists, denylists, approvals, and rollback. Open dossier | Security Guidance Plugin Before Merge Install and use the official Claude Code security-guidance plugin before merge: per-edit pattern warnings, end-of-turn and commit git-diff review, and team rollout for command injection, XSS, eval, and dangerous file edits. Open dossier |
|---|---|---|---|---|
| Trust | ||||
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Category | guides | guides | guides | guides |
| Source | source-backed | source-backed | source-backed | source-backed |
| Author | kiannidev | kiannidev | YB0y | kiannidev |
| Added | 2026-06-16 | 2026-06-16 | 2026-06-10 | 2026-06-16 |
| Platforms | Claude Code | Claude Code | Claude Code | Claude Code |
| Source repo | — | — | — | — |
| Safety notes | ✓Unverified packages execute with user privileges in stdio mode—provenance review is not optional for production repos. Registry listings describe intent but do not replace maintainer security audit. Typosquat package names can mimic popular servers—verify exact publisher coordinates. | ✓Unpinned npx -y installs can pull new semver-compatible releases without review. Registry listings describe intent but do not replace maintainer security review. Do not pipe curl-to-shell install scripts without reading the pinned release artifact. | ✓Local stdio MCP servers execute commands with the user's privileges, so review the exact command, arguments, package runner, file paths, and network behavior before sharing a config. Remote MCP servers can expose model-controlled tools for production systems; require least-privilege scopes, explicit approval for write tools, and a rollback path before team rollout. Do not rely on server names alone for enforcement because names are user-assigned labels; use command or URL allowlist entries when policy must control what actually runs. | ✓Hook pattern matching can miss novel attack classes; combine with code review and CI scanners. Stop-time git-diff LLM review adds latency and may produce false positives on refactors. Plugins run with session permissions; compromised plugin sources are a supply-chain risk—pin trusted marketplaces. Security guidance warns about risky patterns but does not block merges automatically unless paired with deny hooks. |
| Privacy notes | ✓Provenance notes may reference private registry URLs—keep internal hostnames out of public tickets. Checksum logs should not include OAuth tokens or .env contents. Vendor privacy policies apply when servers phone home—review before enterprise rollout. | ✓Pinned versions should be documented in git; avoid embedding API keys in the same commit. Test profiles prevent accidental production credential use during pin validation. Registry metadata may link to vendor privacy policies—review before enterprise rollout. | ✓MCP client configuration can reveal server URLs, internal hostnames, command paths, environment-variable names, header names, OAuth client IDs, and tool availability. Do not store API keys, bearer tokens, client secrets, tenant IDs, or personal credentials in shared `.mcp.json`, managed-mcp.json, PR bodies, issue comments, logs, or screenshots. Tool arguments, tool results, resources, prompts, logs, traces, and OAuth metadata can expose private repositories, tickets, databases, user identities, and workspace data. | ✓Hook scripts inspect edited file paths, diffs, and prompt text that may contain proprietary code. Git-diff review at session stop transmits change summaries to the configured model provider per normal Claude Code data handling. Shared plugin settings in git expose which security patterns your team monitors. |
| Prerequisites |
|
|
|
|
| Install | — | — | — | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Signals
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.