MCP servers have been around for a while now, and if you’ve ever tested some of them, you probably know how easy it is to just grab one of from GitHub, and paste the config into an editor like Cursor or Claude Code. It only takes a minute or two, and you’re ready to start using it.
As long as you’re just testing something out locally, this can be an okay thing to do. But the moment you want to use the same server in production, or give it to your whole team, it’s definitely something else. This is the moment you need to start thinking about security and similar. An MCP server is code that runs with your credentials, and the AI can and will call it whenever it wants to.
In this article, I will walk you through what I actually check before I trust a third-party MCP server with anything real.
Who made the MCP server, and is it still alive?
One of the first things I always check is the repository on GitHub. Who is the author, when was the last commit, and other basic stuff.
If the last commit was a year ago, and there are more than 20 open issues, you have a strong indication that this MCP server isn’t maintained any longer. That’s usually enough for me to rule it out among otherwise good servers.
I also check to see if there is information saying that it’s an official server from the vendor, or if it’s something that’s just being built by a random person. Both of these options can be fine, but it’s nice to know anyways.
What does the MCP server actually do?
This is an important step, and a typical step that many people skip when vetting a MCP server. I open up the code, look at the tools it exposes, and review the GitHub repository for maintainer activity, release history, and issue response patterns as signs of a healthy project. Is this only reading from data sources and other external systems, or can it write, delete, send emails, etc, as well?
You can typically see a tool like “read my calendar”, which usually is fine. But if the server also has the possibility to delete events from you calendar, it’s a whole different story. At least you need to be aware that this can happen when the AI starts calling the MCP server. If a third-party project is compromised or abandoned, it becomes a supply chain problem and can also break when the upstream API changes, which is a real risk with community-built connectors.
To be a little technical, I usually just search the code for the tool definitions, and then read the docstrings. For Python, it’s the @server.tool() decorators, and for TypeScript it’s the server.tool(...) calls or the ListToolsRequestSchema handler. This is also where you can see whether the service exposes specific tools for multiple tools, or just a narrow set of actions. The docstring is actually what the AI reads to decide when to call the tool, so if the description says “get user” but the functions does a DELETE request, you would want to know. Good MCP tools make those descriptions explicit, and they should clearly map to the specific tools being made available.
I will also check if there are any tools running shell commands, or read arbitrary files. This can be fine for your local system, but not something I would expose to my team.
How does it handle credentials?
We can also take a look at how the MCP server gets your tokens and API keys (Environment variables are fine). Since MCP servers expose tools, resources, and prompts to AI models across multiple tools, data sources, and external systems, you should review the code for functionality where the server is sending your credentials to other services than it’s supposed to talk to, that would be a hard no. To look for this we can use the grep command and search for things like fetch(, requests. or httpx. and look at the hostnames. These should look familiar based on the MCP server you’re vetting.
And if the server supports OAuth, check where the redirect goes and what scopes it’s asking for. You don’t want it to be asking for more than what you need. Sometimes the description says it’s only going to be needing a read only access, but the OAuth is asking for full access. That’s not a good thing.
What dependencies does the MCP server have?
If you start the server by first installing it with npx or uvx directly from the internet every time it starts, you don’t really control what version you’re running. MCP uses a client-server architecture, where the MCP client or AI client sends requests to the server over a defined transport mechanism.
So for production, I would pin the version, or even take it as far as forking the GitHub repository and run my own copy. That matters even more for a third party MCP server acting as a backend service, since MCP servers enhance security by managing tool access through a unified protocol.
You can also take a quick glance through files like package-lock.json or uv.lock. You can run commands like npm audit or pip-audit on them. It usually only take a minute, and can sometimes show some weird surprises.
Run it somewhere safe first
If you’re really thorough, a thing that can be done before anything else is to run the server in a sandbox with a test account. Whether it’s a hosted MCP server or one of many custom builds, the third-party MCP server implementation still needs to comply with the MCP specification before you trust it in production. Spin up a Docker container with no volumes mounted, and only the network access. Let the AI use it for a day or two, and then take a look at the logs. What has it been calling, how often, and are there any “hidden” surprises? Good error handling also matters here, because clear logs and meaningful failures make it much easier to spot risky behavior before rollout.
This is also where a platform like Obot can help. Instead of distributing MCP server configurations across individual machines, Obot’s MCP Gateway lets you centrally deploy the servers you’ve vetted, control who can access them, and see how their tools are actually being used — giving teams a controlled path for moving a server from testing into broader production use. And because our MCP Gateway sits inside Obot’s broader AI control plane, that same visibility extends past any one server: policies you set are applied across every MCP server, skill, and agent connecting to it, not just the one you just tested.
Vetting is the first step. Governance comes next.
So that’s an introduction to vetting MCP servers. Take a little bit of time in order to protect yourself, your team, and your company. It’s most likely a little bit of the same thing you do when you’re installing a new package to your web application project and similar, you just need to be aware of the AI using it in the background.
A quick list I go through is:
Who made the server, and if it’s actively maintained
What tools does it expose, and the permissions do these tools have
How are the credentials handled
Pin the versions and dependencies
Do a test run in a sandbox before production
Answering those questions can help you decide whether you can trust an MCP server today, but production introduces another problem: how do you make sure it stays within those boundaries tomorrow?
MCP servers change. Dependencies get updated. Permissions evolve. New users and AI clients start connecting to them. And it’s not just MCP servers — teams are adopting AI agents and skills at the same pace, each with their own access to tools and data. Reviewing each one individually is only part of the security problem. You also need a way to control how all of it is accessed and used, on an ongoing basis.
That’s where a centralized AI control plane comes in.
Obot actually started out as just an MCP gateway, but it’s grown into a full AI control plane at this point: the same idea, just not limited to MCP servers anymore. You get one place to see what agents, skills, and MCP servers are actually connected across your org, set rules for what they’re allowed to do, and pull logs of every tool call if you ever need to go back and check something. The gateway part mentioned above is still in there, it’s just one piece of it now instead of the whole thing.
Ultimately, vetting is really just the first step. It tells you whether an MCP server is worth letting in the door in the first place. What happens after that, whether it keeps behaving the way you expect once it’s live, is a separate problem, and that’s the part a control plane is there to help with.
