Plugins and MCP servers are easy to install, and that's the problem. A plugin can bundle hooks and MCP servers, and both run code on your machine. Nobody audits every community plugin (we don't either), so here's the quick check I run before installing anything.
Disclosure: I run PickAPlugin, an independent, hand-sorted catalog of ChatGPT and Codex plugins. This checklist is adapted from our guide, and it works no matter where you found the plugin.
1. Is it alive?
Look at the last commit, the open issues, and whether the repo is archived. A plugin that hasn't been touched in a long time may still work, but you'll be on your own when something in the host app changes.
2. What does it actually run?
Open .mcp.json and any hooks.json before you install. These are the parts that execute:
-
MCP servers start a process (often
npx,uvx, or a binary) that your agent talks to. - Hooks run commands on events like tool calls or session start.
If you can't tell what a command does, look it up before letting it run.
3. What does it ask for?
Tokens, filesystem access, network access. Then ask whether that matches what it says it does. A Markdown formatter that wants your GitHub token deserves a closer look.
I boil this down to three questions:
- What can it read?
- What can it write or send?
- Where does my data go?
If the README can't answer those on one screen, I usually skip it.
4. Who made it?
A known company or a maintainer with a history of active projects is a better bet than a brand-new account with one repo. It's not proof of anything, just a signal.
5. Is there a license?
No license means you technically can't reuse the code. It also tells you how much thought went into publishing it.
6. Is the manifest sane?
Check plugin.json for absolute paths, hardcoded secrets, or fields pointing somewhere unexpected. Those are red flags. We built a free plugin.json validator that catches the common problems in the browser.
What about official plugins?
Plugins in the built-in directory are curated by OpenAI, which is a real signal. It's still worth knowing what you're connecting, especially anything that touches email, files, or deploys.
The short version
Alive, what it runs, what it asks for, who made it, license, manifest. Two minutes, and you'll skip most of the sketchy stuff. The full checklist lives at pickaplugin.com/guides/vet-a-plugin.
What's on your own checklist? I'd like to hear what I'm missing.
Top comments (2)
Do you count version pinning as part of "what it runs"? An npx or uvx launcher on @latest can change after you vetted it, while a pinned @x.y.z only changes when the plugin itself is bumped.
One item I'd add for anything that drives the screen or a browser: check whether it ships a rule to ask before buy, delete or send, because the manifest alone won't show that. (From the Auten team, we make a computer-use MCP, so this one is on our own list too.)
Two minutes is a sensible first pass for a plugin. The check I add is the tool definitions themselves: a server that declares shell or file write access is a different risk than one that only reads. Pinning the version and diffing the manifest after each update catches the rug pull that a quick review window misses.