Official or community MCP server: how to tell

Who published it, checked from both ends

An official MCP server is one published by the company whose product it connects to. To tell, check two things that point at each other: the repository should sit under that company's own account on the code host, and the company's own documentation should link to it. A name that includes the product, or a logo in the README, proves nothing on its own. Anyone can name a repository after a product.

The check takes a minute. Open the account that owns the repository and see what else it publishes: a vendor's account usually holds its SDKs and other public code, while a personal account holds one person's projects. Then go to the vendor's documentation, find its page on MCP or on assistant integrations, and follow the link from there rather than from a search result or a list.

Everything else is community: written by someone who uses the product and wanted a server for it. That covers a lot of careful, well-maintained work and a lot of weekend experiments, and the label alone does not say which.

How the directory marks it

In the MCP server directory a server is marked official only when the site's own records link it to a vendor's product as that vendor's own server. The mark is a relationship held in data, not a word matched in a name or a badge copied from a README. Servers without that link are shown without the mark, which means no such link is on record, not that the server has been judged unofficial.

The skills directory uses the same kind of link for skills, and its page has a filter to show only official ones. A vendor's own skill is useful mainly because it was written by the people who know how their product behaves.

What official tells you and what it does not

It tells you who to hold responsible, where to report a problem, and that the server's authors know the API it wraps. It often means the server follows the vendor's own permission model, so the token it asks for may be scoped in ways a third party could not offer.

It does not tell you the code is careful, or that the default setup is narrow. A vendor's server may expose every endpoint of its API as a tool because that is the vendor's idea of complete. It does not tell you the server is maintained either: a company can publish one and move on. Check the last push the same way you would for anyone. A vendor's server that has not changed since the vendor's own API did is as stale as anyone else's.

And it says nothing about the credential you give it. An official server with an account-wide write token has account-wide write access.

When a community server is the better pick

Sometimes no official server exists. Sometimes the official one does far more than you need, and a small community server with three read-only tools is easier to reason about. A short piece of code you can read in full may be a safer install than a large one you cannot.

For a community server, look harder at the parts that would have been someone else's job at a vendor: whether the install command pins a version, whether the tools do what their names say, whether anything sends data to an address you did not configure. The post on evaluating a server before you install it walks through those checks.

Lookalikes and copies

Watch for repositories that copy an official server's name and README under a different account. The tell is the account, so read it every time, and compare against the link in the vendor's documentation.

The directory also counts unchanged copies of one starter template on their own tile, separate from distinct servers. Those copies are real repositories, and listing them openly is how the directory's size stays honest. A copy with a product name attached is not that product's server unless the vendor says it is.

Remote servers and who operates them

Some vendors run their official server themselves, and the client connects to it over the network rather than running code locally. That changes the question. You are no longer trusting code on your machine, you are trusting the operator of a service with whatever you send it and whatever access you grant when you sign in.

For a vendor's own remote server, that is often the same trust you already extend to the vendor's product, since the data lives there anyway. For a remote server run by a third party in front of someone else's product, it is a new party in the middle, with your key or session in its hands.

So for remote servers the official question matters more, not less. Check that the address you connect to is one the vendor documents, and read what the sign-in screen asks to grant before you accept it. A community server you run locally keeps the key on your machine, which is sometimes the reason to prefer it.

None of this is a reason to avoid remote servers. Hosted servers spare you from running and updating code, and a vendor's own one may be the only way to reach some features. The point is to know which party holds your access, and to give that party no more of it than the task needs.