An MCP server is code you run with real permissions, chosen because 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, made urgent by the fact 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. The sourcing rule that saves grief: prefer a vendor's official server for that vendor's product, reference implementations for the basics, and 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, and 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 converts 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 from the ecosystem and our own keyword research: developer tooling (repos, issues, CI), data stores and warehouses, SaaS APIs (CRMs, docs, messaging), browser/automation capabilities, and 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.