MCP-SEC: Automated Security Analysis

• MCP-SEC is an automated framework that systematically crawls MCP servers and tools to assess their risk through metadata collection and LLM-based analysis.
• It uses a dual-module design—collecting tool descriptions and applying a unanimous voting mechanism among three LLMs—to accurately label capabilities.
• The framework quantifies ecosystem risks, revealing that 46.41% of tools expose vulnerabilities due to systemic issues like lack of isolation and least-privilege enforcement.

MCP-SEC is an automated security analysis framework for the Model Context Protocol (MCP) ecosystem, introduced to systematically crawl, analyze, and assess MCP servers and their exposed tools for vulnerabilities that can be combined in parasitic toolchain attacks such as MCP Unintended Privacy Disclosure (MCP-UPD). In "Mind Your Server: A Systematic Study of Parasitic Toolchain Attacks on the MCP Ecosystem," it serves as the basis for the first large-scale, empirical security census of the emerging MCP ecosystem, linking tool metadata collection to LLM-based capability analysis and quantifying the prevalence and composability of risky tools across live servers (Zhao et al., 8 Sep 2025).

1. Conceptual basis and threat model

MCP-SEC is motivated by a security shift introduced by MCP-enabled tool use: LLMs transition from passive information processors to autonomous orchestrators of task-oriented toolchains, expanding the attack surface and elevating adversarial goals from manipulating single outputs to hijacking entire execution flows (Zhao et al., 8 Sep 2025). The attack class emphasized in the framework is the Parasitic Toolchain Attack, instantiated as MCP-UPD. In that setting, adversaries require no direct victim interaction; instead, they embed malicious instructions into external data sources that LLMs access during legitimate tasks. The malicious logic then unfolds in three phases: Parasitic Ingestion, Privacy Collection, and Privacy Disclosure (Zhao et al., 8 Sep 2025).

The root cause analysis in the same study identifies two architectural deficiencies: MCP lacks both context-tool isolation and least-privilege enforcement, enabling adversarial instructions to propagate unchecked into sensitive tool invocations (Zhao et al., 8 Sep 2025). Related MCP security work places these issues within a broader ecosystem model comprising hosts, registries, and servers, and reports that hosts lack output verification mechanisms for LLM-generated outputs while registries often lack a vetted server submission process (Li et al., 18 Oct 2025). Other systematic analyses describe the threat surface in complementary ways, including 17 attack types across 4 primary attack surfaces (Yang et al., 17 Aug 2025), 31 distinct attack methods under four key classifications (Guo et al., 18 Aug 2025), and a component-based taxonomy comprising twelve attack categories for malicious MCP servers (Zhao et al., 29 Sep 2025). Taken together, these results position MCP-SEC as an ecosystem-scale analysis framework within a rapidly expanding literature on MCP security.

2. Architecture and operating workflow

MCP-SEC comprises two main modules: a Description Collection Module and a Tool Capability Analysis Module (Zhao et al., 8 Sep 2025). The Description Collection Module crawls and indexes publicly available MCP servers and their tool metadata. It gathers a comprehensive list of MCP servers from public directories such as Pulse MCP, MCP Market, and open-source indexes, then establishes a connection with each live server via an official or custom MCP client and calls standardized listing endpoints such as list_tools() to extract every registered tool’s name, description, and input schema (Zhao et al., 8 Sep 2025).

The Tool Capability Analysis Module uses advanced LLMs to semantically assess the security-relevant capabilities of each tool (Zhao et al., 8 Sep 2025). Full tool descriptions and schemas are analyzed using three diverse LLMs in parallel—Deepseek-R1-250528, OpenAI o3, and Claude Sonnet—and the framework applies a unanimous voting mechanism: only if all three LLMs agree does a tool receive a positive label (Zhao et al., 8 Sep 2025). This suggests a conservative labeling policy oriented toward minimizing false positives. The resulting output is a structured database that supports downstream risk analysis, including ecosystem-wide risk maps, aggregate statistics, per-server breakdowns, and attack-recipe construction (Zhao et al., 8 Sep 2025).

This workflow differs from prompt-only or host-only evaluation because it targets the MCP ecosystem at the level of server-exposed tool inventories. That emphasis is consequential: later auditing work focused on server implementations rather than ecosystem census, such as mcp-sec-audit for over-privileged tool capabilities, operates by static pattern matching over Python source code and MCP metadata plus dynamic sandboxed fuzzing and monitoring via Docker and eBPF (Huang et al., 23 Mar 2026). MCP-SEC instead begins from discoverability, metadata, and capability semantics at ecosystem scale (Zhao et al., 8 Sep 2025).

3. Capability model and attack-chain formalization

The capability model in MCP-SEC is defined around the functional roles tools can play in MCP-UPD attack chains (Zhao et al., 8 Sep 2025).

Capability	Role in the attack chain
EIT	Fetches external content; potential for parasitic ingestion
PAT	Reads local/private data; supports collection phase
NAT	Able to send/publish data to external endpoints; enables data exfiltration

The framework analyzes each tool’s metadata and schema to determine whether it exhibits EIT, PAT, or NAT capability (Zhao et al., 8 Sep 2025). Formally, if $\mathcal{S}$ is the set of MCP servers and each server $s \in \mathcal{S}$ exposes a set of tools $T_s$, then each tool $t \in T_s$ has descriptive metadata $\text{desc}(t)$ and parameter schema $\text{schema}(t)$. Capability functions are defined as

$$\text{Cap}_i(t) = \begin{cases} 1, & \text{if tool } t \text{ matches capability } i \ 0, & \text{otherwise} \end{cases}$$

where $i \in \{\text{EIT}, \text{PAT}, \text{NAT}\}$ (Zhao et al., 8 Sep 2025).

At the server level, the framework defines

$$\text{Risk}_i(s) = \exists t \in T_s: \text{Cap}_i(t) = 1$$

and an attack chain exists within server $s$ iff

$s \in \mathcal{S}$0

that is, the server hosts at least one tool of each required capability (Zhao et al., 8 Sep 2025). This formalization captures both intra-tool and inter-tool composability. The study explicitly reports that threat-relevant capabilities cluster both within single tools and across tools and servers, so command execution tools may expose all phases while complementary tools can also be assembled into an attack chain (Zhao et al., 8 Sep 2025).

4. Ecosystem-scale measurement results

MCP-SEC crawled 12,700 MCP servers from three primary sources, analyzed all servers directly runnable (2,191), successfully established connections with 1,360 live servers, and extracted and analyzed 12,230 individual tools from these servers (Zhao et al., 8 Sep 2025). The servers span diverse application areas, including information retrieval, social media, collaboration, communications, development/testing, cloud, and blockchain (Zhao et al., 8 Sep 2025).

The core measurement results show that 46.41% (5,666/12,230) of tools expose at least one threat-relevant capability, 78.5% (1,067/1,360) of servers exposed at least one risky tool, and 93 servers hosted all three gadget types required for complete MCP-UPD attacks within a single server (Zhao et al., 8 Sep 2025). The same study concludes that the MCP ecosystem is rife with exploitable gadgets and diverse attack methods (Zhao et al., 8 Sep 2025). It also reports that certain server types, particularly information retrieval and communication/email, are particularly dangerous as natural ingestion or disclosure hubs, while nearly every server category had representatives in all three risk phases (Zhao et al., 8 Sep 2025). Popular servers with hundreds or thousands of GitHub stars were also frequently found with high-risk exposures (Zhao et al., 8 Sep 2025).

These results align with adjacent measurement studies that identify systemic weaknesses across other MCP layers. A large-scale study of the broader MCP ecosystem collected and analyzed 67,057 servers from six public registries and found that a substantial number of servers can be hijacked by attackers due to invalid links, maintainers deleted, redirection hijacking, and credential leakage in configurations (Li et al., 18 Oct 2025). A separate measurement study on remote MCP authentication identified 7,973 live remote MCP servers and found that 40.55% expose tools without authentication; among 119 testable OAuth-enabled servers, each server exhibited at least one flaw, and dynamic client registration flaws affected 96.6% of tested servers (Zhou et al., 21 May 2026). The aggregate picture is not merely one of isolated malicious tools, but of systemic risk across discovery, hosting, authentication, and invocation boundaries.

5. Relation to adjacent MCP security benchmarks and analyzers

MCP-SEC sits within a broader family of MCP security evaluation frameworks, but its emphasis is ecosystem census rather than host robustness benchmarking or implementation-level auditing. MCPSecBench introduces a comprehensive security benchmark and playground integrating prompt datasets, MCP servers, MCP clients, and attack scripts to evaluate 17 attack types across 4 primary attack surfaces; its experiments show that over 85% of the identified attacks successfully compromise at least one platform, with core vulnerabilities universally affecting Claude, OpenAI, and Cursor, while prompt-based and tool-centric attacks vary across hosts and models (Yang et al., 17 Aug 2025). MSB, by contrast, is an end-to-end evaluation suite that measures how well LLM agents resist MCP-specific attacks throughout task planning, tool invocation, and response handling; across 2,000 attack instances, nine popular LLM agents, 10 domains, and 400+ tools, it reports models with stronger performance as more vulnerable because of stronger tool calling and instruction following capabilities (Zhang et al., 14 Oct 2025).

At the server-analysis layer, mcp-sec-audit provides protocol-aware inspection of MCP tool metadata and implementation code, using a TOML rulebook, static analysis over Python and JSON metadata, and dynamic sandboxed fuzzing with Docker and eBPF (Huang et al., 23 Mar 2026). On the MCPTox benchmark, it identified 663 capability instances over 491 samples with 100% detection rate where indicators existed (Huang et al., 23 Mar 2026). MCP-BiFlow addresses a different problem—unsafe bidirectional data flows—and reports 30 out of 32 confirmed MCP vulnerability cases detected, corresponding to 93.8% recall, then surfaces 549 overlap-compressed candidate clusters across 15,452 repositories, with 118 vulnerability paths in 87 servers confirmed by manual review (Hou et al., 8 May 2026).

Pitfall-oriented work extends this progression from detection to remediation. MCP Pitfall Lab operationalizes six developer pitfalls, distinguishes Tier-1 static analysis from Tier-2 trace/dataflow analysis, and reports F1 = 1.0 on four statically checkable pitfall classes; applying recommended hardening eliminates all Tier-1 findings, reducing the framework risk score from 10.0 to 0.0 at a mean cost of 27 lines of code (Hao et al., 23 Apr 2026). In a preliminary 19-run corpus, agent narratives diverged from trace evidence in 63.2% of runs and 100% of sink-action runs, which reinforces a methodological lesson already implicit in MCP-SEC: security assessment must rely on explicit capability and trace evidence rather than natural-language self-report (Hao et al., 23 Apr 2026).

6. Defensive implications, governance, and standardization

The findings exposed by MCP-SEC imply that defense cannot be reduced to prompt filtering alone. The broader literature proposes layered controls that target admission, privilege, authentication, provenance, and runtime policy. One line of work introduces an additive MCP extension, mcp-attested, with three mechanisms: a small, offline-signed clearance assertion a server publishes at a well-known URI and a host verifies against a pinned trust root before any tool dispatch; a deny-by-default per-server tool allowlist; and a flavor-gated enforcement mode that turns checks from warnings into hard denials, with every decision written to a tamper-evident audit log (Metere, 22 May 2026). This is a direct response to the absence of host-side server admission and per-tool authorization in baseline MCP deployments.

Authentication-specific work identifies a separate control plane. In remote MCP deployments, OAuth is the dominant authorization mechanism, but the ecosystem commonly exhibits open client environments, dynamic client registration, and delegated authorization, which distinguish MCP deployments from traditional OAuth and introduce new attack surfaces (Zhou et al., 21 May 2026). The resulting recommendations include strict restriction of dynamic client registration, mandatory PKCE with only the S256 method, explicit display of redirect URIs in consent UIs, and stronger specification-level requirements around redirect URI restrictions and client metadata handling (Zhou et al., 21 May 2026).

Governance-oriented proposals add further operational controls. Practical MCP security guidance recommends per-user authentication with scoped authorization, provenance tracking across agent workflows, containerized sandboxing with input/output checks, inline policy enforcement with DLP and anomaly detection, and centralized governance using private registries or gateway layers (Errico et al., 25 Nov 2025). Measurement work on privilege management similarly argues for least-privilege design, dynamic permission models, and automated trust assessment, after finding that network and system resource APIs dominate usage patterns across 2,562 real-world MCP applications (Li et al., 5 Jul 2025). Within this landscape, MCP-SEC’s principal significance is diagnostic rather than prescriptive: it quantifies the extent to which exploitable gadgets already exist in the ecosystem and thereby provides an empirical basis for tool labeling, privilege restriction, server admission, and cross-tool auditing policies (Zhao et al., 8 Sep 2025).