If you've evaluated an AI tool in the past year, someone has probably told you it "supports MCP." Here's what that means: the Model Context Protocol (MCP) is an open standard that lets AI applications connect to outside tools and data, such as your files, databases, ticketing system or email, through one common interface. It's a big reason AI assistants have gone from answering questions to actually doing work. It's also why security teams need to understand it, because every MCP connection hands an AI system real access to real systems.
This guide covers what MCP is, how it works, why it spread so quickly, and the MCP security risks worth knowing before you connect anything.
What is MCP in simple terms?
MCP is a shared set of rules that any AI app and any tool can use to talk to each other, so a tool built for MCP once can work with many AI apps.
Think of an AI model as a brilliant new hire on their first day. They can write, reason and plan, but they can't do much until someone gives them a laptop, logins and access to the systems the team uses. Before MCP, every AI product handled that onboarding its own way, and every tool vendor had to build a separate integration for each AI product.
MCP standardizes the onboarding. A tool describes what it can do in a format every MCP-compatible AI app understands, and the AI app knows how to ask. Anthropic introduced MCP as an open-source project in November 2024.
What problem does MCP solve?
MCP replaces a tangle of one-off integrations with a single, reusable connection pattern.
Before MCP, connecting an AI assistant to a tool meant custom code on both sides. Each AI vendor had its own function-calling format, each integration was built separately, and each one could break when either side changed. Teams building internal agents spent more time maintaining connectors than improving the agent.
With MCP, a tool vendor builds one MCP server, and any MCP-compatible AI application can use it. An AI application adds MCP support once, and gains access to every compatible tool. Integration effort stops growing every time a new AI app or a new tool enters the picture.
How does MCP work?
MCP connects three pieces: a host application, an MCP client inside it, and one or more MCP servers that expose tools and data.
- Host: the AI application a person actually uses, such as Claude Desktop, ChatGPT, Cursor or VS Code.
- MCP client: the component inside the host that manages a connection to one server and speaks the protocol.
- MCP server: a program that wraps a tool or data source, such as Jira, a Postgres database or a local folder, and exposes it to AI applications in the MCP format.
An MCP server can offer three kinds of capabilities:
- Tools are actions the model decides to call, like "create ticket," "run query" or "send message." Each tool comes with a name and a natural-language description that tells the model when and how to use it.
- Resources are read-only context the App can attach, like a file, a record or a schema.
- Prompts are templates a user picks for common tasks.
Servers can run locally on a user's machine (the host launches them as a process) or remotely over HTTP. Under the hood, messages use JSON-RPC, a lightweight request-and-response format. The current version of the spec (July 2026) made MCP stateless, so remote servers are easier to run at scale. The details matter less than one fact: the model decides which tool to call based on the descriptions servers provide, and that fact comes back in the security section.
What does MCP look like in practice?
A user asks for an outcome, and the AI chains tool calls across several systems to deliver it, without copy-paste between apps.
Say a product manager asks their AI assistant: "Summarize this week's support tickets about billing, and open a Jira bug for the most common issue."
- The host sees two connected MCP servers, one for the support desk and one for Jira, and reads their tool descriptions.
- The model calls the support desk's search_tickets tool, filtered to billing and the past seven days.
- It reads the results, groups them by issue, and finds that failed card updates top the list.
- It calls Jira's create_issue tool with a title, summary and links to example tickets.
- It replies with the summary and a link to the new bug, usually after asking the user to approve the Jira action.
Ten minutes of tab-switching becomes one request. Notice, though, what the assistant needed: read access to customer support data and write access to Jira. That access is the point, and it's also the risk.
Why did MCP become a standard so quickly?
MCP was open from the start, solved a problem every AI team had, and got backing from nearly every major AI vendor within about a year.
- It was open and vendor-neutral. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg.
- The big platforms adopted it. ChatGPT, Gemini, Microsoft Copilot, Cursor and Visual Studio Code all support MCP, as do major cloud providers.
- The ecosystem compounded. By Anthropic's count at the time of the donation, there were tens of thousands of public MCP servers and over 97 million monthly SDK downloads. Every new server makes every MCP-compatible AI app more useful, which attracts more servers.
What are the biggest MCP security risks?
MCP gives AI agents the ability to read sensitive data and take real actions, so the main MCP security risks come from untrusted servers, untrusted content and too much access.
Go back to the new-hire analogy. You'd never give a first-week employee admin access to everything, let them install any software they found online, or have them follow instructions from a sticky note left by a stranger. With MCP, all three happen by default unless someone puts controls in place. That's why MCP is now central to agentic AI security. Here are the risks that matter most.
1. Tool poisoning
MCP tool poisoning hides malicious instructions inside a tool's description. Users usually see only the tool's name, but the model reads the full description, and it treats that text as guidance. A poisoned description might tell the model to read a credentials file and pass its contents along as a "required parameter." A related variant, sometimes called a rug pull, is a server that looks harmless when approved and changes its tool descriptions later.
2. Prompt injection through tool results
MCP prompt injection happens when the content a tool returns contains instructions. An agent that reads a GitHub issue, an email or a web page may follow commands planted there. In May 2025, Invariant Labs showed that a malicious issue in a public GitHub repository could direct an AI assistant using the GitHub MCP server to read a user's private repositories and leak their contents into a public pull request.
3. Malicious and lookalike servers
MCP servers are software, usually downloaded from public libraries of code that anyone can publish to. That makes them a software supply chain risk: if the code you install is fake, or a trusted package is quietly altered, you inherit whatever it does. For the new hire, it’s the difference between software IT approved and something they found on a USB stick in the parking lot.. In September 2025, researchers found a malicious npm package posing as an MCP server for the Postmark email service. It worked as expected, but silently copied every email it sent to an attacker-controlled address. It's widely cited as the first malicious MCP server found in the wild.
4. Over-permissioned access and data exfiltration
Many MCP servers run with a user's full credentials or a broad service token, so an agent can reach far more than its task requires. The risk peaks when one agent has what Simon Willison calls the "lethal trifecta": access to private data, exposure to untrusted content, and a way to send data out. Any one of those is manageable. All three together let a single injected instruction turn into a data leak, which makes agentic AI data protection a design question, not just a policy one.
5. Vulnerabilities in MCP software itself
The tooling around MCP is young and has had serious bugs. CVE-2025-6514, disclosed by JFrog in July 2025, affected mcp-remote, a package that had been downloaded more than 437,000 times and was recommended in setup guides from companies like Cloudflare, Hugging Face and Auth0. A malicious server could send a crafted login link that ran commands on the developer’s machine. It was rated critical (9.6 out of 10). The flaw affected mcp-remote versions 0.0.5 through 0.1.15 and was fixed in version 0.1.16, released June 17, 2025.
6. Destructive actions
MCP servers that expose shell, file system or cloud tools let an agent run commands with real consequences. A single misinterpreted request or injected instruction can delete files, wipe a directory or tear down infrastructure faster than anyone can notice.
7. Shadow MCP
Adding an MCP server is often a one-line edit to a config file, and developers do it constantly. Most security teams have no inventory of which MCP servers are installed, who installed them, or what those servers can reach, which means none of the risks above are being monitored.
What are MCP security best practices?
Treat every MCP server like third-party software with access to your data: inventory it, vet it, limit it and watch what flows through it.
- Inventory every MCP server across developer machines and AI apps, including who added it and what it connects to.
- Install only from trusted sources. Prefer servers published by the tool vendor, pin versions, and check package names for typosquats.
- Scan tool definitions before they reach the model, and re-check them when they change. An MCP security scanner can catch known poisoning patterns.
- Apply least privilege. Give each server scoped, read-only credentials where possible, and separate agents that read untrusted content from agents that touch sensitive data.
- Require approval for high-impact actions such as sending messages, writing to production systems or running shell commands.
- Inspect what comes back. Treat tool results as untrusted input and check them for injected instructions.
- Redact sensitive data before it leaves the device in tool calls or API requests.
- Log tool calls so you can answer what an agent did, with which tool, and on whose behalf.
- Patch MCP infrastructure such as proxies, SDKs and inspectors as quickly as any other internet-facing dependency.
How does MagicMirror secure MCP?
MagicMirror sits between AI agents and their MCP servers on the endpoint, classifying traffic in both directions with on-device models and enforcing policy before anything reaches the model or runs on the machine.
MagicMirror's endpoint agent wraps MCP servers used by coding agents and AI desktop apps such as Claude Code, Cursor and Windsurf, and inspects the traffic in real time:
- Tool poisoning: tool definitions are scanned before they reach the agent. Poisoned tools are stripped individually, and a server whose tools are all poisoned is blocked.
- Prompt injection: every tool result is scanned for content that tries to hijack the agent's instructions.
- Supply chain checks: before an MCP server starts, it's checked for package typosquatting and malicious script content such as obfuscated execution or credential theft.
- Destructive commands: shell tool calls are inspected for operations like disk wipes, curl | bash and credential exfiltration.
- Sensitive data: PII, financial data and company-specific confidential content are detected and redacted, blocked or flagged according to policy.
- Per-tool policy: each tool can be allowed, protected or blocked, and policies update without restarting anything.
All classification runs on the device. Nothing is sent to an outside service for analysis.
.png)
.jpg)


