An MCP server is code you run with real permissions, chosen knowing a model will be steered by whatever it returns. Popularity metrics do not audit code; a directory listing is not a review. The tiering above is not snobbery — it is the same supply-chain logic your dependency policy already applies. What makes it urgent is that a compromised or merely sloppy server sits in the path between an easily-influenced model and your data. The evaluation guide turns this into a checklist.
Landscape questions
Where do I find MCP servers?
The official repositories and documentation index reference servers. Beyond those, registries and directories aggregate community servers of every quality level, and vendors increasingly ship official servers for their own products. One sourcing rule saves a lot of grief: prefer a vendor's official server for that vendor's product, and reference implementations for the basics. Treat everything else as unaudited third-party code, because that is what it is.
Should I write my own server?
For your own internal systems, usually yes. It is less work than the word "server" implies: official SDKs in the major languages reduce a basic tools server to an afternoon. Writing your own turns the trust question into code review you control. And internal capabilities were never going to have a trustworthy third-party server anyway. The build-vs-adopt line lands where it always does: adopt commodity, build proprietary.
What do people connect via MCP in practice?
The recurring categories come from the ecosystem and our own keyword research. They are developer tooling (repos, issues, CI), data stores and warehouses, and SaaS APIs (CRMs, docs, messaging). Browser and automation capabilities also recur, as do workflow platforms — the n8n-style integration cluster shows up constantly. Agent-to-agent protocols (the a2a cluster) are adjacent but distinct: different problem, different spec.