Every MCP entry on this site carries a maintainer label. Some are marked official, most are not. The distinction is narrow and easy to misread, so this page states exactly what it means.
The definition
Official means the server is maintained by the vendor that owns the API it talks to. An official Cloudflare MCP is published by Cloudflare. An official Neon MCP is published by Neon.
It says nothing about whether the server is good, complete, or safe. It says who will notice when the API changes.
Why the label is useful
The failure mode that matters most with MCP servers is drift: the vendor's API changes, the server does not, and the tools start returning errors or, worse, plausible empty results.
A vendor-maintained server has an internal reason to keep up. A community server depends on a maintainer noticing, which may take days or never happen. That difference is worth surfacing before installation.
What the label does not mean
- Not a security review. An official server can still ask for a broad token. Scope is a separate question, and we judge it separately.
- Not a feature guarantee. Vendor servers are often narrower than community alternatives, because they cover the endpoints the vendor cares about.
- Not permanent. Projects get archived. We track that with the archived flag rather than by quietly removing the label.
How community servers compare
The two servers we reviewed alongside official ones in this batch make the point: Airtable MCP and Resend MCP are community projects. Both wrap a small, stable API where the maintenance burden is low and the code is short enough to read.
That is the pattern where community servers are fine: small surface, stable API, readable implementation. Community servers get riskier as the API surface grows and the number of maintainers stays at one.
How we decide the label
| Test | Official | Community |
|---|---|---|
| Published by the API vendor | Yes | No |
| Can change the vendor's own docs | Usually | No |
| Maintenance depends on one person | No | Often |
| Reviewed for token scope | Yes | Yes |
The last row matters: we review every server for scope regardless of the label. Official servers do not get the benefit of the doubt on access.
Why we do not rank by label
It would be easy to sort official servers first. It would also be misleading: a community server that reads one API endpoint is often a better fit than an official suite that requires a broad token to do the same thing.
The decision should be made on the four questions that actually matter — what it reads, what it writes, what token it needs, and how big its tool definition is. The label is context, not a verdict.
What happens when a server is archived
We keep the entry and mark it. Removing archived servers hides the fact that a lot of tutorials still point at them, which is itself useful information.
The rule is that an archived entry must say what replaced it, where a replacement exists. That is why the Puppeteer entry points at the Playwright server instead of disappearing.
The case against the label
There is a reasonable argument that the label should not exist at all. It can imply quality, and it can push readers toward a narrow vendor server when a community one would serve them better.
We keep it for two reasons. First, maintenance is a real risk that readers cannot easily assess on their own. Second, the label is falsifiable: we publish the maintainer and the repository, so anyone can check it.
What we do not do is rank by it. Sorting official servers first would turn a maintenance signal into a recommendation, which it is not.
How we handle forks and takeovers
Projects get forked, adopted, and abandoned. When a server changes hands, the label changes with it: a fork maintained by the vendor becomes official, and an official project that stops receiving updates keeps the label but gains the archived flag when the repository is archived.
The entry's verified date moves whenever we make that call, so a reader can see how recently the judgement was checked. That is the whole system: state the claim, show the evidence, date the decision.
Frequently asked questions
Are official MCP servers always better? No. They are better maintained against their own API and often narrower. For a one-endpoint need, a well-maintained community server can be a better fit.
Can a community server become official? In practice yes — projects get adopted. When that happens we update the label and the repository link, and the entry's verified date changes.
Do you accept submissions for community servers? Yes. Submissions go through the same review: repository, install command, token scope, and what the server actually returns.
Last checked: 9 November 2026.
Related: who maintains MCP servers, the MCP install checklist, and our editorial policy.