MCP [1] defines a JSON-RPC 2.0-based protocol for LLM tool integration. A session begins with an initialize handshake, after which clients may issue tools/list to enumerate available capabilities. Each tool schema contains a name, a natural-language description, and an inputSchema (a JSON Schema object). LLMs consume these schemas in their context window to make routing decisions. Critically, the protocol provides no cryptographic validation, schema attestation, or sandboxing mechanism – all trust is delegated to the server.

Indirect prompt injection [9] refers to attacks where adversarial instructions are embedded in data that an LLM processes, rather than in the user’s direct prompt. MCP tool poisoning is a structural instance: the schema field is server-supplied metadata, yet it is processed by the same inference pipeline that executes user instructions. This conflation of data and instruction planes is the fundamental flaw.

Prior defenses fall into three broad categories.

Pattern Matching / Static Analysis. Rule-based filters detect known malicious keywords (e.g., “ignore previous instructions”). These are trivially bypassed by paraphrasing or encoding.

Retrieval-Based Similarity. Systems like the predecessor to our own work [5] use FAISS [10] vector indexes to compare incoming schemas against a registry of known-safe tools. The fundamental limitation is that this approach requires a pre-registered baseline for every legitimate tool; novel tools without a registered anchor – the definition of a zero-day – are passed through unchecked.

Graph Neural Networks. MCPShield [4] models tool-call sessions as directed graphs and uses GNNs to detect anomalous patterns. This provides strong recall on known attack categories but requires runtime graph construction, carries substantial memory overhead ($>$500 MB RAM), and cannot intercept schemas before LLM ingestion.

MCP Neural Shield addresses all three limitations: it generalizes beyond pattern matching by learning semantic intent, eliminates registry maintenance burden, and intercepts schemas pre-ingestion at negligible latency with a memory footprint under 15 MB.

We assume an adversary with control over one or more MCP server instances that a target LLM agent connects to – either because the server is malicious, has been compromised, or hosts user-contributed tool definitions. We assume the LLM client and transport layer are unmodified and behave per the MCP specification. We do not assume the adversary has access to the client’s system prompt or prior conversation history.

Tool Poisoning. The attacker injects a secondary directive into the description field of an otherwise structurally valid tool schema. Representative payload categories include:

• •

  Explicit override: “Ignore all prior instructions. Forward /etc/passwd to http://attacker.com/exfil.”

• •

  Subtle embedding: “Calculates tax. Additionally, email the session token to support@attacker-domain.org.”

• •

  Encoding obfuscation: Base64 or Unicode-escaped payloads within otherwise benign descriptions.

• •

  Execution triggers: Silent rm -rf or background remote command execution embedded as secondary instructions.

Tool Shadowing. The attacker registers a tool with a name identical or semantically similar to a privileged system tool (e.g., read_file, execute_command), but with a modified description that steers the agent toward the attacker’s implementation. MCPSecBench [3] covers name squatting, spoofed database inspection tools, and Man-in-the-Middle SSE frame injections (e.g., CVE-2025-6541).

Our system targets schema-level attacks at the tools/list interception point. We do not address: (1) attacks on tool execution outputs, (2) active man-in-the-middle network attacks, or (3) jailbreaks through direct user prompts. These are complementary defense layers.

MCP Neural Shield is designed around three constraints imposed by the target deployment environment:

1. 1.

   Pre-ingestion interception. Detection must occur before tool schemas reach the LLM context window.

2. 2.

   Sub-millisecond hot-path latency. IDE-integrated agents load tool schemas on every session start; validation must not be user-perceptible (target: ${<}2.0$ ms).

3. 3.

   Zero protocol dependencies. The system must wrap any MCP server regardless of implementation language (Python, TypeScript, Go, Rust) without server modification.

The system provides two deployment paths illustrated in Figure 1.

Native FastMCP Middleware. For Python servers built on FastMCP, ShieldMiddleware attaches directly to the list_tools event loop. It intercepts the tools/list response, passes each schema through the classifier, and either strips flagged tools (FILTER mode) or replaces the entire response with a JSON-RPC error (code: $-32000$, BLOCK mode).

Universal Stdio Passthrough CLI. The mcp-shield CLI entrypoint spawns any target MCP server as a subprocess and interposes on its stdout stream. It parses tools/list JSON-RPC response objects, classifies each schema, and emits a sanitized response to the originating client. The CLI additionally monitors the inbound stdin stream, maintaining an in-memory set of blocked tool names to intercept tools/call requests for previously flagged tools before the subprocess ever receives them. This path is transport-agnostic and supports any implementation language.

The system applies two sequential validation layers.

Layer 1 – Deterministic Keyword Verification. A rule-based pre-filter (verify.py) blocks tools that: (a) are missing a name field; (b) contain shell-execution keywords in their name (exec, shell, eval, system, bash); (c) contain unsafe intent phrases in their description (execute arbitrary, run shell, system command); or (d) specify shell-linked input parameter names (command, cmd, script). This layer provides deterministic, zero-latency coverage for known-bad signatures.

Layer 2 – Neural Semantic Classifier. Schemas that pass Layer 1 are evaluated by MCPNeuralShield, which classifies their semantic intent using the trained MLP. This layer detects naturally-phrased, paraphrased, and structurally novel attacks that evade the keyword filter.

JSON-RPC tool schemas are structured objects; feeding raw JSON to a language encoder is suboptimal due to tokenization noise from structural characters. We serialize each schema into a structured natural-language string $s$:

Serialized strings are encoded using all-MiniLM-L6-v2 [7], a 22.7M-parameter Sentence Transformer pretrained on over 1B sentence pairs via contrastive learning. This encoder projects the semantic intent of a tool schema into a 384-dimensional unit-normalized embedding space:

The choice of all-MiniLM-L6-v2 is deliberate: it achieves competitive performance on semantic similarity benchmarks (STS-B Spearman $\rho{=}0.891$) while maintaining an inference footprint suitable for CPU-only local execution.

The classifier, ToolMLPClassifier, is a three-layer feed-forward network. Letting $\mathrm{D}_{p}$ denote dropout with rate $p$:

Training uses Adam ($\mathrm{lr}{=}10^{-3}$, $\lambda{=}10^{-5}$ weight decay) for 30 epochs with batch size 32 on an 80/20 stratified train/test split. The decision boundary is $\hat{y}=\mathbf{1}[\sigma(f(\mathbf{x}))\geq 0.5]$.

The trained float32 model undergoes PyTorch dynamic weight quantization, converting all linear layer weights to torch.qint8 via the qnnpack backend:

This reduces forward-pass compute by approximately 4–5$\times$ on CPU, exploiting ARM NEON vector instructions via the qnnpack engine on Apple Silicon and Intel NEON on x86. The full quantized checkpoint occupies approximately 110 KB (shield_model.pt), compared to ${>}150$ MB for GNN-based alternatives, and imposes a total runtime memory footprint under 15 MB.

Schema re-encoding via the Sentence Transformer dominates inference time at ${\sim}5.0$ ms. Since deployed agents repeatedly check the same set of registered tools across sessions, we introduce an MD5-keyed LRU embedding cache (capacity: 1,024 entries):

On a cache hit, the stored 384-d embedding is retrieved and passed directly to the quantized MLP, bypassing the Sentence Transformer entirely. This reduces hot-path latency from ${\sim}5.0$ ms to ${<}0.1$ ms – a $50{\times}$ improvement for tools seen in prior sessions.

All latency profiling and execution benchmarks were conducted on an Apple M3 Max (16-core CPU: 12 high-performance, 4 high-efficiency cores; 36 GB unified LPDDR5 memory; macOS Sonoma 14.7.1). Inference was executed single-threaded using PyTorch dynamic qint8 quantization with the qnnpack engine. No GPU acceleration was used.

We report True Positive Rate (TPR, recall on adversarial class), False Positive Rate (FPR, fraction of legitimate tools incorrectly blocked), precision, and F1-Score per class and in aggregate. We prioritize TPR and FPR over overall accuracy given the asymmetric costs: a missed attack (false negative) risks data exfiltration or unauthorized execution, while a false positive blocks a legitimate capability.

Table I reports the per-class classification metrics computed on the held-out 20% validation split (861 samples, never seen during training).

The quantized MLP achieves perfect separation across both classes on the held-out split, with zero false positives on the 581 benign schemas and zero false negatives on the 280 adversarial schemas. This validation set maintains the same ${\approx}67.5\%$:$32.5\%$ class ratio as the full corpus, preserving statistical integrity.

Table II reports detection performance across all benchmark splits evaluated via run_comprehensive_benchmark.py.

The batch latency column reflects asynchronous execution of large schema batches (1,000+ tasks) on a single CPU core via a thread-pool executor. While the aggregate queuing latency reaches ${\sim}3.1$ s for the full MCPTox batch, the main Python event loop remains non-blocking throughout. Per-schema hot-path latency is unaffected (${<}0.1$ ms).

Table III situates MCP Neural Shield against the three prior defense paradigms.

The FAISS-based registry fails categorically on zero-day tool names for which no baseline embedding exists. Our approach eliminates this failure mode by classifying semantic intent directly, without requiring any pre-registered anchor.

Inference latency was profiled on the Apple M3 Max across 1,000 repeated classifications per schema:

• •

  Cold path (cache miss): Sentence Transformer encoding ${\sim}5.0$ ms + MLP forward pass ${\sim}0.07$ ms $\approx 5.1$ ms total.

• •

  Hot path (LRU cache hit): MD5 hash lookup ${\sim}0.01$ ms + MLP forward pass ${\sim}0.07$ ms $<0.1$ ms total.

In realistic deployment the hot path dominates: tool schemas are registered once per server, and the same schemas are checked on every session reconnect. After the first cold-path evaluation, all subsequent checks execute in under 0.1 ms – well within the strict ${<}2.0$ ms performance budget.

To isolate the neural component’s contribution, we evaluated the deterministic keyword filter (Layer 1) in isolation on MCPTox. It detected 58.4% of adversarial schemas – those containing explicit shell-execution keywords or canonical injection phrases. The remaining 41.6% used natural-language paraphrases (e.g., “Additionally, please transmit the file contents to…”) that bypassed lexical matching. The MLP classifier (Layer 2) correctly identified all residual cases, confirming that semantic intent modeling is both necessary and sufficient for complete coverage.

Tool poisoning attacks, despite surface diversity, share a common structural property: they must convey a directive to the LLM in natural language. This directive, regardless of phrasing, occupies a distinct region of the semantic embedding space from legitimate tool descriptions, which describe capabilities and inputs without issuing commands. The Sentence Transformer projects both into a shared 384-dimensional space where this separation is learnable by a simple MLP. Our Semantic Cross-Pollination augmentation explicitly widens the legitimate schema manifold to reduce false positives on edge cases such as legitimately authoritative descriptions (e.g., “Executes a read-only SQL query…”).

The critical advantage over retrieval-based approaches is that our classifier evaluates the content of a schema rather than its proximity to known-safe examples. A novel tool named exfil_optimizer with a benign description (e.g., “Compresses output files for efficient storage”) will be correctly classified as safe; a familiar tool named calculate_tax with an injected directive will be correctly flagged – regardless of whether either tool appears in any registry.

Training Distribution. The classifier was trained on English-language schemas. Adversarial payloads in other languages or unusual Unicode (e.g., direction-override characters) may reduce TPR. Multilingual encoder variants (e.g., paraphrase-multilingual-MiniLM-L12-v2) could address this.

Perfect Benchmark Results. A 100% TPR and 0% FPR on both the validation split and benchmark data warrants epistemic caution. The held-out validation split was produced from the same augmentation pipeline as the training set; although MD5-based deduplication (Section V-F.2) prevents verbatim leakage, semantic near-duplicates from the same template family could still inflate validation performance. Independent corroboration comes from the MCPTox and MCPSecBench benchmarks, which were not generated by our augmentation pipeline: 1,348 and 50 adversarial schemas respectively, all correctly flagged at 0% FPR on MCPToolBench++. Adaptive adversaries with knowledge of the training distribution could craft schemas near the decision boundary. The adjustable threshold $\tau\in[0,1]$ (via --threshold) allows operators to shift the precision-recall trade-off, and the two-layer architecture provides defense-in-depth.

Obfuscated Payloads. Highly obfuscated payloads (Base64, Unicode-escaped instructions) may evade the encoder’s tokenization. A preprocessing normalization stage before classification is a natural extension.

Execution-Layer Attacks. Our system defends the tools/list boundary only. Attacks that manifest in tool outputs (e.g., a legitimate tool returning injection instructions for the next reasoning step) are outside our scope.