Research guide · MCP trust
How to verify an MCP server before connecting
MCP makes tool discovery easy, but connecting is a trust decision. Before an AI client can call a server, decide whether the publisher, code or endpoint, permissions, authentication and live behavior are acceptable for the environment you are about to expose.
Published 11 September 2026 · sources checked 11 September 2026
29,754
servers cataloged by MCPLookup in its 9 Sep snapshot
62%
MCPLookup live-pass rate across its observed catalog
16%
D/F share in Canopii's separate 23,754-server Sep scan
These third-party datasets use different coverage and scoring methods and should not be combined into one market statistic. They are useful here only as evidence that discovery scale and trust verification are separate problems.
The trust boundary
MCP itself does not certify the server you choose
The official MCP security policy is explicit: clients trust the servers they connect to, users and administrators are responsible for server selection, and local stdio servers should be evaluated like any other software you install. A registry card, successful handshake or familiar tool name is therefore not a security guarantee.
The latest Streamable HTTP specification also requires servers to validate the Origin header on incoming connections and recommends proper authentication. For protected resources, the MCP authorization specification requires tokens to be intended for the MCP server rather than passed through to unrelated upstream services.
Pre-connect checklist
Eight checks before granting an MCP server access
1
Resolve the canonical server
Match the publisher, package, repository and endpoint to an owned source. Similar names, mirrors and stale directory cards should not be treated as the same identity.
2
Know the execution boundary
For stdio, remember that the client launches local code. For remote HTTP, verify the exact endpoint, TLS, transport and whether the service is intended to be public or protected.
3
Inspect the capability surface
List tools, resources and prompts before enabling broad use. Flag filesystem writes, shell execution, credential access, outbound network calls, publishing, payments and destructive actions.
4
Check authentication and audience
Protected remote servers should use current MCP/OAuth patterns. Tokens should be scoped to the intended resource; do not accept token passthrough or unrelated bearer credentials as normal.
5
Review package and dependency risk
For local packages, inspect install/postinstall behavior, dependency health, repository provenance, release recency and known advisories before execution.
6
Constrain what the server can reach
Give the minimum filesystem, environment, network, API and account access required. Do not expose broad secrets merely because the server is listed in a popular registry.
7
Probe read-only first
Perform an initialize/tools-list style check in a constrained environment before enabling state-changing calls. Reachability is evidence of operation, not evidence of trust.
8
Record a baseline and re-check changes
Persist the accepted publisher, version, endpoint, tool set and permissions. Re-verify when any of those change instead of silently inheriting trust from an earlier release.
Local stdio
Treat it like installed software
The MCP client executes the configured command. Review the package, install scripts, publisher and requested environment access before launch. Sandboxing or a low-privilege execution account can reduce the blast radius, but it does not make an unknown package trustworthy by itself.
Remote HTTP
Treat it like a privileged API integration
Resolve the owned endpoint, verify transport behavior and authentication, constrain tokens and review every tool's side effects. A public endpoint with no auth may be intentional for read-only data; an exposed state-changing server deserves a very different decision.
Current ecosystem evidence · Sep 2026
Reachability, provenance and security posture are being measured separately
MCPLookup's September 9 snapshot says it cataloged 29,754 servers, with 81% reachable and 62% passing its live check. Its product deliberately separates adoption from its Trust evidence and says an unrated server should not be read as safe.
Canopii's separate September MCP Security Index says 3,801 of 23,754 scanned servers scored D or F and 42% declared no authentication. Those figures depend on Canopii's own coverage and rubric; absence of declared auth can be normal for a local-only server, so it should not be treated as proof of compromise.
More important than either headline number is the operational lesson: a server can be popular, reachable and correctly registered while still requiring an independent trust decision before you expose credentials, files, repositories, payment authority or production systems.
Minimal acceptance policy
Trust should be revocable, scoped and versioned
allow only if:
publisher == expected_publisher
package_or_endpoint == canonical_source
version in approved_versions
requested_permissions <= approved_scope
tool_surface matches reviewed_baseline
no unresolved critical_advisory
auth_and_transport match environment_policy
secrets_exposed <= minimum_required
otherwise: do not connectAfter connecting, keep the same discipline. Re-check when the package version, endpoint, publisher, tool schema, permissions or authentication flow changes. A clean install-time review is a snapshot, not permanent trust.
Continue the research
Separate discovery, trust and payment decisions
Publishing a server helps agents find it. Verification helps decide whether to connect. If the server also charges per call, payment verification is a separate gate again.