1. Establish who publishes it#
The MCP Registry lets anyone publish. A namespace like com.stripe requires proving control of stripe.com; a namespace like io.github.someone requires only a free GitHub account. Those are very different assertions and the registry does not visually distinguish them.
Check that the server's actual endpoint lives on the domain its namespace claims. A server published under com.example whose endpoint is on an unrelated host is worth a question, not an assumption.
Registry domain verification happens once, at publication. It is not re-checked when a domain changes hands, so treat it as a fact about a date rather than a fact about now.
2. Decide where it runs before anything else#
A hosted remote endpoint means your prompts, and whatever context accompanies them, leave your network. A self-hostable package means they do not. This single decision constrains everything downstream — data residency, egress review, incident response — so make it first.
Of the 33 servers we profile, 6 publish an installable package you could run inside your own perimeter. Hosted-only is the common case, not the exception.
Do not treat 'it has a GitHub repository' as evidence you can self-host. A public repo for a hosted service is source visibility, not a deployment option.
3. Read the authentication, not the marketing#
A well-behaved remote MCP server answers an unauthenticated request with 401 and points at OAuth discovery metadata. You can check this yourself with a single request — no account required.
22 of 33 servers we profile publish OAuth discovery metadata. 5 accepted a connection with no credentials at all when we checked.
If a server only supports a long-lived API key, ask who holds that key, where it is stored, how it is rotated, and what it can do. A personal access token pasted into a client config is a credential with no expiry and usually no audit trail.
4. Establish what it can write to#
This is the question that separates a reporting integration from a change-management problem, and it is answerable from the server's published scopes.
Of the 16 servers publishing a machine-readable scope list, 8 expose a single scope covering both reading and writing. For those, read-only access cannot be granted: approving the connection approves everything it can do.
If separate read and write scopes exist, confirm your client actually requests only the ones you intend. A server offering least privilege does not deliver it by itself.
5. Write down what is undocumented#
Audit logging, data retention, residency and access control are the four criteria vendors document least often. An absent answer is not a failing grade — it is an open question you should put to the vendor in writing before you connect anything.
Be precise about attribution. A vendor's SOC 2 report covers the vendor. It does not tell you that this specific MCP server writes an audit record when a tool is called. Those are different claims and only one of them is usually evidenced.