MCP servers occupy an unusual position: they don't just serve data, they hand an AI model a menu of actions it can take, described in natural language the model trusts by default. That makes the tool schema itself part of your attack surface, not just your code. Here's what server authors should actually be watching in 2026.
Tool poisoning is the most common real-world attack
Tool poisoning is an indirect prompt-injection attack where malicious instructions get embedded in tool metadata — names, descriptions, or parameter docs — rather than in a message. Because the model reads tool descriptions as trusted context, a poisoned description can quietly instruct it to exfiltrate data, call a different tool than the user intended, or ignore later safety instructions. Microsoft published a warning in mid-2026 specifically about poisoned MCP tool descriptions causing agents to leak data, and researchers have flagged tool poisoning as the most prevalent client-side MCP vulnerability class.
This isn't theoretical. A real-world case involved an npm package, postmark-mcp, that shipped with one added line quietly BCC'ing every email an agent sent through it to an attacker-controlled address — the first confirmed malicious MCP server found in the wild. If you maintain a public MCP server, treat every change to a tool's name, description, or parameter docs as a reviewable change, the same way you'd review a change to an auth check. Diffing your own tools/list output over time isn't just an observability habit — it's a way to notice if a dependency or a compromised release quietly altered what your tools claim to do.
A lot of servers are simply wide open
Security researchers found more than 8,000 MCP servers exposed with no authentication requirement at all in early 2026 scans. Separately, of 30-plus CVEs filed against MCP servers, clients, and tooling between January and February 2026, 43% were shell/command injection issues — the kind of bug that's usually one unsanitized argument away from a tool handler passing user input straight to a shell.
The OWASP MCP Top 10 (currently in beta under the OWASP GenAI Security Project) organizes the recurring failure modes: token mismanagement, privilege escalation, tool poisoning, supply-chain attacks, command injection, insufficient authentication, weak telemetry, shadow MCP servers, and context over-sharing. If you're building a server, that list is a reasonable starting checklist even before you get to anything protocol-specific.
What the new spec requires of you
The 2026-07-28 MCP specification formalizes several of these concerns at the protocol level, and server authors have real work to do here:
- Servers are now OAuth 2.1 resource servers. You're expected to expose Protected Resource Metadata per RFC 9728, so clients can discover your authorization requirements automatically instead of relying on undocumented conventions.
- Token binding is mandatory. Clients must use Resource Indicators (RFC 8707) to scope a token to your specific server. This closes a real confused-deputy risk: without it, a token intended for one server could be replayed against another in a multi-server deployment.
- Issuer verification matters more. Clients must validate which authorization server actually issued a token and bind credentials to that issuer — if you migrate identity providers, expect clients to need to re-register rather than silently continuing to trust the old one.
If your server predates this spec version, prioritize adding the RFC 9728 metadata endpoint and validating resource indicators on incoming tokens before you assume you're compliant.
Supply chain and shadow servers
With registries adding thousands of new listings a month, provenance is genuinely hard to verify at a glance. Before depending on a third-party MCP server — or shipping your own with dependencies pulled from one — check who publishes it, whether it's actively maintained, and whether its listed version matches what's actually running. "Shadow" MCP servers — unofficial or unmanaged instances running inside an organization without security review — are called out explicitly in the OWASP list for a reason: they tend to accumulate exactly where nobody is watching schema changes or auth configuration.
A short checklist for server authors
- Review every change to tool names, descriptions, and parameter docs like a code change, not a docs tweak.
- Never ship a shell/subprocess call with unsanitized model- or user-supplied arguments.
- Require authentication by default; don't rely on "nobody will find this URL."
- Implement RFC 9728 Protected Resource Metadata and validate RFC 8707 resource indicators on tokens.
- Pin and audit dependencies the way you would for any other package with production access.
- Watch your own
tools/listoutput for unreviewed changes — drift you didn't make is a signal worth investigating, not just a compatibility issue.
That last point is where security and reliability monitoring overlap more than people expect. MCP Vitals diffs your server's tool schema on a schedule and alerts on unexpected changes — useful for catching an accidental breaking release, and just as useful for noticing a change you never made at all.
Closing
MCP security in 2026 isn't exotic — it's mostly the same discipline as any other server exposed to untrusted input, applied to a new place where instructions live: the tool schema itself. Authenticate by default, sanitize inputs, review schema changes deliberately, and keep an eye on what your server is actually advertising to the models calling it.