MCP-Zero: Minimalist MCP Ecosystem Hardening

• MCP-Zero is a family of minimalist proposals that reduce prompt context, ambient privilege, and audit exposure in MCP-based systems.
• It enables proactive toolchain construction with iterative tool retrieval, significantly cutting token overhead while ensuring semantic alignment.
• The framework enforces a zero-trust, least-privilege baseline and clause-compliant profile to mitigate authorization, cross-server, and security risks.

Searching arXiv for papers on "MCP-Zero", "Model Context Protocol security", and related MCP research. “MCP-Zero” denotes a cluster of research proposals built around the Model Context Protocol (MCP) rather than a single canonical artifact. Across the current literature, the label is used for at least three distinct but related agendas: proactive toolchain construction that avoids prompt-scale schema injection, secure-by-default MCP implementations that eliminate compatibility-abusing behavior, and zero-trust or zero-knowledge control planes for authorization, composition, and audit. The common motif is minimization: reducing unnecessary prompt context, ambient privilege, clause ambiguity, or plaintext audit exposure within MCP-based agent systems (Fei et al., 1 Jun 2025, Yang et al., 10 Mar 2026, Jing et al., 11 Dec 2025).

1. Terminological scope and conceptual center

The underlying substrate is MCP itself: an open, JSON-RPC-based interoperability standard in which MCP clients discover and invoke tools, resources, and prompts exposed by MCP servers. In that setting, “MCP-Zero” is used as a minimizing qualifier rather than a stable standard name. In one line of work it means constructing a task-specific toolchain “from scratch”; in another, it means a minimal clause-compliant implementation profile; in another, it denotes a zero-trust or zero-knowledge operational baseline (Fei et al., 1 Jun 2025, Yang et al., 10 Mar 2026, Li et al., 5 Jul 2025, Jing et al., 11 Dec 2025).

Usage of “MCP-Zero”	Core objective	Representative source
Proactive tool acquisition	Retrieve only needed tools at runtime	(Fei et al., 1 Jun 2025)
Clause-compliant secure profile	Remove compatibility-abuse windows	(Yang et al., 10 Mar 2026)
Zero-trust least-privilege baseline	Default deny, scoped capability, per-call auth	(Li et al., 5 Jul 2025, Huang et al., 8 Mar 2026, Croce et al., 26 Jul 2025)
Privacy-preserving audit	Verify communication without revealing contents	(Jing et al., 11 Dec 2025)

This multiplicity is not accidental. MCP centralizes tool metadata, standardized invocation semantics, and compositional workflows; those same properties create pressure to minimize different failure modes. One research thread targets context overhead and semantic retrieval; another targets privilege sprawl, caller confusion, and cross-server exfiltration; another targets post hoc verifiability under confidentiality constraints. A plausible implication is that “MCP-Zero” functions as a design family for hardening MCP along orthogonal axes rather than as a single interoperable profile.

2. Proactive toolchain construction from scratch

In "MCP-Zero: Proactive Toolchain Construction for LLM Agents from Scratch" (Fei et al., 1 Jun 2025), MCP-Zero is an active tool discovery framework intended to replace passive function-calling patterns in which the full JSON-Schema inventory is injected into the prompt. The motivating observation is quantitative: a single MCP tool definition can require 143 tokens; the complete GitHub MCP server requires over 4,600 tokens for 26 tools; and comprehensive MCP ecosystems can exceed 248.1k tokens while spanning nearly 3,000 candidate tools (Fei et al., 1 Jun 2025).

The framework is organized around three components. First, Proactive Tool Request returns “tool requirement specification authority” to the model itself. When the model detects a capability gap, it emits a structured block of the form:

$r$9

The server field captures platform, permission, or domain constraints such as filesystem, GitHub, or shell; the tool field describes the desired operation type and target. Second, Hierarchical Vector Routing performs coarse-to-fine retrieval: server filtering uses embeddings over server_description and server_summary, tool ranking then scores tool descriptions within the selected servers. The ranking combines server-level and tool-level cosine similarities through the paper’s scoring expression $$\text{score} = (s_{\text{server}} \times s_{\text{tool}})\times \max(s_{\text{server}}, s_{\text{tool}})$$. Third, Iterative Proactive Invocation supports multi-round revision when the initial retrieved toolset is insufficient, enabling cross-domain toolchain construction with minimal context overhead (Fei et al., 1 Jun 2025).

The evaluation is built on MCP-tools, a retrieval dataset extracted from the official Model-Context-Protocol repository. The dataset begins with 396 servers and, after quality filtering, retains 308 servers with 2,797 tools normalized into a unified JSON schema; Qwen2.5-72B-Instruct is used for structured extraction and server-summary generation, and text-embedding-3-large is used for embeddings (Fei et al., 1 Jun 2025). On APIBank, the reported token reductions are substantial: in the single-turn full setting, average tokens drop from 6308.2 for the standard schema-injection baseline to 111.0 for MCP-Zero, a reduction of 98.24%, while maintaining high accuracy across Claude, GPT-4.1, and Gemini. In the multi-turn full setting, average tokens drop from 6402.2 to 159.0, a reduction of 97.52% (Fei et al., 1 Jun 2025).

Conceptually, this version of MCP-Zero is not primarily a security system. Its central claim is that active acquisition yields better semantic alignment than query-once retrieval and better scaling than prompt-wide schema injection. The paper formalizes the distinction as passive selection over a fixed tool pool versus active acquisition through request variables $r$, with iterative information gain accumulating across rounds (Fei et al., 1 Jun 2025).

3. Zero-trust, least-privilege, and compositional security baselines

A second usage of MCP-Zero treats it as a secure operational baseline for MCP ecosystems. The strongest empirical motivation comes from resource-usage and authorization studies. "We Urgently Need Privilege Management in MCP" analyzes 2,562 real-world MCP applications across 23 categories and finds that network and system resource APIs dominate usage patterns, affecting 1,438 and 1,237 servers respectively; file resources affect 613 servers and memory resources 25. Developer Tools and API Development are the most API-intensive categories, and plugins with 0–10 GitHub stars account for 1,837 total API calls, exceeding higher-star ranges (Li et al., 5 Jul 2025). On that basis, the proposed MCP-Zero posture is explicit: zero trust, least privilege, and default deny, with granular scopes, dynamic permissions, pre-approval workflows for powerful scopes, per-plugin sandboxes, egress controls, immutable audit logging, and code-signing or provenance signals (Li et al., 5 Jul 2025).

"Give Them an Inch and They Will Take a Mile" sharpens the authorization problem by identifying caller identity confusion in MCP-based systems (Huang et al., 8 Mar 2026). In a dataset of 6,137 MCP servers, 2,846 servers, or 46.4%, exhibit insecure authorization behavior through missing authorization, cached authorization, or authorization reused across invocations. The paper formalizes an invocation-level authorization function $A(c,t,\mathrm{ctx})$ and an identity-binding invariant $I(c,t,\mathrm{ctx})$, then argues for per-invocation caller authentication, session-bound tokens, per-tool allowlists $S(c)$, and deny-by-default dispatch. The corresponding MCP-Zero interpretation is a zero-trust architecture in which no tool execution occurs before initialize establishes a caller-bound session, and cached global authorization is replaced with session-scoped, short-lived credentials (Huang et al., 8 Mar 2026).

"Trivial Trojans" extends the threat model from server-local privilege to cross-server composition (Croce et al., 26 Jul 2025). Its proof-of-concept uses a malicious weather MCP server, built from Anthropic’s “Hello Weather” example with fewer than 25 lines of additional code, to discover a Monzo banking tool and exfiltrate account balance data via an HTTP POST to webhook.site. The demonstration requires only “undergraduate-level Python knowledge,” no dedicated server infrastructure, no monetary investment, and under 2 hours of setup time. From this, the paper derives an MCP-Zero baseline centered on capability-based permissions, mandatory access boundaries, signed manifests, explicit designation of sensitive servers, default-deny cross-server composition, destination-aware consent prompts, and data-loss-prevention-style output filtering (Croce et al., 26 Jul 2025).

MSB, the MCP Security Bench, adds an evaluation lens rather than a definition (Zhang et al., 14 Oct 2025). It operationalizes 12 attack types across planning, invocation, response handling, and retrieval, then measures nine LLM agents across 10 domains, 25 MCP servers, 304 benign tools, 400+ malicious tools, and 2,000 attack instances. The average attack success rate is 40.71%; the invocation-stage Out-of-Scope Parameter attack reaches 74.03% average ASR, User Impersonation 50.72%, False Error 43.42%, Prompt Injection 17.03%, and Retrieval Injection 18.89%. Its Net Resilient Performance metric, $\mathrm{NRP}=\mathrm{PUA}\cdot(1-\mathrm{ASR})$, is useful for judging whether an MCP-Zero hardening profile reduces security failure faster than it degrades utility (Zhang et al., 14 Oct 2025).

4. Clause compliance and compatibility-abusing attacks

A third major usage appears in "Compatibility at a Cost: Systematic Discovery and Exploitation of MCP Clause-Compliance Vulnerabilities" (Yang et al., 10 Mar 2026), where MCP-Zero is distilled as a minimal, secure, clause-compliant implementation. The paper’s starting point is the structure of the MCP specification itself. Across 275 clauses, 59 are unconditional MUST clauses, 78 are conditional or scoped MUST clauses, and 138 are non-MUST clauses; thus only 21.5% are strictly non-optional across all scenarios. The authors argue that optional or relaxed clauses frequently become misuse-prone implementation gaps involving listChanged notifications, ping frequency configurability, token issuer validation, capability scoping, strict parsing, and fail-safe error handling (Yang et al., 10 Mar 2026).

The formal model represents a clause as $c \equiv \langle \gamma_c,\alpha_c\rangle$, where $\gamma_c$ is a guard condition and $\alpha_c$ an action. Compliance is defined by the existence of an IR-level call site whose condition entails the guard and whose callee matches the required action. On top of that model, the paper constructs a universal language-agnostic IR with defs_<lang>.jsonl and calls_<lang>.jsonl, then applies static slicing plus LLM-guided semantic reasoning for cross-language compliance auditing. The self-refinement loop iteratively expands keywords when confidence $q$ falls below threshold $r$0, retaining evidence for auditability (Yang et al., 10 Mar 2026).

The attack model is organized by payload and timing control. If $r$1 denotes payload control and $r$2 timing control, then PyTy, PyTn, and PnTy correspond respectively to joint payload-and-timing attacks, payload-only attacks, and timing-only attacks. Three concrete categories are emphasized. Silent prompt injection arises when ToolListChanged, ResourceListChanged, or PromptListChanged notifications are omitted despite changes and declared listChanged capability. Ping-based denial of service arises when no configurable ping rate or rate limit is enforced. Token misuse or data exfiltration arises when clients validate only token presence and expiry, not issuer binding (Yang et al., 10 Mar 2026).

The empirical study audits 10 official SDKs—Python, TypeScript, Go, Kotlin, Swift, Java, C#, Ruby, Rust, and PHP—over all 275 clauses. It reports 1,270 non-implementations, of which 1,265 are deemed exploitable. Per-SDK non-implementations range from 80 to 211, mostly in optional clauses. The hybrid audit yields approximately 86% precision and 87% recall, with average false-positive and false-negative rates of about 14% and 13.5%, at a total LLM audit cost of approximately $r$30.20 per clause (Yang et al., 10 Mar 2026).

Within this paper, MCP-Zero is the name for the hardened profile that elevates repeatedly exploited optional clauses into enforced behaviors: mandatory notifications for tools, resources, and prompts; issuer-bound token validation; configurable and rate-limited ping policies; strict JSON schema parsing that rejects unexpected fields; capability declaration with denial of undeclared operations; and fail-closed behavior on parse, verification, or timeout failures. The paper also states informal safety, liveness, and non-interference properties over such implementations, including the guarantee that changed server-side content cannot reach LLM context without a corresponding notification event when notification enforcement holds (Yang et al., 10 Mar 2026).

5. Privacy-preserving audit and the zk-MCP variant

A fourth usage of the label appears in "Zero-Knowledge Audit for Internet of Agents: Privacy-Preserving Communication Verification with Model Context Protocol" (Jing et al., 11 Dec 2025). Here MCP-Zero, also called zk-MCP, is a zero-knowledge audit framework layered alongside standard MCP exchanges. The objective is not tool retrieval or runtime hardening, but privacy-preserving verification of communication statistics, format adherence, and auditability in regulated settings such as billing and compliance (Jing et al., 11 Dec 2025).

The architecture contains agent provers, a communicating peer, an Audit Service Provider verifier, an MCP Registry Server, and a Model Registry. During a normal MCP session, the prover logs metadata for each message, extracts message types, and later generates a zk-SNARK proof over public outputs $r$4 and private witness material $r$5. The implementation uses Circom and snarkjs, with Poseidon hashes as public commitments to message contents. Audit traffic is carried out-of-band via Session-Start, Audit-Request, and Session-Close, leaving MCP messages and headers unchanged (Jing et al., 11 Dec 2025).

The implemented circuit checks that each padded JSON message contains a "type" field, that message bytes lie in the valid range, that each message matches exactly one known type, that counts accumulate correctly, and that each message hash is computed with domain separation. The paper states standard completeness, soundness, and zero-knowledge properties for the zk-SNARK relation $r$6, and proves data authenticity and communication privacy under zk-SNARK soundness plus Poseidon collision resistance and one-wayness (Jing et al., 11 Dec 2025).

Operationally, the framework is designed to minimize latency impact by making proof generation asynchronous after session close. In the reported evaluation, communication overhead is less than 4.14% relative to the original MCP communication performance, with parsing and storage overhead $r$7 per message and verification remaining succinct. The chosen practical parameter is $r$8 messages per session, with circuit parameters MAX_JSON = 64, MAX_TYPE = 20, and NUM_TYPES = 8 (Jing et al., 11 Dec 2025).

This variant broadens the meaning of MCP-Zero. It does not implement zero trust or active tool routing; instead, it reduces audit visibility to the minimum public surface needed for verification. The paper is explicit that token-usage proofs and output-authenticity proofs are part of the framework’s goals but are only described conceptually, whereas the implemented circuit verifies message format, type classification, and message commitments (Jing et al., 11 Dec 2025).

6. Synthesis, misconceptions, and research trajectory

The principal misconception is that MCP-Zero names a single protocol extension or reference implementation. The published record instead indicates several non-equivalent proposals sharing a “minimal sufficient control” philosophy. In one branch, the minimization target is prompt context and retrieval complexity; in another, it is clause ambiguity; in another, it is ambient privilege, caller confusion, or unrestricted cross-server composition; in another, it is audit disclosure (Fei et al., 1 Jun 2025, Yang et al., 10 Mar 2026, Li et al., 5 Jul 2025, Huang et al., 8 Mar 2026, Croce et al., 26 Jul 2025, Jing et al., 11 Dec 2025).

A second misconception is that the term is purely security-centric. The proactive toolchain work is primarily about retrieval efficiency, semantic alignment, and stable tool selection under scale. Conversely, the zero-trust and clause-compliance lines are security-centered, but they address different layers: ecosystem privilege management, per-call authorization semantics, cross-server dataflow control, benchmarked agent robustness, and SDK-level clause enforcement (Fei et al., 1 Jun 2025, Zhang et al., 14 Oct 2025).

The research trajectory remains open on several fronts. The clause-compliance program identifies blind spots in IR normalization, evolving specifications, and LLM-driven false positives or false negatives. The privilege-management line leaves dynamic permission models and automated trust assessment as open challenges. The caller-identity line calls for standardizing caller identity in MCP protocol fields and portable per-tool authorization semantics. The cross-server exfiltration line leaves formal secure composition and social-engineering-resistant consent as unresolved. The zero-knowledge audit line still lacks detailed circuits for token consumption and output authenticity. MSB, finally, shows that security-utility trade-offs must be evaluated end-to-end under real MCP tool execution rather than by isolated prompt tests (Yang et al., 10 Mar 2026, Li et al., 5 Jul 2025, Huang et al., 8 Mar 2026, Croce et al., 26 Jul 2025, Jing et al., 11 Dec 2025, Zhang et al., 14 Oct 2025).

Taken together, the literature suggests that MCP-Zero is best understood as a family of minimality doctrines for MCP systems. Whether the target is active capability acquisition, secure clause compliance, least-privilege execution, caller-bound authorization, cross-server isolation, or privacy-preserving audit, the unifying aim is to preserve MCP interoperability while removing unnecessary surface area from the tool-use pipeline.