Awesome MCP Servers: How to Use the List

Awesome MCP Servers is the largest community list of Model Context Protocol servers: a long GitHub README, grouped into dozens of categories, where each entry is a repository link, a few tags and a one-line description. It is a good place to discover what exists. It is not a security review, so check each server before you install it. We read the README on 31 October 2026.

Quick facts

The counts are ours, taken by counting list lines and section headings in the README on the date above. They will have changed by the time you read this.

What the README contains

The page opens with a contents list: What is MCP, Clients, Remote Servers, Tutorials, Community, Legend, Server Implementations, Frameworks, and Tips and Tricks. It also carries an advertisement near the top, marked "Ad" in the README, so do not read the order of anything on the page as an endorsement.

Clients and remote servers

The list does not try to cover clients. It points to awesome-mcp-clients and to Glama's clients page. For hosted servers you connect to by URL, it points to awesome-remote-mcp-servers. The main list is for servers with a GitHub repo that you install and run yourself.

If you want the clients that can use these servers, see our MCP clients page.

The legend

Each entry can carry emoji that mean something. From the README:

The README explains scope with an example. Use local when the server talks to locally installed software, such as taking control of Chrome. Use cloud when it talks to remote APIs, such as a weather API.

These tags are useful filters. If you only run Linux and want Python, you can scan for those marks. They are also self-reported by whoever submitted the entry.

Categories

Server Implementations is the bulk of the file. Section names include Aggregators, Aerospace, Agreements and Coordination, Accessibility, Art and Culture, Architecture and Design, Biology and Medicine, Browser Automation, Cloud Platforms, Code Execution, Coding Agents, Command Line, Communication, Conversational AI, Cryptography, Customer Data Platforms, Databases, Data Platforms, Developer Tools, Delivery, Data Science, Data Visualization, Embedded Systems, Education, E-Commerce, Environment, File Systems, Finance and Fintech, Gaming, Health, Home Automation, Identity, Industrial and IoT, Knowledge and Memory, Legal, Location Services, Marketing, Monitoring, Multimedia, OS Automation, Podcasts, Product Management, Real Estate, Research, RAG platforms, Search and Data Extraction, Jobs, Security, Social Media, Spirituality, Sports, Support, Translation, Speech-to-Text, Text-to-Speech, Travel, Version Control, Workplace and Productivity, and Other Tools.

Entries inside a section are mostly in alphabetical order, with no ranking. A few sections are far bigger than others. In our count, Developer Tools, Finance and Fintech, Knowledge and Memory, Search and Data Extraction, and Security each run to hundreds of lines.

After Server Implementations the README has a Frameworks section (for building servers, including FastMCP for TypeScript) and Tips and Tricks, which points to an official prompt file for teaching an LLM about MCP.

Reading one entry

A typical line in the README looks like this: a name that links to the repo, sometimes a score badge from the companion directory, a run of legend marks, a dash and one sentence. For example, a browser server might carry marks for TypeScript, local scope and all three operating systems, with a sentence that says what it controls.

Read the marks as claims, not facts:

• A TypeScript mark tells you how to run it (usually npx), and which runtime you need.
• A local mark means it starts a process on your machine and may touch your files or apps.
• A cloud mark means it talks to a remote API, so you will need an account and a key.
• The three operating system marks are the submitter's statement about support, not a test result.
• An official mark means the submitter says the vendor published it. Confirm by checking the organisation that owns the repo.

The description is a single sentence, so it will never tell you the tool list, the permissions or the risks. That is what the repo's README is for. Open it, read the tools, and then decide.

Using the list with the registry and the web directory

The three sources overlap and complement each other.

A sensible path: find a candidate on the list, look it up in the registry, then read the vendor docs or the repo. If all three agree on who maintains it, you can be more confident it is what it claims to be.

The context cost of a server

Every MCP server you connect adds its tool names, descriptions and schemas to the model's context, and some clients send that on every request. A list with thousands of servers makes it tempting to connect many, and that has a price you can estimate. These figures use example token counts, so measure your own with your client's usage view.

The dollar figures use Sonnet 5.5's $2 per million input tokens. Caching and tool search reduce them in some clients, and a subscription plan hides them as usage limits. The larger cost is accuracy: with 120 tools in view the model picks the wrong one more often, and each wrong call is a wasted step. A sensible limit for a daily setup is a handful of servers, each with a job you can name. Turn off or filter tools you never call, and add a server per project instead of globally.

Pinning, so a discovery stays what you found

A list entry gives a repository. The command that runs it is what matters. Many READMEs show a launch line that fetches the newest published package every time. That is convenient and means your setup can change under you. Pin a version once you decide to keep a server:

{
  "mcpServers": {
    "example": {
      "command": "npx",
      "args": ["-y", "example-mcp-server@1.4.2"]
    }
  }
}

The package name and version above are placeholders. Replace them with the exact release you reviewed, and update on purpose, after reading the changelog and the diff. For a server you install from source, pin a commit hash. Record the date and the reason in your notes, so the next person knows why it is on that version.

From a personal shortlist to a team allow list

A discovery habit works for one person. A team needs a shared decision.

1. Keep a short approved list in the repository, with each server's purpose, owner, version and the scopes or tokens it needs.
2. Review additions like dependencies. A new server goes through a pull request, with the vetting steps above as the checklist.
3. Separate read from write. Approve read-only servers freely and require a named reason for any that can change systems.
4. Use per-project configuration where the client allows it, so a server for one repository is not available in every session.
5. Rotate tokens and give each server its own, so revoking one does not break the rest.
6. Review quarterly. Remove servers nobody uses, and check that those you keep are still maintained.

The list helps you find candidates, and the registry and vendor docs help you confirm them. The approved list is what turns a discovery into a decision.

What the list is good for

• Discovery. You know the job, not the server. Scan the category.
• Seeing what exists before you build your own. Someone has probably tried it.
• Finding the official one. The medal mark helps find a vendor's own server among community clones.
• Learning by example. A server in your language is a free reference.

What the list is not

• Not a quality filter. Entries come from submissions. The README does not describe an audit.
• Not a security review. MCP servers run code or reach real systems.
• Not always current. Servers get archived, renamed and replaced. A link can point to a dead repo.
• Not ranked. Alphabetical within a section.
• Not neutral about everything. The page has an ad slot, and many entries carry Glama score badges from the companion directory.
• Not a package manager. You still install each server by its own README.

With roughly 4,600 entries and a heavy tail of small projects, the odds that any given entry is abandoned are not low. Treat every unfamiliar name as unproven.

How to vet an MCP server before you install it

Do this in five minutes, in order.

1. Open the repo. When was the last commit? Is it archived? Who are the maintainers? Is it under a vendor's org?
2. Check the licence. No licence file means you have no clear right to use it.
3. Read the tool list. Every tool is something the agent can do. Would you give each one to a new hire? If not, find a read-only mode or an allow list.
4. Read how it authenticates. OAuth with scopes is better than a long-lived all-powerful token. See which scopes it asks for.
5. Look at what it runs. A server launched with npx -y package@latest runs the newest published package every time. Pin a version.
6. Search the issues for "security", "token", "injection" and "credentials".
7. Check where data goes. Does it call any service other than the one it names? Does it log your prompts or content?
8. Run it in a scratch project with a throwaway token before you connect real systems.

Claude Code's MCP docs give the short version: verify you trust each server before connecting it, and note that servers that fetch external content can expose you to prompt injection. If the agent will read untrusted text (web pages, issues, messages) through a server that can also write, that combination is where the risk sits.

A faster path for common needs

If you want a known job done and a known vendor, you do not need the big list.

For a registry that lists published servers with a defined API, use the official MCP Registry at registry.modelcontextprotocol.io. Its repo describes it as a registry that provides MCP clients with a list of servers, like an app store, and the MCP project's reference repo tells people looking for a list to browse the registry.

Contribute or get listed

The README is a community list that accepts submissions through the repository. If you maintain a server, read the repo's contribution rules, since an open tracker of this size means entries are processed as maintainers have time. Do not expect listing to bring users. Build something useful, publish it with a clear README, licence and tool list, and the list is a place to be found.

If you add your server to the official registry as well, you reach clients that read from it.

Limits and cautions

• Size. Searching the README on GitHub in a browser can be slow. Use the page's find box or the companion web directory.
• Duplicates. Many categories hold several servers for the same service. Prefer the official one.
• Stale links. Check the repo before you rely on an entry.
• Badge noise. Score badges are another party's score, not ours and not the list's verdict.
• Self-reported tags. Language and platform marks come from submitters.
• Prompt injection risk grows with every content-fetching server you add.
• Ads. The README labels its sponsor placement as an ad.

Our take

We read the README and counted its contents. We did not test the servers in it, and we do not rank them.

The list does one job well: it shows how wide the ecosystem is. Nearly 4,600 entries, from databases to sports data, from vendor servers to hobby projects. That is a real signal that MCP has become the default plug for AI tools.

The same width is the problem. A list this big cannot tell you which entries are safe, current or worth the context they cost. For that you need your own checks, and the eight steps above take five minutes.

Our habit: use the list to find candidates, then check the vendor's own docs before installing anything. For the 10 or so servers most developers need, skip the list and go straight to a short, checked page. For the long tail, the list is the place, and a throwaway token is the safeguard.

Frequently asked questions

What is Awesome MCP Servers? The largest community GitHub list of MCP servers, maintained by punkpeye.

How big is it? About 4,600 list items in 59 category sections when we counted.

Are the servers vetted? No. It is a link list, not an audit.

What do the emoji mean? A legend for official status, language, scope and operating system.

Where are hosted servers listed? In awesome-remote-mcp-servers.

*Product names are used descriptively. We are not affiliated with the list's maintainer or the Model Context Protocol project.*