Organizational MCP allowlists and plugin governance answer "what is my company permitted to install." They do not answer the question a developer actually faces at the moment of clicking install: is this specific server worth the access I am about to give it.
That is a five-minute check, not a committee decision, and it is worth having a fixed routine for it rather than deciding from scratch every time — especially now that Agent Plugins bundle MCP servers into one-click installs from a default marketplace.
1. Who published it, and can you verify that
A server maintained by the vendor whose product it wraps carries a different risk than one published by an anonymous account with no history. Check the publisher's other work, not just this one listing — a single-purpose account with one recent upload is a signal worth weighing, not proof of anything.
2. What does it actually reach, in concrete terms
Not "what does the description say it does" — what systems, credentials or files does it need access to in order to run. A server that reads your calendar needs calendar access; one that also asks for email, contacts and file storage is asking for more than the stated purpose requires, and that gap is worth a direct question before installing rather than an assumption afterward.
3. Local or remote, and what that implies
A remote MCP server runs on someone else's infrastructure with a URL you can inspect and potentially restrict. A local server runs as a process on your own machine, inheriting whatever access that machine already has — which is usually far more than the server's stated purpose needs.
Local servers deserve the closer look. If a local server could accomplish its purpose with narrower access than a full process on your machine, that is worth noting even if you decide to install it anyway.
4. Does it log or transmit anything, and where
Check whether the server sends data anywhere beyond completing your request — telemetry, usage analytics, error reporting to a third party. This is usually in the documentation if it exists at all; its absence is itself information.
5. Read-only where the option exists
If a server offers a read-only mode or narrower scopes, use the narrowest one that does what you need. Most people install with default permissions and never revisit them, so the default is the permission set you should assume you are stuck with.
The one test worth running before trusting it with real work
Run it once on throwaway or non-sensitive data before pointing it at anything that matters. Watch what it actually does versus what it claimed to do — a server whose behaviour matches its description is a different proposition from one that reaches further than advertised, and you only find that out by trying it on something you would not mind being wrong about.
This is a personal check, not a substitute for policy
If your organisation has MCP allowlists or plugin governance, this checklist runs inside that boundary, not instead of it. A server that passes every item here can still be something your organisation has a reason to block, and a server on the approved list still deserves this five minutes the first time you personally install it — an org-level approval is not the same as someone having actually looked at what it reaches.