Home › Guides

How to Vet an MCP Server Before You Install or Buy It: A Practical Checklist

Connecting an MCP server takes a minute. Undoing the damage of a careless one can take much longer. A Model Context Protocol server is not just another library: it hands an AI agent tools that can read files, call APIs and act on your accounts, and the agent decides on its own when to use them. This guide walks through the checks worth running before you install a community server or pay for a hosted one, whichever marketplace or registry you found it on.

1. Why an MCP server deserves more scrutiny than a normal dependency

With a regular package, your own code decides what gets called and when. With MCP, a language model reads the list of tools the server exposes, reads their descriptions, and chooses which ones to call based on whatever is in its context: your request, a web page, an email, a document. That means two things. First, the server's code runs with whatever credentials you give it. Second, the text the server sends to the model (tool names, descriptions, results) becomes part of the model's instructions.

So the question is not only 'is this code malicious?' but also 'what could go wrong if the agent is tricked into using these tools?'. Security write-ups from OWASP's GenAI Security Project and several vendors group the main risks the same way: over-broad permissions, poisoned tool descriptions, tools that change after approval, and leaked secrets.

2. Check who publishes it and whether you can read the code

Start with provenance. An official server published by the company whose API it wraps is a different risk profile from an anonymous fork with a similar name. Look-alike names are a known trick in every package ecosystem, and MCP registries are no exception.

• Is the publisher identifiable, and does the repository link back from the vendor's own docs?
• Is the source code available, and does the published package actually match that repository?
• Is there recent maintenance: commits, answered issues, a changelog?
• Does it pull in many dependencies you would not expect for what it does?
• For a closed, hosted server: is there a named company, terms of service and a privacy policy?

3. Read every tool description, not just the README

The README is written for you; the tool descriptions are written for the model, and that is where 'tool poisoning' hides. A poisoned description can contain hidden instructions such as asking the model to read a configuration file and pass its contents as a parameter, or to quietly call another tool. Most MCP clients let you list the tools a server exposes; do it and read them in full.

Red flags include descriptions much longer than the tool needs, instructions addressed to 'the assistant', references to other servers' tools, requests to keep something from the user, and parameters that have nothing to do with the stated purpose (a weather tool asking for a 'notes' or 'context' field).

4. Map exactly what it can touch

Write down, in one line per tool, what each tool can read and what it can change. Then compare that list with what you actually need. A server that only needs to read one folder should not get your whole home directory; a server that summarises tickets does not need permission to close them.

• Prefer read-only tools and scoped API tokens over full-access keys.
• Give each server its own credentials so you can revoke one without breaking the others.
• Keep secrets in environment variables or a secrets manager, never pasted in a prompt or a shared config file.
• Turn on per-call confirmation in your client for any tool that writes, sends, deletes or pays.
• Be careful when combining servers: one that reads untrusted content (email, web) plus one that can send data out is the classic exfiltration pair.

5. Pin the version and watch for changes

Approving a server once does not mean it stays the same. If your configuration always pulls the latest version, a later update can change tool behaviour or descriptions after you reviewed them, which security writers often call a 'rug pull'. Pin a specific version or commit, review the diff before upgrading, and if your client can alert you when a server's tool list changes, switch that on. For hosted servers you cannot pin, ask the provider how they announce changes.

6. Test it in a sandbox with fake data first

Before connecting a new server to real accounts, run it against a throwaway workspace: a test folder, a sandbox API key, a dummy mailbox. Run a few realistic tasks, read the logs, and watch which tools get called and with which arguments. If the server makes network calls you did not expect, or the agent starts calling tools you never asked about, you have learned that cheaply. Local servers can also be run in a container with no network access beyond what they need.

7. Extra questions for paid and hosted MCP servers

When you pay for an MCP server or an agent service, you are also trusting the operator with your data and your workflow. Ask before you pay: where requests are processed and logged, how long data is kept, what the rate limits are, what happens when the service is down, and how billing works if a call fails.

Marketplaces can help by putting a process around the purchase. On Kiosq, for example, sellers list AI agents, MCP servers and automations, and on-demand services are paid in USDC on Polygon into escrow: under the Kiosq Guarantee the buyer validates the result, gets one free revision, and can then ask for a refund. That protects the transaction, but it does not replace the technical checks above; run them on anything you connect, wherever you got it.

8. A quick go / no-go checklist

If you can answer yes to all of these, you have done more than most people do before clicking 'connect'.

• I know who publishes it, and the code or company is verifiable.
• I have read every tool description and found nothing addressed to the model that I would not accept.
• Each tool's access is limited to what my task needs, with its own revocable credentials.
• The version is pinned, or I know how changes are announced.
• I tested it with fake data and the logs matched what I expected.
• Write, send, delete and payment actions require my confirmation.