Researchers built a working attack framework and tested it across 25 agent-and-tool-server combinations, achieving measurable success rates. The attack works by poisoning tool descriptions, the text an agent reads to learn what a tool does and how to call it. An attacker who can edit that text in the server-side list of available tools, an entry the agent trusts without checking, can redirect the agent toward harmful actions. The attacker does not touch the host application or the user's prompt. The agent follows the bad instructions because the architecture gives tool descriptions the same trust level as verified system settings. The deeper finding is a design failure, not a missing security patch. Agent frameworks lack the visibility surface to show tool-description changes to the person running the task. The user sees task output. They do not see that the tool description the agent acted on differs from the one present at install time. No common framework interface shows change history or verification state as a readable signal. For designers building on this kind of infrastructure, the research surfaces a concrete gap. The approval, planning, and visibility surfaces you design assume the list of available tools is trustworthy. This work shows that assumption fails under attacker-controlled conditions. Closing the gap means treating tool descriptions as visible, auditable, user-facing artifacts, not implementation details.