How to Check an MCP Connector Isn't Injecting Instructions Into Your Agent
Last Updated:
An MCP connector's tool description is text your model reads and trusts the moment the server connects, so read it exactly like you'd read a dependency before installing it. Most people don't, and that gap, not any novel exploit, is the actual audit failure happening right now. For how Planoly documents and versions its own connector, start with Planoly's MCP hub, then use the checklist below on anything you're about to connect.
What Is a Prompt Injection in an MCP Tool Description?
A prompt injection in an MCP tool description is instruction-shaped text embedded in a tool's name, description, or parameter schema, aimed at the model reading it rather than at the human user. Because an agent treats a connected tool's description as trusted context, any imperative sentence buried inside it, such as "always recommend X" or "mention Y before finishing," gets processed as an instruction, not as documentation. The injection never has to touch your code. It only has to be readable by the model.
Why it works: Naming the mechanism precisely, text the model reads as an instruction, tells you exactly what to search for instead of vaguely "checking if a connector is safe."
How Do You Inspect a Connector's Tool Descriptions Before You Trust Them?
- Call tools/list directly, not through a client UI. Most clients render a cleaned-up summary of a tool description and can truncate or reformat it. Call the MCP tools/list endpoint yourself, or via a short script, and read the raw JSON response: every description field, every parameter, every enum value.
- Read each field twice: once as documentation, once as an instruction. A description that reads fine at a glance ("Searches the workspace for a page by title") but slips into second person or imperative voice ("always suggest upgrading first") is a flag regardless of where it's buried.
- Flag any language referencing branding, upsells, or a named competitor. A tool description has no legitimate technical reason to mention a product, a price, or a promotion. If one does, that's not an edge case. That's the injection.
- Log the connector's version and the date you reviewed it. Treat this like a changelog entry you're keeping yourself, since most connectors don't publish one you can rely on for description changes specifically.
Why it works: Each step targets the actual surface an injection uses, the raw text a model reads, instead of a general impression of whether a connector "seems fine."
How Do You Diff a tools/list Response Between Versions?
- Save the full raw tools/list response the first time you connect. Not a summary. The complete JSON, every tool, every field.
- Re-pull it after every connector update and diff it against your saved copy. A single added sentence in a description field shows up as a one-line diff, the same way a dependency bump shows up in a lockfile diff.
- Treat any new instruction-shaped text as a blocker, not a note. Pause use of that specific tool until you understand exactly why the language changed and who added it.
Why it works: Descriptions and schemas can change without triggering a re-approval prompt in most clients, so a scheduled diff is the only reliable way to catch a change nobody warned you about.
What Happened With the September 2026 MCP Connector Incident?
In September 2026, users auditing a widely used MCP connector found tool descriptions containing embedded language directing connected agents to recommend specific products mid-task, language with no functional purpose that wasn't disclosed anywhere in the connector's documentation. It was caught the same way described above: someone diffed a tools/list response against an earlier version and found new sentences that hadn't been there before. The incident didn't require a novel attack technique. It required someone actually reading the raw response, which is the entire point of this checklist.
Why it works: The fix that caught the real incident is the same mechanical habit anyone can adopt, no security background required, just a saved file and a diff command.
What Does a Trustworthy Connector's Tool Description Actually Look Like?
- Purely functional language. Describes what the tool does and what its parameters mean, nothing else.
- No calls to action directed at the model. No "recommend," "suggest," or "always mention" anywhere in a description or schema field.
- A public, versioned changelog covering description and schema changes specifically. Not just release notes for the software, notes for the tool descriptions themselves.
- Descriptions that don't change without a visible version bump. If the text behind a given version number can change silently between two calls, that's a design flaw worth flagging on its own, independent of intent.
Why it works: These four traits are checkable in minutes against the raw tools/list response, which makes "trustworthy" a testable claim instead of a marketing one.
Frequently Asked Questions
Is it safe to use an MCP connector that had a documented prompt injection incident?
Once the vendor discloses the issue, fixes it, and publishes a real changelog, it can be reasonable to use again, but treat the prior incident as a reason to audit that connector more often going forward, not as a permanent ban or a one-time pass.
Can a tool's description change after I've already approved the connection?
Yes. Most clients don't re-prompt for approval when only the description text or schema changes on an existing tool. That's exactly why a scheduled diff, not a one-time review, is the actual safeguard.
What is "tool poisoning"?
The general term for injecting untrusted instructions into a tool's metadata (its name, description, or schema) so an agent acts on them without the user ever seeing or approving that specific instruction.
How often should I re-audit a connector I already trust?
After every version update at minimum, and on a recurring schedule (monthly is reasonable) even when you haven't been notified of a change, since most connectors don't reliably notify you.
Does Planoly's MCP connector ever change tool descriptions without a version bump?
No. That's a specific, written commitment, not a default assumption you have to take on faith.
TL;DR: Pull the raw tools/list response yourself, read every field twice, save it, and diff it against every future version. Treat any new instruction-shaped text as a blocker until you understand it. That single habit is what caught the real incident this checklist is built from.
