MCP Server List: Vendor and Reference Servers

This is a checked list of MCP servers worth knowing, grouped by what they do, with the licence, maintainer and status we found on GitHub or in the vendor's docs on 31 October 2026. For the official catalogue use the MCP Registry at registry.modelcontextprotocol.io. The reference repo points there too. We list the servers developers ask about most, and note which ones have moved or been archived.

How to read this list

• Maintainer means the organisation behind the repo or hosted service, taken from GitHub or the vendor's docs.
• Licence is the SPDX identifier GitHub reports. "None found" means GitHub did not detect one, which is not the same as "free to use".
• Last push is the date of the latest push to the default branch we saw, not a release date.
• Archived means the maintainer has marked the repo read-only. It may have moved. We say where when we know.
• Hosted means the vendor runs it and you connect with a URL and sign in. There may be no server code to read.
• Our page links to the detail page, where we cover install lines for Claude Code, Cursor, Codex, Gemini CLI and VS Code.

A recent push is a sign of life, not a sign of quality. Stars are omitted on purpose. They measure attention, and attention is cheap.

Code and repositories

Early reference servers for GitHub and GitLab are archived. Use GitHub's current server.

Docs, search and web

Browsers

Data and databases

Cloud, containers and infrastructure

Observability and errors

Work, payments and apps

Memory, reasoning and utilities

The reference repo's licence shows as undetected on GitHub's API, so check the folder of the server you use. The README describes these as reference implementations that teach MCP features, not production-ready solutions.

Moved, renamed or archived

These are the changes most likely to trip you up if you follow an older tutorial.

How we would use this list

1. Pick the job first: browse, code, docs, data, deploy, observe, talk to the team.
2. Take the vendor's own server where one exists.
3. Check the three columns that fail quietly: licence, last push and archive status.
4. Open the detail page and read the auth and risk sections.
5. Install one server. Look at your context usage. Then decide on the next.
6. Re-check the repo before you roll it out to a team. Things move.

For ranked picks see best MCP servers. For the setup commands in each agent see the MCP servers hub. For community-maintained mega lists see Awesome MCP servers and free MCP servers.

Which source for which question

The directories answer different questions, so match the question to the source before you search.

The vendor's docs are the only source that cannot be a copycat, which is why we put them first for any named product. A directory is for discovery, and the repository is for the decision.

A written source policy

Teams that install servers casually end up with a mix nobody can audit. A short policy fixes that, and it fits on one page. This template is our suggestion.

1. Approved sources. Name the one or two places servers may come from, for example the vendor's documentation and the official registry.
2. Review. Every new server gets a pull request that links its repository, licence, owner, tool list and the token it needs.
3. Scopes. State the maximum access a token may have. For example, read-only everywhere, and no write access to production.
4. Versions. Pin a version or commit. No @latest in committed files.
5. Owners. Each server has a named person who watches for updates and removes it when it is no longer needed.
6. Review date. Check the list every quarter and remove what nobody uses.
7. Incidents. If a server is found to be malicious or compromised, revoke its tokens first, then remove it, then tell the team.

The policy does not need a committee. A single owner who reads the pull requests can run it, and it replaces the loose habit of pasting a command from a directory page.

Auditing what you already have

Most people have a few servers they installed months ago and forgot. A short audit once a quarter catches the ones that have gone stale. For Claude Code, list what is configured with claude mcp list, and for other agents look at their config files. For each server ask five things.

• Is it still used? If the tool log shows no calls, remove it.
• Is it still maintained? Check the repository for recent commits and whether it was archived.
• Has its owner or name changed? Renames and transfers are a known risk, and the archived table above shows several real ones.
• What does its token allow today? Tokens are often created with more access than the task needs.
• Is it pinned? A server launched with a floating version can change without your knowing.

A script helps when you have many repositories to check. This one uses the GitHub CLI to print the last push date, archive status and licence for each repository in a file.

#!/usr/bin/env bash
# usage: ./check-servers.sh repos.txt   (one owner/repo per line)
while read -r repo; do
  [ -z "$repo" ] && continue
  gh repo view "$repo" --json nameWithOwner,pushedAt,isArchived,licenseInfo \
    --jq '[.nameWithOwner, .pushedAt, (.isArchived|tostring), (.licenseInfo.spdxId // "none")] | @tsv' \
    || echo "$repo	not found"
done < "$1"

Rows with a push date older than a year, an archived flag or a licence of none need a look. The script does not judge security, and a recent push proves only that someone is working on the code. It turns a half-hour of tab opening into a table.

What the list leaves to you

The list tells you what exists and which entries have moved. It cannot tell you whether a server suits your data, your threat model or your agent. Three questions remain yours: what the server can reach, what the agent can do with that reach, and who is accountable when it goes wrong. For the first, read the tool list. For the second, set permissions in your agent and use read-only modes where they exist. For the third, name an owner. The best MCP servers page gives a shortlist, how to build an MCP server covers the case where nothing fits, and Awesome MCP servers covers the long tail.

What this list does not cover

It is not exhaustive. The MCP ecosystem has thousands of servers. We list the ones people ask about, check each, and leave out the rest on purpose. Servers from small teams or single authors can be excellent, and we do not mean to dismiss them. We simply cannot check thousands. The MCP Registry and the community lists are the places to look for the long tail.

Our take

We compiled this from GitHub's API and vendor documentation. We did not install every server.

The useful thing this list shows is churn. In one afternoon of checking, we found archived repos for Azure, Railway and Browserbase, a renamed Sentry repo, a WordPress server retired in favour of an adapter, and a stack of early reference servers that tutorials still recommend. The server you read about last spring may not be the one to install now.

That is the reason we record the check date and show the last-push column. It takes ten seconds to look, and it saves an afternoon of debugging a server nobody maintains.

Frequently asked questions

Where is the official list of MCP servers? The MCP Registry at registry.modelcontextprotocol.io.

How was this list checked? GitHub for licence, push and archive status; vendor docs for hosted servers; all on 31 October 2026.

Which listed servers are archived? Several early reference servers, and Azure, Railway and Browserbase's repos at the time we looked.

Does a recent push mean a server is safe? No, only that it is active.

How often does it change? Often. Check the date on each row.

*Product names are used descriptively. We are not affiliated with any maintainer named here.*