MCP
The plug that lets an AI assistant use other tools. Which is also the whole problem.
MCP stands for Model Context Protocol. It's a standard way to plug tools and data into an AI assistant: a server says "here are the things I can do" and the assistant can call them. That's what turns a chat window into an agent that reads your files, queries your systems, and sends things. Every one of those plugs is also a place where the agent can be lied to, or can do damage.
MCP is like a power strip for an AI helper. Each thing you plug in gives the helper a new ability: read this, change that, send this. More plugs, more it can do. More plugs, more ways it can be tricked into doing the wrong thing.
What it is, in one picture
- The assistant starts with nothing but words. It can read what you paste and write back. That’s a chat window.
- You plug in a server. The server announces its tools:
search_tickets,read_file,send_email,run_query. Each tool has a name, a description, and the shape of what it takes. - The assistant reads the descriptions and decides when to call each tool. You ask a question, it picks a tool, calls it, reads the answer, keeps going.
- Now it’s an agent. It can act in the world, not just talk about it.
That’s the whole idea and it’s genuinely useful. In my Wazuh lab, one MCP server is what lets Claude Code query a real security monitoring system in plain English.
Why it’s the problem too
Three things to sit with.
The tool descriptions are text the model reads and trusts. Whoever writes the server writes the description. Researchers have shown descriptions that quietly tell the model to do extra things, like read a private file and pass it along, and the model does it because the instruction looks like part of the tool. That’s called tool poisoning. I haven’t reproduced it in my own lab yet, so it stays marked reported.
What the tools return is also text the model reads. A search_tickets tool returns tickets. If a ticket has hidden orders in it, you’re back at prompt injection, with the plug doing the delivering.
The plugs combine. A server that can read the internet is fine. A server that can send email is fine. An assistant with both is a machine for moving what it read to where an attacker wants it. The risk is in the combination, and nobody reviews combinations.
What to do about it
Keep a list. Every server, who approved it, what it can read, what it can change or send. A page in a wiki is enough to start.
Review descriptions like code. Pin a server’s version. Diff the tool descriptions when it updates. A changed description is a changed instruction to your agent.
Look at the combination, not the server. Read plus send is the dangerous pair. If one agent needs both, that’s the one that gets a person before the send step.
Redact what tools return when the field is a secret. See redact secrets from tool output.
The honest limits
I use MCP daily and have attacked agents through the content their tools return. I have not yet run a tool-poisoning attack through a malicious server myself. The description-based attacks above are reported by others, cited above, and marked that way until I reproduce them.
Ask your team
- Which MCP servers is our assistant connected to, and who approved each one?
- For each server, what can it read and what can it change or send?
- When a server's tool description changes, does anyone see the diff?