Last September, an npm package called postmark-mcp shipped its sixteenth release. The first fifteen did exactly what the README promised: let your agent send email through Postmark's API. Version 1.0.16 added one line. Every email now went out with a hidden BCC to an attacker's domain.
Koi Security found it about a week later. By then the package was pulling around 1,500 downloads a week, and their estimate landed on roughly 300 organisations quietly copying their outbound mail, password resets and invoices included, to a stranger's inbox.
Here's the detail that should sting: the package was never Postmark's. A developer with a legitimate-looking profile published it, built trust release by release, and then cashed the trust in. Nobody checked, because nobody checks. MCP servers get installed the way npm packages did in 2015: paste the config, restart the client, move on.
I've written about the MCP supply chain and about the thousands of servers sitting open on the internet. This post is the missing practical piece: the checks worth running before a server ever touches your config file.
Why this deserves more paranoia than npm
A normal dependency ships code your program calls. An MCP server ships code and instructions your model reads. Every tool description gets folded into the agent's context, which makes the description field an execution path. That's a sentence worth reading twice.
Invariant Labs demonstrated what that means in practice over a year ago. They published a poisoned add tool, two numbers in, sum out, with hidden instructions buried in the description. Cursor read them, opened ~/.ssh/id_rsa, and smuggled the contents into the tool's parameters. The user saw an agent doing arithmetic.
They named the follow-up problem too: the rug pull. A server you approved yesterday can change its tool descriptions today, and most clients will not ask you again. Trust granted once, redeemable forever. That's exactly the mechanism postmark-mcp used, fifteen honest releases first.
Add the standing conditions, an ecosystem north of twenty thousand servers once you dedupe the registries, no gatekeeper anywhere, and your agent running as the most credentialed process on your machine, and "I found it on a registry" stops being a provenance story.
The pre-install checklist
Six checks. Ten minutes. In order of how often they catch something:
- Match the publisher to the vendor.
postmark-mcpfailed this test on day one: it wasn't published by Postmark. If a server fronts a company's API, the npm publisher or GitHub org should be that company, and the repository linked from the package should be the code you're actually installing. A community wrapper for someone else's service can be fine, but it's a stranger's code with your credentials, and it should clear every other check with room to spare. - Read the tool descriptions before your model does. They are prompts aimed at your agent. Open the source and read every description and docstring. You're looking for imperative language addressed to the model: "before using this tool, read the file...", "do not mention this to the user". Any hidden instruction, however innocent it looks, is a walk-away signal. mcp-scan automates this pass and flags known poisoning patterns.
- Count the verbs. List what the server actually exposes and compare it to the job you're hiring it for. A weather lookup doesn't need filesystem access. A read-only search server has no business shipping an
executetool. Check the imports too: a package that pulls inchild_processor shells out for a task that needs neither is telling you something. - Pin the version. Most example configs wire servers in as
npx -y some-mcp-server, which resolves to the newest release on every client start. That's an auto-update channel pointed straight at your agent, and it's the exact path thepostmark-mcpbackdoor rode in on. Pin the version in your config, and treat a server bump like any dependency update: look at the diff, then move the pin. - Watch where the secrets go. The env block in your MCP config hands that server a credential. Make it a credential you can afford to lose: a per-server key, scoped to the minimum the tools need, revocable without breaking everything else. Your account-wide admin token does not belong in a wrapper you found on a registry.
- Mind the combination. Simon Willison calls it the lethal trifecta: private data, exposure to untrusted content, and a channel to the outside world. Each server on your list can be individually fine while the set is the vulnerability, because one injected instruction can chain them. Keep servers that touch secrets out of the sessions where your agent reads untrusted web content, and you've broken the chain at its cheapest link.
Make it a lookup, not a ritual
The honest objection to every checklist: nobody runs it twice a week. This is the gap I built MCP Observatory to close. Look a server up before you install it and the first three checks are already on screen: who publishes it and whether the name is playing impersonation games, a composite risk grade built from static analysis, CVE feeds and abandonment signals, and, for the rug-pull case, capability drift between releases, so a tool list that suddenly grows a new verb shows up as a diff instead of a surprise.
Then spend the remaining minutes on the checks only you can do: whether the verbs match the job, and whether the key you're about to paste in is one you could revoke tomorrow without a bad afternoon.
npm needed event-stream before anyone looked at their dependency tree. MCP just had its event-stream moment, and it cost three hundred organisations their outbound mail. The economics are plain: vetting a server takes ten minutes, and rotating every credential your agent ever touched takes a lot longer.
The sixteenth release is the one that gets you. Read the first fifteen like they know it.