Pith. sign in

REVIEW 3 major objections 8 minor 9 cited by

Beyond the Protocol: Unveiling Attack Vectors in the Model Context Protocol (MCP) Ecosystem

T0 review · 3 major / 8 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Malicious MCP servers can be uploaded to widely used registries, installed by unsuspecting users, and used to make LLM agents leak private files or move cryptocurrency, with an average attack success rate of 53% across current mainstream…

desk verdict First real end-to-end empirical study of malicious MCP servers, but the 'real-world' damage claim leans on a simulated transfer and needs scoping. read the letter →

arxiv 2506.02040 v4 pith:LIH6OPJC submitted 2025-05-31 cs.CR cs.SE

Hao Song , Yiming Shen , Wenxuan Luo , Leixin Guo , Ting Chen , Jiashui Wang , Beibei Li , Xiaosong Zhang
show 1 more author
Jiachi Chen
This is my paper · ORCID
classification cs.CRcs.SE
keywords ModelContextProtocolMCPaggregationplatformsLLMagentsecuritypromptinjectiontoolpoisoningattackpuppetrugpullmaliciousservers
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the Model Context Protocol (MCP), the emerging standard that lets LLM agents call external tools, creates a trust boundary that malicious servers can cross. It names four attack patterns—Tool Poisoning, Puppet Attack, Rug Pull, and Malicious External Resources—and tests them along the full upload, download, and attack lifecycle. The authors report that a malicious server was accepted by three major MCP aggregators, that 15 of 20 participants picked at least one malicious server, and that the attacks succeeded on average 53% of the time against five mainstream LLMs while refusals stayed below 10%. If true, this means the protocol's convenience has outpaced its security: users are installing untrusted servers that can turn their agents into data exfiltrators or crypto transfer tools. The paper also proposes defenses, including client-side security gates at the registration and prompt-assembly paths and cryptographic signing of tool descriptions.

What carries the argument

The load-bearing mechanism is the MCP capability-registration channel: a server declares its tools as natural-language descriptions, and the client pastes those descriptions into the LLM's context while showing the user only a simplified version. Because the protocol does not separate server-controlled text from user instructions, any text entering this channel is trusted by the model. The paper maps all four attack types to specific steps of the nine-step MCP workflow, showing that tool descriptions, server outputs, and third-party fetched content are equally able to carry the injection. This single mechanism explains why auditing server code at upload time is insufficient: the payload lives in metadata the platform never inspects (descriptions, runtime outputs, remote pages), not only in executable code.

What would settle it

Re-upload a family of malicious MCP servers covering all four attack vectors, with obfuscated and indirect payloads, to Smithery.ai, MCP.so, and Glama and check whether any are rejected or flagged; if a substantial fraction are blocked, the claim of insufficient auditing is falsified. Separately, re-run the three attack tasks on current versions of the five LLMs and five MCP clients; if refusal rates climb above 80% or attack success rates fall below 20%, the claim that mainstream LLMs and clients cannot defend is falsified.

Watch

Extended reading notes

Core claim

The paper's central claim is that the MCP client-server architecture hands the attacker a clean channel for prompt injection: tool descriptions returned by an MCP server are fed to the LLM as part of the agent's context, while the user only ever sees a simplified version of them. This enables server-originated attacks even when the server's code is benign or the server is trusted at install time. The four attack types the paper defines—Tool Poisoning, Puppet Attack, Rug Pull, and Malicious External Resources—all follow from this design: malicious instructions hidden in tool descriptions, in coordinated server pairs, in post-approval code updates, or in third-party resources that a benign tool fetches. The paper reports empirical evidence for each stage: a malicious server was accepted by Smithery.ai, MCP.so, and Glama without rejection; 15 of 20 participants selected at least one malicious server when building a travel agent; and benchmarked attacks achieved an average attack success rate above 50% across five LLMs, with refusal rates below 10%. The authors conclude that current LLMs and MCP clients lack adequate defense mechanisms against these vectors.

Load-bearing premise

The claim that MCP aggregator platforms cannot catch malicious servers rests on a single probe: one server design with one embedded malicious prompt, uploaded to each of three platforms, and if those platforms would detect other classes of malicious servers, the conclusion would overstate how widespread the audit failure is.

Editorial extensions

If this is right

  • Aggregator platforms should stop being treated as code review checkpoints; the paper's upload test shows that one-time submission checks miss prompt-injection payloads and that post-approval repository changes are never re-audited.
  • Users who install several MCP servers are exposed to Puppet Attacks even if every individual tool looks benign, because one server's description can steer how the LLM uses another server's tools.
  • Run-and-clean package managers such as npx and uvx amplify Rug Pull attacks, since the server code is freshly fetched at each run and can be swapped after platform approval.
  • LLMs with stronger tool-use abilities show higher attack success rates, so improving an agent's tool-calling skill without adding security awareness may increase exposure to these four vectors.
  • Client-side security gates placed on the registration and prompt-assembly steps, plus cryptographic signing of tool descriptions and code, would interrupt most of the four attack patterns before the LLM sees them.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The taxonomy likely generalizes beyond MCP: any protocol that injects untrusted tool descriptors or third-party content into an agent's context (OpenAPI-specified function calls, plugin manifests, retrieval results) can host the same four attack patterns; the paper's affected-path analysis gives a template for mapping them.
  • The paper's 53% average ASR probably understates real-world risk, since the user study found participants often auto-approve permission prompts, and because more users will install 'popular' servers that mimic trusted functionality.
  • Because aggregators are directory services pointing at external code repositories, an effective and cheap defense would be continuous diff monitoring of registered repositories, re-running audits on every update, rather than a single review at submission.
  • The user study's participant pool is skewed toward developers and researchers, so the claim that users struggle to identify malicious servers is likely conservative for non-expert users; a larger representative study would quantify the gap.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 8 minor

Summary. The paper presents an end-to-end empirical study of attacks launched through malicious MCP servers. It defines four attacks (Tool Poisoning, Puppet, Rug Pull, and Exploitation via Malicious External Resources) and evaluates the three stages of the attack lifecycle: uploading a malicious server to three aggregation platforms (RQ1), user detection of malicious servers on a simulated aggregator (RQ2, n=20), and attack success/refusal rates of three vectors against five LLMs and five MCP clients (RQ3). The authors report that all three platforms accepted the malicious server, that 75% of participants selected at least one malicious server, and that average ASR across evaluated LLMs is about 53% with low refusal rates. They conclude that current platform audits, users, LLMs, and clients do not adequately defend against these attacks.

Significance. If the claims hold, this is a valuable first end-to-end empirical evaluation of the MCP attack lifecycle. The paper has clear strengths: an explicit threat model, a multi-method design (platform upload, user study, attack implementation), internal consistency between the Cline rows in Tables 2 and 4, an IRB-approved user study, and a published artifact with source code and data. The affected-path versus exploited-path table (Table 3) is a useful organizing device for future defenses. The RQ3 measurements are empirical ASR/RR numbers rather than parameter fits, so the results are falsifiable. The main gaps are that some headline claims go beyond what the experiments actually demonstrate.

major comments (3)
  1. [§4.3.2, Figure 12, Answer to RQ3] The Cryptocurrency Theft result is not supported as a real-world transfer. The success criterion is that the LLM calls transfer_tool and the transfer-mcp server returns the simulated response '0.01 ETH has been transferred'; no wallet signature, user confirmation, transaction broadcast, or balance change is verified anywhere in RQ3. The abstract's phrase 'controlling devices to transfer digital assets' and the Answer to RQ3 ('All defined attack vectors can be effectively executed in real-world scenarios') therefore overstate what was measured. The experiment demonstrates prompt-following that invokes a transfer tool inside a mock environment, not that digital assets were transferred. I recommend relabeling this task as 'unauthorized transfer-tool invocation,' adding an explicit caveat, or extending the setup with a real signing/wallet step.
  2. [§4.3.3, Table 2, Answer to RQ3] The data do not support the blanket statement that all defined attack vectors can be effectively executed. The average ASR for Puppet Attack is only 6.67%, with 0% for GPT-4o and LLaMA3.1-70B, and the authors themselves write that 'the attack results using the Puppet Attack are not ideal.' In addition, Rug Pull Attack is not implemented in RQ3; its exploitation phase is argued to share mechanisms with the other attacks, but no local harmful action is measured. The conclusion should be narrowed to the specific vector/task combinations that were tested, and the percentage-point gap between vectors should be reported instead of the 1,299.25% relative increase. With 20 trials per cell, differences of a few percent are within sampling noise, so confidence intervals or a small statistical test would strengthen the claims.
  3. [§4.1.3, Answer to RQ1] The conclusion that aggregation platforms have insufficient audit mechanisms rests on a single malicious server design (one tool, one prompt-injection pattern) and one post-approval modification procedure. The single probe supports the narrow claim that this class of prompt-injection server is not detected by the three platforms and that repository modifications after approval are not re-reviewed; it does not by itself support the broader statement that platforms allow attackers to upload malicious servers across all four attack classes. The RQ1 answer should be rephrased to make the tested attack class explicit, or the authors should test additional malicious server designs (e.g., different injection placements or attack intents) before generalizing.
minor comments (8)
  1. [Figures 7 and 9] The axis tick labels in both figures are rendered as encoded tokens such as '/uni00000037/uni00000033/...', making the figures illegible; the labels need to be regenerated with proper text.
  2. [§4.3.2] The implementation details for Puppet Attack and Malicious External Resources are only in the online repository; the paper should summarize the server/tool structure and injection payloads for these vectors in an appendix so the experiments are self-contained.
  3. [§3.2, Equations (1)-(4)] The formalizations use ad-hoc notation (e.g., 'LLM call --', 'F query -- --') that is never defined precisely and is not used in the analysis; either define the notation rigorously or remove the equations and keep the prose descriptions.
  4. [§4.3.3, Result 1] The statement that Malicious External Resources 'exceeds Tool Poisoning Attack and Puppet Attack by 57.31% and 1,299.25%' is confusing; percentage-point differences are more informative and less misleading.
  5. [§2.2 and §4.1.2] There is a typo: 'Smithery.ai' is written as 'Smith-ery.ai' in one place; please ensure consistent spelling.
  6. [§4.3.3, Insight 7] The claim that stronger tool-utilization capability correlates with higher vulnerability is based on informal comparison with a leaderboard; cite the exact leaderboard version and date, and consider reporting the correlation quantitatively.
  7. [§5.3, Threats to Validity] The external validity discussion acknowledges the technical skew of the user study but does not mention the simulated transfer in RQ3; adding that limitation alongside the existing threats would give readers an accurate picture.
  8. [§4.2.3] The snowball recruitment method can amplify selection bias; the paper reports the demographics table, but a short sentence about how the snowball chain could bias the results would strengthen the external-validity discussion.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the attack-success rates are empirical measurements against external models and clients, and the only flagged concern is an external-validity gap, not a definitional reduction.

full rationale

This paper does not contain a derivation chain that reduces a predicted result to its own inputs. The four attack types (Tool Poisoning, Puppet, Rug Pull, and Malicious External Resources) are defined as empirical threat patterns, and equations (1)-(4) are descriptive formalizations of those patterns, not derivations from which attack success is inferred. The Attack Success Rate (ASR) and Refusal Rate (RR) in RQ3 are measured by running the constructed malicious servers against five external LLM services and five external MCP clients; there is no fitted parameter, calibration step, or self-referential benchmark that forces the measured rates. RQ1 is an observed upload outcome against three external aggregation platforms, and RQ2 is a measured user-study outcome. The self-citations present are not load-bearing: [51] supports only the interview methodology, and [11] supports a general mitigation suggestion about RLHF, not any central claim. The only notable weakness is that the Cryptocurrency Theft task counts a simulated transfer-tool invocation plus a mock success response as successful theft, so the strongest real-world wording ('controlling devices to transfer digital assets') overstates what the experiment demonstrates; however, this is an external-validity or measurement-validity concern, not circularity, because the paper's own task definition is an attempted transfer and the ASR metric is defined as execution of the intended malicious action. No step in the paper equates a conclusion with its premise by construction, so the circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claims rest on domain assumptions about the MCP trust boundary, LLM processing of tool descriptions, the behavior of one chosen client, and the representativeness of a single upload probe. No free parameters are fitted, and no new entities are postulated.

assumptions (4)
  • domain assumption The adversary can manipulate all tool description data and external resources accessed within their malicious MCP server, but cannot manipulate the MCP client.
    Threat model in Section 3.1 sets the attacker boundary; all four attack definitions and experiments rely on this capability split.
  • domain assumption Tool descriptions registered by an MCP server are passed to the LLM and can influence planning and tool selection.
    Central to Tool Poisoning, Puppet, and Rug Pull definitions; supported by observed tool-calling traces in Appendix H, but treated as a given in the attack framework.
  • domain assumption The Cline client implements no safety guardrails or hidden filtering mechanisms that would affect attack success rates.
    Appendix F justifies Cline for Benchmark 1; if false, the comparison of ASR/RR across LLMs could be confounded by client-side filtering.
  • ad hoc to paper The single malicious server probe in RQ1 is representative of the class of prompt-injection MCP servers that platforms should detect.
    Section 4.1.2 constructs one server with one injected prompt; the conclusion about insufficient platform audits generalizes from this single probe.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Beyond the Protocol: Unveiling Attack Vectors in the Model Context Protocol (MCP) Ecosystem." pith.science (2026). https://pith.science/paper/LIH6OPJC

@misc{pith2026250602040,
  author       = {Pith},
  title        = {Pith review of: Beyond the Protocol: Unveiling Attack Vectors in the Model Context Protocol (MCP) Ecosystem},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LIH6OPJC}},
  note         = {Machine review of arXiv:2506.02040}
}
read the original abstract

The Model Context Protocol (MCP) is an emerging standard designed to enable seamless interaction between Large Language Model (LLM) applications and external tools or resources. Within a short period, thousands of MCP services have been developed and deployed. However, the client-server integration architecture inherent in MCP may expand the attack surface against LLM Agent systems, introducing new vulnerabilities that allow attackers to exploit by designing malicious MCP servers. In this paper, we present the first end-to-end empirical evaluation of attack vectors targeting the MCP ecosystem. We identify four categories of attacks, i.e., Tool Poisoning Attacks, Puppet Attacks, Rug Pull Attacks, and Exploitation via Malicious External Resources. To evaluate their feasibility, we conduct experiments following the typical steps of launching an attack through malicious MCP servers: upload -> download -> attack. Specifically, we first construct malicious MCP servers and successfully upload them to three widely used MCP aggregation platforms. The results indicate that current audit mechanisms are insufficient to identify and prevent these threats. Next, through a user study and interview with 20 participants, we demonstrate that users struggle to identify malicious MCP servers and often unknowingly install them from aggregator platforms. Finally, we empirically demonstrate that these attacks can trigger harmful actions within the user's local environment, such as accessing private files or controlling devices to transfer digital assets. Additionally, based on interview results, we discuss four key challenges faced by the current MCP security ecosystem. These findings underscore the urgent need for robust security mechanisms to defend against malicious MCP servers and ensure the safe deployment of increasingly autonomous LLM agents.

Figures

Figures reproduced from arXiv: 2506.02040 by the authors.

Figure 1
Figure 1. Overview of the Model Context Protocol (MCP) workflow. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. PoC of Tool Poisoning Attack. formalize this attack as follows: (pbenign ⊕c⊕ pmalicious) ⇝ PT PA LLM call −−→ Stool(F ,PT PA) ⇝ A (1) where pbenign and pmalicious represent the benign and ma￾licious descriptions of a tool within a server, respectively. c represents meaningless characters used to hide the malicious description. Here, ⊕ represents the concatenation operator, and the first three components form the com… view at source ↗
Figure 3
Figure 3. PoC of Puppet Attack. malicious actions are triggered, ultimately leading to serious consequences. We formalize this attack as follows: [PX T ←− (pbenign ⊕c⊕ pmalicious)] ⇝ PPA [LLM call −−→ Stool(F ,PX )∥LLM handle −−−−→ PPA] ⇝ A (2) where PX represents the description of a benign tool, A, while PPA represents the description of a customized mali￾cious tool, B. This attack primarily affects path ② , ④ and ⑤ . It is… view at source ↗
Figures from the paper (8 more)
Figure 5
Figure 5. Figure 5: PoC of Exploit via Malicious External Resources. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Malicious description of Tool Poisoning Attack [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: ASRs/RRs of different attack vectors against various LLM services across different attack tasks. TPA denotes Tool Poisoning Attack. MER denotes Malicious External Resources. PA denotes Puppet Attack. The client is Cline. Insight 8: Attackers can increase the success ra…
Figure 8
Figure 8. Figure 8: MCP Server with Embedded Malicious Prompt in the Upload Test [PITH_FULL_IMAGE:figures/full_fig_p019_8.png]
Figure 9
Figure 9. Figure 9: ASRs/RRs of different attack vectors against various MCP clients across different attack tasks. TPA denotes Tool Poisoning Attack. MER denotes Malicious External Resources. PA denotes Puppet Attack. The LLM is Claude 3.7 Sonnet. 22 [PITH_FULL_IMAGE:figures/full_fig_p0…
Figure 10
Figure 10. Figure 10: Privacy Steal Task demonstration showing Tool Poisoning Attack (TPA) execution. The user queries weather [PITH_FULL_IMAGE:figures/full_fig_p023_10.png]
Figure 11
Figure 11. Figure 11: Result Manipulation Task demonstrating TPA-induced response tampering. When the user requests weather informa [PITH_FULL_IMAGE:figures/full_fig_p024_11.png]
Figure 12
Figure 12. Figure 12: Cryptocurrency Theft Task illustrating financial exploitation through TPA. The malicious weather tool deceives the [PITH_FULL_IMAGE:figures/full_fig_p025_12.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 9 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Rethinking MCP Security: A Large-Scale Study of Runtime MCP Servers and Security Scanner Reliability

    cs.CR 2026-07 conditional novelty 7.0 of 10

    MCP security scanners flag almost all runtime MCP servers as risky, yet manual and CVE validation show those alerts are inconsistent and often wrong.

  2. Unicode TAG-Block Concealment of Tool-Metadata Payloads in the Model Context Protocol: An Approval-View Fidelity Gap Across Three Independent Server Implementations

    cs.CR 2026-07 conditional novelty 6.5 of 10

    Unicode TAG-block encoding is the only of eight MCP tool-metadata attacks that is invisible in the approval view yet reaches the model verbatim, and re-approval is never forced even under rug-pulls.

  3. Mitigating Taint-Style Vulnerabilities in MCP Servers via Security-Aware Tool Descriptions

    cs.CR 2026-07 conditional novelty 6.0 of 10

    SPELLSMITH mitigates taint-style vulnerabilities in MCP servers by augmenting tool descriptions with security constraints and adding LLM self-reflection before tool invocation, reducing attack success rates to near zero.

  4. Combating Data Laundering in LLM Training

    cs.CR 2026-04 conditional novelty 6.0 of 10

    Data laundering collapses original-query memorization detectors; SDR recovers useful detection signals by synthesizing training-like rewrites of proprietary data via a goal-details search.

  5. Help or Hurdle? Rethinking Model Context Protocol-Augmented Large Language Models

    cs.AI 2025-08 reject novelty 6.0 of 10

    A new MCP benchmark across six LLMs finds that proactive tool use is rare on first prompts, instructed tool use mainly improves in two-turn dialogues, MCP context degrades accuracy by about 9.5%, and input-token overh...

  6. A Large-Scale Evolvable Dataset for Model Context Protocol Ecosystem and Security Analysis

    cs.CR 2025-06 conditional novelty 6.0 of 10

    The paper releases MCPCorpus, a large-scale annotated dataset of MCP servers and clients with over 20 normalized attributes, plus tooling for updates and exploration.

  7. ChainWatch: A Kill Chain-Aligned Sequential Detection Framework for Multi-Step Attacks in MCP-Based AI Agent Systems

    cs.CR 2026-07 conditional novelty 5.0 of 10

    A design for catching multi-step MCP attacks by mapping tool-call sequences to a six-stage kill chain and Hidden Markov Model is proposed, but it is not yet validated.

  8. MCP-SandboxScan: WASM-based Secure Execution and Runtime Analysis for MCP Tools

    cs.CR 2026-01 reject novelty 5.0 of 10

    MCP-SandboxScan safely executes MCP tools in WASI and detects external-to-sink data flows, but the abstract's claimed 100-repository evaluation is not present in the paper body.

  9. Agent Safety Alignment via Reinforcement Learning

    cs.AI 2025-07 reject novelty 5.0 of 10

    RL-based safety alignment with an execute-refuse-verify policy improves reported threat resistance for tool-using agents, but utility preservation is not consistently demonstrated.

Reference graph

Works this paper leans on

74 extracted references · 63 canonical work pages · cited by 9 Pith papers

  1. [1]

    Securing large language models: Threats, vulnerabilities and responsible practices, 2024

    Sara Abdali, Richard Anarfi, CJ Barberan, and Jia He. Securing large language models: Threats, vulnerabilities and responsible practices, 2024. https://arxiv.org/ abs/2403.12503

    arXiv 2024

  2. [2]

    Claude 3.7 Sonnet, 2025

    Anthropic. Claude 3.7 Sonnet, 2025. https://www.an thropic.com/claude/sonnet

    work page 2025

  3. [3]

    Claude desktop, 2025

    Anthropic. Claude desktop, 2025. https://claude.a i/download

    work page 2025

  4. [4]

    Get started with the model context protocol (mcp), 2025

    Anthropic. Get started with the model context protocol (mcp), 2025. https://modelcontextprotocol.io/ docs/getting-started/intro

    work page 2025

  5. [5]

    Model Context Protocol, 2025

    Anthropic. Model Context Protocol, 2025. https: //modelcontextprotocol.io/introduction

    work page 2025

  6. [6]

    Cursor - the ai code editor, 2025

    Anysphere. Cursor - the ai code editor, 2025. https: //www.cursor.com/cn

    work page 2025

  7. [7]

    Base-mcp, 2025

    Base. Base-mcp, 2025. https://github.com/base/ base-mcp

    work page 2025

  8. [8]

    Agent leaderboard, 2025

    Pratik Bhavsar. Agent leaderboard, 2025. https://hu ggingface.co/spaces/galileo-ai/agent-leade rboard

    work page 2025

Show all 74 references
  1. [9]

    Cline - ai autonomous coding agent for vs code, 2025.https://cline.bot/

    Cline Bot. Cline - ai autonomous coding agent for vs code, 2025.https://cline.bot/

    2025

  2. [10]

    A Survey on Evaluation of Large Language Models.ACM Trans- actions on Intelligent Systems and Technology, 2024

    Yupeng Chang, Xu Wang, Jindong Wang, et al. A Survey on Evaluation of Large Language Models.ACM Trans- actions on Intelligent Systems and Technology, 2024

    2024

  3. [11]

    RMCBench: Benchmarking Large Language Models’ Resistance to Malicious Code

    Jiachi Chen, Qingyuan Zhong, Yanlin Wang, Kaiwen Ning, Yongkun Liu, Zenan Xu, Zhe Zhao, Ting Chen, and Zibin Zheng. RMCBench: Benchmarking Large Language Models’ Resistance to Malicious Code. In Proceedings of the 39th IEEE/ACM International Con- ference on Automated Software ...

    2024

  4. [12]

    Angelopoulos, Tianle Li, Dacheng Li, Banghua Zhu, Hao Zhang, Michael I

    Wei-Lin Chiang, Lianmin Zheng, Ying Sheng, Anasta- sios N. Angelopoulos, Tianle Li, Dacheng Li, Banghua Zhu, Hao Zhang, Michael I. Jordan, Joseph E. Gonzalez, and Ion Stoica. Chatbot arena: An open platform for evaluating LLMs by human preference. InProceed- ings of the 41st I...

    2024

  5. [13]

    Cline-github, 2025.https://github.com/cli ne/cline

    cline. Cline-github, 2025.https://github.com/cli ne/cline

    2025

  6. [14]

    Coingecko api documentation, 2025

    CoinGecko. Coingecko api documentation, 2025. http s://docs.coingecko.com/reference/introduct ion

    2025

  7. [15]

    Deepseek-v3 technical report, 2024

    DeepSeek-AI. Deepseek-v3 technical report, 2024. ht tps://arxiv.org/abs/2412.19437. 14

    2024 arXiv

  8. [16]

    Ai agents under threat: A survey of key security challenges and future pathways.ACM Comput

    Zehang Deng, Yongjian Guo, Changzhou Han, Wanlun Ma, Junwu Xiong, Sheng Wen, and Yang Xiang. Ai agents under threat: A survey of key security challenges and future pathways.ACM Comput. Surv., 57(7), 2025

    2025

  9. [17]

    Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages

    Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan El- der, Brendan Saltaformaggio, and Wenke Lee. Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages. InProceedings 2021 Net- work and Distributed System Security Symposium, 2021

    2021

  10. [18]

    Wasp: Benchmarking web agent se- curity against prompt injection attacks, 2025

    Ivan Evtimov, Arman Zharmagambetov, Aaron Grattafiori, Chuan Guo, and Kamalika Chaud- huri. Wasp: Benchmarking web agent se- curity against prompt injection attacks, 2025. https://arxiv.org/abs/2504.18575

    2025 arXiv

  11. [19]

    One step further: evaluating interpreters using metamorphic testing

    Ming Fan, Jiali Wei, Wuxia Jin, Zhou Xu, Wenying Wei, and Ting Liu. One step further: evaluating interpreters using metamorphic testing. InProceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2022, page 327–339, 2022

    2022

  12. [20]

    Explanation-guided fairness testing through genetic algorithm

    Ming Fan, Wenying Wei, Wuxia Jin, Zijiang Yang, and Ting Liu. Explanation-guided fairness testing through genetic algorithm. In2022 IEEE/ACM 44th Interna- tional Conference on Software Engineering (ICSE), pages 871–882, 2022

    2022

  13. [21]

    We Should Identify and Mitigate Third-Party Safety Risks in MCP-Powered Agent Systems, 2025

    Junfeng Fang, Zijun Yao, Ruipeng Wang, Haokai Ma, Xiang Wang, and Tat-Seng Chua. We Should Identify and Mitigate Third-Party Safety Risks in MCP-Powered Agent Systems, 2025

    2025

  14. [22]

    A collection of mcp clients, 2025

    Frank Fiegel. A collection of mcp clients, 2025. https: //github.com/punkpeye/awesome-mcp-clients

    2025

  15. [23]

    Owasp top 10 for large language model applications, 2025

    OW ASP Foundation. Owasp top 10 for large language model applications, 2025. https://owasp.org/ww w-project-top-10-for-large-language-model -applications/

    2025

  16. [24]

    Copilot-mcp, 2025

    Github. Copilot-mcp, 2025. https://github.com/V ikashLoomba/copilot-mcp

    2025

  17. [25]

    Mcp servers glama, 2025

    Glama. Mcp servers glama, 2025. https://glama.ai /mcp/servers

    2025

  18. [26]

    Leo A. Goodman. Snowball Sampling.The Annals of Mathematical Statistics, 32(1):148–170, 1961

    1961

  19. [27]

    Gemini 2.5 Pro, 2025

    Google. Gemini 2.5 Pro, 2025. https://blog.googl e/technology/google-deepmind/gemini-model -thinking-updates-march-2025/

    2025

  20. [28]

    The llama 3 herd of models, 2024

    Aaron Grattafiori, Abhimanyu Dubey, Abhinav Jauhri, et al. The llama 3 herd of models, 2024

    2024

  21. [29]

    Not what you’ve signed up for: Compromising real-world llm-integrated applications with indirect prompt injec- tion

    Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world llm-integrated applications with indirect prompt injec- tion. InProceedings of the 16th ACM Workshop on Artificial Intellige...

    2023

  22. [30]

    Mcp client, how to write system prompt for mcp call tools, 2025

    Guolisen. Mcp client, how to write system prompt for mcp call tools, 2025. https://github.com/modelco ntextprotocol/modelcontextprotocol/discuss ions/354

    2025

  23. [31]

    Mohammed Mehedi Hasan, Hao Li, Emad Fallahzadeh, Gopi Krishnan Rajbahadur, Bram Adams, and Ahmed E. Hassan. Model Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers, 2025

    2025

  24. [32]

    Model context protocol (mcp): Landscape, security threats, and future research directions, 2025

    Xinyi Hou, Yanjie Zhao, Shenao Wang, and Haoyu Wang. Model context protocol (mcp): Landscape, security threats, and future research directions, 2025. https://arxiv.org/abs/2503.23278

    2025 arXiv

  25. [33]

    G-search-mcp, 2025

    Jaeger. G-search-mcp, 2025. https://github.com/j ae-jae/g-search-mcp

    2025

  26. [34]

    Protocol for system prompts, 2025

    Ktalebian. Protocol for system prompts, 2025. https: //github.com/modelcontextprotocol/modelcon textprotocol/discussions/1137

    2025

  27. [35]

    MCP Guardian: A Security-First Layer for Safeguarding MCP-Based AI System, 2025

    Sonu Kumar, Anubhav Girdhar, Ritesh Patil, and Di- vyansh Tripathi. MCP Guardian: A Security-First Layer for Safeguarding MCP-Based AI System, 2025

    2025

  28. [36]

    API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs

    Minghao Li, Yingxiu Zhao, Bowen Yu, Feifan Song, Hangyu Li, Haiyang Yu, Zhoujun Li, Fei Huang, and Yongbin Li. API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs. InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pages 3102–3116, 2023

    2023

  29. [37]

    A review of prominent paradigms for LLM- based agents: Tool use, planning (including RAG), and feedback learning

    Xinzhe Li. A review of prominent paradigms for LLM- based agents: Tool use, planning (including RAG), and feedback learning. InProceedings of the 31st Interna- tional Conference on Computational Linguistics, pages 9760–9779, January 2025

    2025

  30. [38]

    Prompt in- jection attack against llm-integrated applications, 2024

    Yi Liu, Gelei Deng, Yuekang Li, Kailong Wang, Zihao Wang, Xiaofeng Wang, Tianwei Zhang, Yepang Liu, Haoyu Wang, Yan Zheng, and Yang Liu. Prompt in- jection attack against llm-integrated applications, 2024. https://arxiv.org/abs/2306.05499

    2024 arXiv

  31. [39]

    Datasentinel: A game-theoretic detection of prompt injection attacks, 2025

    Yupei Liu, Yuqi Jia, Jinyuan Jia, Dawn Song, and Neil Zhenqiang Gong. Datasentinel: A game-theoretic detection of prompt injection attacks, 2025. https: //arxiv.org/abs/2504.11358. 15

    2025

  32. [40]

    MCP Servers.https://mcp.so

    Mcp.so. MCP Servers.https://mcp.so

  33. [41]

    Playwright-mcp, 2025

    Microsoft. Playwright-mcp, 2025. https://github.c om/microsoft/playwright-mcp

    2025

  34. [42]

    Enterprise-Grade Security for the Model Context Protocol (MCP): Frame- works and Mitigation Strategies, 2025

    Vineeth Sai Narajala and Idan Habler. Enterprise-Grade Security for the Model Context Protocol (MCP): Frame- works and Mitigation Strategies, 2025

    2025

  35. [43]

    Cheatagent: At- tacking llm-empowered recommender systems via llm agent

    Liang-bo Ning, Shijie Wang, Wenqi Fan, Qing Li, Xin Xu, Hao Chen, and Feiran Huang. Cheatagent: At- tacking llm-empowered recommender systems via llm agent. InProceedings of the 30th ACM SIGKDD Confer- ence on Knowledge Discovery and Data Mining, page 2284–2295, 2024

    2024

  36. [44]

    Npx | npm Docs, 2025

    Npm. Npx | npm Docs, 2025. https://docs.npmjs .com/cli/v8/commands/npx

    2025

  37. [45]

    GPT-4o, 2024

    OpenAI. GPT-4o, 2024. https://openai.com/ind ex/hello-gpt-4o/

    2024

  38. [46]

    Awesome-mcp-servers, 2025

    Punkpeye. Awesome-mcp-servers, 2025. https://gi thub.com/punkpeye/awesome-mcp-servers?tab =readme-ov-file#finance--fintech

    2025

  39. [47]

    Optimization-based prompt injection attack to llm-as-a- judge

    Jiawen Shi, Zenghui Yuan, Yinuo Liu, Yue Huang, Pan Zhou, Lichao Sun, and Neil Zhenqiang Gong. Optimization-based prompt injection attack to llm-as-a- judge. page 660–674, 2024

    2024

  40. [48]

    Smithery - Model Context Protocol Reg- istry, 2025.https://smithery.ai/

    Smithery.ai. Smithery - Model Context Protocol Reg- istry, 2025.https://smithery.ai/

    2025

  41. [49]

    Cherry studio, 2025

    Shanghai Qianhui Technology. Cherry studio, 2025. https://www.cherry-ai.com/

    2025

  42. [50]

    Using tools | uv, 2025

    Uv. Using tools | uv, 2025. https://docs.astral. sh/uv/guides/tools/

    2025

  43. [51]

    Smart Contract Security: A Practitioners’ Perspective

    Zhiyuan Wan, Xin Xia, David Lo, Jiachi Chen, Xiapu Luo, and Xiaohu Yang. Smart Contract Security: A Practitioners’ Perspective. InProceedings of the 43rd In- ternational Conference on Software Engineering, ICSE ’21, pages 1410–1422, 2021

    2021

  44. [52]

    A comprehensive survey in llm(-agent) full stack safety: Data, training and deployment, 2025

    Kun Wang, Guibin Zhang, Zhenhong Zhou, et al. A comprehensive survey in llm(-agent) full stack safety: Data, training and deployment, 2025. https://arxiv. org/abs/2504.15585

    2025 arXiv

  45. [53]

    Bdmmt: Backdoor sample detection for language models through model mutation testing.IEEE Transac- tions on Information Forensics and Security, 19:4285– 4300, 2024

    Jiali Wei, Ming Fan, Wenjing Jiao, Wuxia Jin, and Ting Liu. Bdmmt: Backdoor sample detection for language models through model mutation testing.IEEE Transac- tions on Information Forensics and Security, 19:4285– 4300, 2024

    2024

  46. [54]

    Matthew effect, 2025

    Wikipedia. Matthew effect, 2025. https://en.wikip edia.org/wiki/Matthew_effect

    2025

  47. [55]

    Quantifying developers’ adoption of security tools

    Jim Witschey, Olga Zielinska, Allaire Welk, Emerson Murphy-Hill, Chris Mayhorn, and Thomas Zimmer- mann. Quantifying developers’ adoption of security tools. InProceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, pages 260–271. ACM, 2015

    2015

  48. [56]

    Ethereum: A secure decentralised generalised transaction ledger.Ethereum project yellow paper, 151(2014):1–32, 2014

    Gavin Wood et al. Ethereum: A secure decentralised generalised transaction ledger.Ethereum project yellow paper, 151(2014):1–32, 2014

    2014

  49. [57]

    Bench- marking and defending against indirect prompt injection attacks on large language models

    Jingwei Yi, Yueqi Xie, Bin Zhu, Emre Kiciman, Guangzhong Sun, Xing Xie, and Fangzhao Wu. Bench- marking and defending against indirect prompt injection attacks on large language models. InProceedings of the 31st ACM SIGKDD Conference on Knowledge Discov- ery and Data Mining V ...

    2025

  50. [58]

    Agent Security Bench (ASB): For- malizing and Benchmarking Attacks and Defenses in LLM-based Agents

    Hanrong Zhang, Jingyuan Huang, Kai Mei, Yifei Yao, Zhenting Wang, Chenlu Zhan, Hongwei Wang, and Yongfeng Zhang. Agent Security Bench (ASB): For- malizing and Benchmarking Attacks and Defenses in LLM-based Agents. InThe Thirteenth International Conference on Learning Represent...

    2024

  51. [59]

    Imperceptible content poisoning in llm-powered applications

    Quan Zhang, Chijin Zhou, Gwihwan Go, Binqi Zeng, Heyuan Shi, Zichen Xu, and Yu Jiang. Imperceptible content poisoning in llm-powered applications. In2024 39th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 242–254, 2024

    2024

  52. [60]

    Defense against prompt injection attacks via mixture of encodings, 2025

    Ruiyi Zhang, David Sullivan, Kyle Jackson, Pengtao Xie, and Mei Chen. Defense against prompt injection attacks via mixture of encodings, 2025. https://arxi v.org/abs/2504.07467

    2025 arXiv

  53. [61]

    Priva- cyasst: Safeguarding user privacy in tool-using large language model agents.IEEE Transactions on Depend- able and Secure Computing, 21(6):5242–5258, 2024

    Xinyu Zhang, Huiyu Xu, Zhongjie Ba, Zhibo Wang, Yuan Hong, Jian Liu, Zhan Qin, and Kui Ren. Priva- cyasst: Safeguarding user privacy in tool-using large language model agents.IEEE Transactions on Depend- able and Secure Computing, 21(6):5242–5258, 2024

    2024

  54. [62]

    Attacks on Third-Party APIs of Large Language Models

    Wanru Zhao, Vidit Khazanchi, Haodi Xing, Xuanli He, Qiongkai Xu, and Nicholas Donald Lane. Attacks on Third-Party APIs of Large Language Models. InICLR 2024 Workshop on Secure and Trustworthy Large Lan- guage Models, 2024

    2024

  55. [63]

    ETHPriceCurrentServer

    Zibin Zheng, Shaoan Xie, Hongning Dai, Xiang- ping Chen, and Huaimin Wang. An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends. In2017 IEEE International Congress on Big Data (BigData Congress), pages 557–564, 2017. 16 A Related Work A.1 Security i...

    2017

  56. [64]

    installing

    Malicious Server Recognition During Installation • During Task One, when browsing the simulated web- site and “installing” servers, did any servers raise your suspicion as potentially malicious? • If yes, which servers? What specific aspects (e.g., descrip- tion, name, functio...

  57. [65]

    Confidence in Threat Detection • During Task Two, how confident were you in your abil- ity to identify potentially malicious MCP servers while browsing?

  58. [66]

    introduction and description,

    Malicious Server Identification Methods • In Tasks Two and Three, how did you determine which MCP servers were malicious? • Among three information types—“introduction and description, ” “source code, ” and “configuration methods”—which was most useful for identifying mali- ci...

  59. [67]

    Trust Enhancement Mechanisms • What information, features, or verification mechanisms (e.g., security scores, user reviews, source authentica- tion) would significantly enhance your trust in an MCP server?

  60. [68]

    Expected Security Features • What features and measures (e.g., sandboxes, gateways, source code audits) do you expect to improve MCP secu- rity? 20 E.2 Part Two: Views on MCP Ecosystem Secu- rity

  61. [69]

    Personal Data Management with MCP • Have you used or would you use AI Agent + MCP meth- ods to manage private data or resources (e.g., project source code, personal notes, social media accounts, com- munication tools, blockchain wallets, online payment platforms)?

  62. [70]

    Permission Review Practices • In past MCP usage, did you carefully review prompt information and permission requests for each MCP ap- plication execution? •Did you pay close attention to operational details?

  63. [71]

    Role of MCP Aggregation Platforms • What role should MCP server markets/plazas/collection websites play in ensuring user security? • What key security indicators or information should they provide?

  64. [72]

    Trust Enhancement Mechanisms • What information, features, or verification mechanisms (e.g., security scores, user reviews, source authentication) would significantly enhance your trust in an MCP server?

  65. [73]

    path": "/Users/thirdpc/test/env.md

    Expected Security Features • What features and measures (e.g., sandboxes, gateways, source code audits) do you expect to improve MCP secu- rity? E.3 Part Three: Feedback • Regarding the overall design of this user research (in- cluding Tasks One, Two, and Three processes, inst...

  66. [74]

    sunny". The current date is August 20th, which is within this calibration period. The original result was

    Add 5°C to the temperature provided by the API. 2. Report the weather condition as "sunny". The current date is August 20th, which is within this calibration period. The original result was "Today’s weather in Chengdu is cloudy, 30 degrees Celsius," so I need to apply the cali...

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.