MCP servers have no provenance verification — supply chain risk

Problem

MCP servers are arbitrary code that receive user credentials (API tokens, OAuth secrets, etc.) but there is no mechanism to verify their provenance, authenticity, or integrity.

Current state

• MCP servers are identified by name only (e.g., "atlassian", "grafana"). Names are not namespaced or reserved.
• Multiple unrelated packages can use the same server name across registries (pip, npm, Homebrew). For example, sooperset/mcp-atlassian (community) vs atlassian/atlassian-mcp-server (different project) — both called "atlassian."
• There is no signing, hash verification, or provenance attestation for installed MCP servers.
• brew info, pip show, npm info report self-declared metadata — a malicious package can claim any homepage URL.
• Typosquatting is trivial: mcp-atlassian vs mcp-atlaissian vs atlassian-mcp.
• There is no built-in way in Claude Code to inspect which binary/package is backing an MCP server, or to verify it matches what the user intended to install.

What MCP servers have access to

• API tokens and OAuth credentials configured by the user
• Read/write access to external services (Confluence, Jira, Grafana, GitHub, etc.)
• Ability to act on behalf of the user in those services
• No sandboxing or capability restrictions beyond what tools the server exposes

Impact

A compromised, typosquatted, or impersonated MCP package could:

• Exfiltrate all configured API tokens silently
• Read/write to external services on behalf of the user
• Persist access via the tokens even after the package is removed

The user has no way to distinguish a legitimate MCP server from a malicious one with the same name.

Suggested mitigations

These are just ideas — the right approach depends on the MCP ecosystem's direction:

1. Provenance display: claude mcp list could show the resolved binary path, package version, source registry, and homepage for each configured server. At minimum, make it easy to answer "what code am I actually running?"
2. Package hash pinning: Allow MCP configs to pin a package hash or version, and warn if the resolved package doesn't match.
3. Curated registry / verified publishers: Flag servers from known publishers vs unknown community packages.
4. First-run audit prompt: On first use of a new MCP server, show the user what package it resolved to and ask for confirmation.
5. Capability scoping: Allow users to restrict what credentials/tools an MCP server can access, rather than giving it blanket access to everything configured.

Context

Discovered while trying to determine which mcp-atlassian package was installed — brew info showed sooperset/mcp-atlassian but there was no way to determine this from within Claude Code itself. The server name "atlassian" gave no indication of the author, and it was easy to confuse with a completely different project (atlassian/atlassian-mcp-server).