How do I vet MCP servers for enterprise use?

An individual developer can reasonably eyeball a tool's raw definition and permissions once. An organization approving MCP servers for broader use needs the same check to produce the same answer regardless of who runs it — a documented rubric covering capability-vs-claim mismatch, provenance attestation, and freshness signals (see the security checklist), applied consistently, with the result recorded somewhere other than one person's memory.

It's tempting to wave through anything published under a recognizable vendor's namespace and scrutinize only the long tail of community servers. Published audits don't support that instinct — vendor-maintained MCP servers have been found failing at comparable rates to community ones, including reference implementations from major AI labs. Namespace verification is a real provenance signal worth crediting (it proves who published something), but it is not a safety signal, and treating it as one is exactly the gap that's let vendor-published servers ship real vulnerabilities without extra scrutiny.

A one-time approval creates a specific, predictable failure mode: the exact version reviewed gets a permanent green light, and every later version inherits that approval by default even though nobody looked at it. The fix is locking approval to what was actually reviewed — a content hash of the tool definitions and, as a secondary signal, the version number — so that either one changing strips the approval automatically rather than requiring someone to remember to re-check it.