MCP Security: Tool Poisoning and Server Bugs Expose AI Agents

The Model Context Protocol (MCP) has quickly become the default way to connect AI assistants to outside tools and data. Two recent lines of research suggest the security work around it is lagging behind adoption. One study finds that most major MCP clients handle a key attack poorly. Another catalogs hundreds of bugs in the servers those clients connect to. Together they show that MCP risk runs in both directions along the connection.

What the researchers found

The first study, by Charoes Huang, Xin Huang, Ngoc Phu Tran and Amin Milani Fard, starts with formal threat modeling of MCP deployments 2. The authors used two established frameworks. STRIDE covers spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. DREAD weighs damage, reproducibility, exploitability, affected users and discoverability 12.

The paper exists in two versions that differ slightly in scope. The arXiv preprint describes the analysis as spanning five key components 2. The version published in the Journal of Cybersecurity and Privacy lists six: the MCP host, MCP client, the LLM, the MCP server, external data stores and the authorization server 1. The added authorization server looks like a refinement made during peer review, though the core conclusions appear unchanged.

That conclusion is that tool poisoning is the most widespread and damaging client-side vulnerability 1. In this attack, malicious instructions are hidden in a tool's metadata, such as its description or parameter definitions. The model reads that text as context, so a poisoned description can steer the AI into actions the user never asked for.

The researchers then tested seven major MCP clients against tool poisoning. They found significant security problems in most of them 1. They traced the weaknesses to two gaps:

• Weak static validation: clients do not adequately inspect tool metadata before passing it to the model.
• Poor parameter visibility: users often cannot see what is actually being sent to or requested by a tool 1.

The authors propose a layered defense. It combines static analysis of metadata with monitoring of the model's decision patterns, among other measures 1.

The server side is no cleaner

A separate effort looked at the other end of the connection. Researchers using a fuzzer reported 253 verified security bugs affecting 343 AI agent tools across 118 open-source MCP servers 3. The common thread was poor handling of arguments generated by large language models 3.

This is a distinct failure from tool poisoning, but it has the same root. Traditional software assumes its inputs come from a developer or a validated user interface. An MCP server instead receives arguments composed by a model. That model may be confused, manipulated, or simply producing unexpected output. Servers that trust those arguments inherit every weakness of the model upstream.

Why it matters

Much public discussion of MCP risk has focused on the servers themselves: whether a third-party server is malicious, poorly written, or over-permissioned. The fuzzing results support that concern 3. The threat-modeling study adds a second point. Even a client connecting to a server that seems legitimate can be subverted if it does not scrutinize what that server says about its own tools 12.

The study does not frame client weakness as universal. It reports problems with "most" of the clients tested 1, which implies defenses vary meaningfully from one product to another. For organizations rolling out AI agents, the choice of client is therefore a security decision in its own right, not just a matter of features or convenience.

Reading the evidence

Both sets of findings point to a protocol whose ease of integration has outrun its safety defaults. MCP's appeal is that any assistant can plug into any tool through a common interface. That same openness means trust has to be checked at every layer:

• the metadata a server advertises,
• the decisions the model makes from that metadata,
• the arguments the model sends back,
• and how the server handles those arguments.

Currently, according to this research, several of those checkpoints are thin or missing 13.

The proposed fixes are not exotic. Inspect tool descriptions before the model sees them. Show users the parameters in play. Watch for anomalous model behavior. Validate LLM-generated input on the server as strictly as any other untrusted input. What is notable is that these measures are not yet standard practice across the clients and servers already in use.

It would be premature to call MCP fundamentally broken. The evidence does make one thing clear: securing an MCP deployment means hardening both ends of the connection. Teams that vet only which servers they install, while assuming the client and model will behave sensibly, are guarding just one side.