Manual review
Verify an MCP server
before you connect
A manual review checklist for an MCP server, covering what an automated scan cannot see. An MCP server can receive sensitive data from your agent and act with your permissions, and you cannot inspect what it does on its own side, so the real question is who runs it. If you already trust the vendor you may be able to stop there; if not, verify four things before you connect: the vendor, the source, the server, and its capabilities. What you cannot verify is itself a signal.
An MCP server can receive sensitive data from your agent and act with your permissions, and most teams add one from a single line in a config file. Our scan reports what an outside observer can check. This page is the rest: the review only a human can do.
You cannot inspect what a server does on its own side, so the real question is who runs it. If you already trust the vendor, a first-party server from an established provider inherits that trust, and depending on the data it fronts you may be able to stop there. If not, verify the four things below before you connect.
The one tool to install first
Most of this means reading a server's tool surface with your own eyes. The official way is MCP Inspector, from the Model Context Protocol project. It runs locally and connects to any server.
npx @modelcontextprotocol/inspector --cli https://your-server.example/mcp \
--transport http --method tools/listAdd --header "Authorization: Bearer <token>" or --header "X-API-Key: <key>" for an authenticated server; --web runs the browser OAuth flow. Run a current version (an older one shipped a serious local-proxy vulnerability), and if a browser OAuth attempt fails with a redirect-URI error, clear ~/.mcp-inspector/storage/oauth.json.
Vendor review
You can't see what a server does on its side, so it comes down to who runs it. Distinguish identity from reputation: knowing a name is not the same as trusting a track record.
- Do you already trust the vendor? A first-party server from an established provider inherits that trust depending on the data it fronts, you may be able to stop here
- Is the publisher's identity independently verifiable, with a security history you are comfortable with?
- If not, do a vendor review before you continue
Source
A malicious or compromised package can get full access to your data, so establish where the code comes from before trusting what it does.
- On an official registry a registry listing verifies namespace ownership, meaning who published it, not that the code is safe
- Open source, licensed, maintained, with real adoption
- A real, named maintainer, and the released version matches the source you reviewed reviewing a repo and installing a package are not the same thing without build provenance
- Dependencies pinned, with no known critical or high vulnerabilities only checkable where the server ships a queryable package
The server
The connection and the tool surface introduce exposure and token cost. Read the surface yourself, and treat everything the server sends your model as untrusted.
- Uses HTTPS, and requires auth for anything sensitive HTTPS alone is not authentication
- Tokens are issued for this server, not passed through to other services the MCP authorization spec requires audience-bound tokens and prohibits passthrough
- Read the tool descriptions and treat as untrusted including input schemas, resources, and prompts, not just tool names; watch for hidden instructions and triggers broader than the tool's stated job
- Tool output is untrusted too indirect prompt injection: a result the tool fetches at runtime can carry instructions your agent follows, and that payload was never in the description you reviewed
- Gauge context cost the full set of tool descriptions loads on every request, so a large surface is a standing tax, especially at organisation scale
npx @modelcontextprotocol/inspector --cli URL --transport http --method tools/listCapabilities
What the tools can do with your access is the real risk, and "runs with your permissions" means the credentials it receives set the blast radius. Sort the tool surface by impact:
- What credentials does it receive, and are they least-privilege? this is your actual blast radius; short-lived and scoped where possible, and not reused against other services
- Read-private paired with send or write-external is an exfiltration path reading private data and creating an issue, commit, or webhook exfiltrates just as well as an obvious "send" tool
- Actions that spend money or run on a schedule one call can set up recurring, paid, or background jobs that outlast the session; standing state is invisible to any outside scan
- "Read-only" hints are claims, not guarantees a tool marking itself read-only in its annotations does not make it so
A review is a snapshot. Servers are usually launched unpinned, so an update can silently change the code or tool surface you approved after you connect. Re-inspect periodically and compare. Ongoing trust in the publisher, not a one-time check, is the real control.
The questions no tool can answer
Some things cannot be observed from the protocol at all. Ask the vendor, and decide whether the answers are good enough before you connect:
- Where does the data your agent sends actually go, and which upstream services does it touch?
- Are tool arguments and results logged, for how long, and is anything used for training or analytics?
- Where is data stored, and is there a data processing agreement?
- Is there a security contact, an incident history, any third-party assurance?
- What is the policy for breaking changes to tool definitions after you have adopted them?
None of this replaces the automated scan, and the scan does not replace this. Together they answer the one question this whole site exists for: should you connect this specific server?