Show HN: MCPShield – Supply chain security scanner for MCP servers(github.com)
github.com
Show HN: MCPShield – Supply chain security scanner for MCP servers
https://github.com/mcpshield/mcpshield
3 comments
The supply chain angle is the right framing — the typosquat example with mcp-servr-github is exactly the kind of thing that's hard to catch manually.
One thing I've been thinking about in this space: static scanning at install time is necessary but not sufficient. A server can pass a clean scan and still behave dangerously at runtime — either because it changes its tool descriptions after installation (the MCP rug pull attack Invariant Labs documented), or because two individually safe tools create a dangerous combination when chained together. Email access alone is fine. Web browser alone is fine. Together they're a data exfiltration path that no static scanner would flag.
Curious whether MCPShield has any plans to address chaining and runtime behavior, or if the focus is intentionally on the pre-deployment supply chain problem?
The npm comparison is right but I'd argue you're being generous. At least npm had years before the malicious package wave hit. MCP is getting it within months of going mainstream.
Thing is — your scanner catches the dumb mistakes (eval on untrusted input, hardcoded creds). Those devs are careless. The scarier category is servers with zero code vulns because they were written specifically to be malicious. Clean repo, good README, useful-sounding tool name. Passes every static check. Then on day 7 after it's in a thousand configs, the tool description quietly gets a new paragraph that the LLM reads as instructions.
You can't lint your way out of that. It's a trust problem not a code quality problem.
Does MCPShield do any post-install monitoring or is it purely a before you pull the trigger tool?
Thing is — your scanner catches the dumb mistakes (eval on untrusted input, hardcoded creds). Those devs are careless. The scarier category is servers with zero code vulns because they were written specifically to be malicious. Clean repo, good README, useful-sounding tool name. Passes every static check. Then on day 7 after it's in a thousand configs, the tool description quietly gets a new paragraph that the LLM reads as instructions.
You can't lint your way out of that. It's a trust problem not a code quality problem.
Does MCPShield do any post-install monitoring or is it purely a before you pull the trigger tool?
We built MCPShield because we kept seeing the same problems in MCP configs:
Typosquat packages that steal credentials (we found mcp-servr-github harvesting env vars) Known CVEs in Anthropic's own Git MCP server (CVE-2025-68145, RCE via prompt injection) Hardcoded database passwords visible to LLMs in tool metadata Agents with access to ~/.ssh and ~/.aws
The MCP ecosystem is following the same trajectory as npm/PyPI — rapid adoption with minimal vetting. 88% of orgs deploying AI agents have had security incidents. MCPShield scans your claude_desktop_config.json (or Cursor/VS Code config) and catches these before deployment. Zero dependencies, works offline, CI/CD-ready. We built this in the open because MCP security is a collective action problem. PRs and CVE reports welcome.
Typosquat packages that steal credentials (we found mcp-servr-github harvesting env vars) Known CVEs in Anthropic's own Git MCP server (CVE-2025-68145, RCE via prompt injection) Hardcoded database passwords visible to LLMs in tool metadata Agents with access to ~/.ssh and ~/.aws
The MCP ecosystem is following the same trajectory as npm/PyPI — rapid adoption with minimal vetting. 88% of orgs deploying AI agents have had security incidents. MCPShield scans your claude_desktop_config.json (or Cursor/VS Code config) and catches these before deployment. Zero dependencies, works offline, CI/CD-ready. We built this in the open because MCP security is a collective action problem. PRs and CVE reports welcome.