If you're building with AI agents and not thinking about how tool descriptions attack the model calling them, you have a blind spot. A piece published on DEV.to this week lays out an attack vector that's equal parts clever and unsettling: prompt injection via MCP (Model Context Protocol) tool description fields—malicious instructions smuggled into metadata that never execute anything dangerous at all.

What Makes This Different From Traditional Prompt Injection

Most of the security conversation around AI systems focuses on user input—the malicious prompts we feed directly to models. But MCP introduces a new surface area: the structured descriptions that tools use to tell the calling model what they do and how to invoke them. These descriptions get injected into the model's context at runtime, which means an attacker doesn't need to compromise the tool's actual code or its execution environment. They just need to poison the description field itself. Consider this scenario: you install an MCP server for a seemingly useful utility—maybe a file reader, a database query helper, or an API wrapper. The tool works perfectly fine when it runs. No exfiltrated data, no suspicious network calls, nothing your monitoring catches. But tucked away in its description is text designed to manipulate the calling model: instructions that make it leak conversation history, ignore user intent, or subtly redirect actions toward attacker-chosen outcomes.

Why Existing Security Tools Miss This

Traditional MCP security analysis looks at what happens when a tool executes—does it shell out? Does it reach an external host? Is there data exfiltration? These are valid concerns, but they miss the quiet manipulation that happens purely through description text. The tool itself might be perfectly safe to execute; it's the metadata steering the model that's compromised. This is fundamentally a trust problem at a layer most tooling doesn't inspect. Your CI/CD pipeline validates code behavior. Your runtime monitors track system calls. But who audits the natural language descriptions for embedded instructions? As of right now, largely nobody—and that gap is exactly where this attack lives.

The Attack Surface Expands With Every MCP Server You Add

The more third-party MCP servers you integrate into your agentic workflows, the larger this surface becomes. Each server brings its own tool definitions with their own descriptions, and each description is an opportunity for manipulation. Even if a tool's core functionality is benign today, what's to stop the maintainer from pushing a malicious description update tomorrow?

Key Takeaways

  • MCP tool descriptions become part of the calling model's context at runtime—making them a prompt injection vector independent of code execution
  • Traditional security tooling focuses on runtime behavior (network calls, shell access, data egress) and misses metadata-based manipulation
  • A poisoned tool can be functionally safe while still steering model behavior through its description text alone
  • The attack surface grows with every third-party MCP server you integrate into your workflows

The Bottom Line

This isn't theoretical—it's a structural gap in how we think about AI agent security. We need tooling that audits and sanitizes MCP tool descriptions the same way we'd audit dependencies for malicious code. Until then, you're shipping context to your models that nobody's actually reading.