MCP scanning gaps: are your controls keeping up?

TL;DR: Several public MCP security scanners returned clean or zero-finding results even when malicious servers could steal credentials or execute commands at runtime, according to Pluto Security research after testing five public MCP security scanners. The result shows that scan coverage, not just scan outcome, determines whether an MCP check is actually meaningful.

Editorial analysis by NHI Mgmt Group, based on content published by Pluto Security: “Malicious Servers, Clean Scans: The Dangerous Illusion of a Clean MCP Scan”.

Key questions

Q: What breaks when an MCP scanner only checks metadata?

A: It misses the server’s real behavior at tool-call time.

Q: Why does incomplete MCP scanning create false confidence?

A: Because the result reflects the evidence the scanner actually saw, not the whole server.

Q: How should teams evaluate an MCP server before production use?

A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions.

Practitioner guidance

• Validate scan coverage before trusting results Record whether the scanner inspected metadata, source files, dependency context, tool output, and runtime behavior.
• Test unknown MCP servers in isolation Run new servers in a sandbox with fake credentials, a temporary home directory, and restricted network access so you can observe what they touch when tools are called.
• Pin and review the exact server version Track the commit, package hash, and update path for every server you allow, because behavior can change after installation even when the tool name stays the same.

Bottom line: MCP scanners can miss malicious behavior when they inspect only metadata or an incomplete slice of source code.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →