Open Source · Model Context Protocol · Updated daily via GitHub Actions
A curated index of Model Context Protocol servers, SDKs, server frameworks, gateways and directories, with live GitHub stats. Vendor-maintained servers are tagged so you can tell them from community ones. Building your own agent? See the frameworks index.
The Model Context Protocol (MCP) is an open protocol for connecting AI applications to the tools and data they act on. An MCP server exposes capabilities — tools the model can call, resources it can read, prompt templates — and an MCP client inside the host application discovers and uses them. One server written once works with any client that speaks the protocol.
That is what makes an index like this useful: a server for a database, a browser, a code host or a design tool is a reusable part rather than a per-application integration. The catch is that a server also widens what an agent can do, so what a server can reach matters as much as what it does.
Every project above is tagged by what it is and who maintains it. Use the Topic filter to isolate any of these — or read on for what each one means.
Maintained by the Model Context Protocol project itself: the specification, reference servers, the inspector and the registry.
Built and maintained by the company that owns the product — for example a code host, a cloud provider or a database vendor.
Language libraries for writing MCP servers and clients: the protocol plumbing so you only write the tools.
Higher-level toolkits on top of an SDK, with routing, auth, testing and deployment helpers for building servers quickly.
Sits in front of many servers to add authentication, routing, policy, logging and a single endpoint for clients.
A catalog that lets clients discover servers, with metadata about what each one is and where it runs.
Curated “awesome” lists of servers. Useful for discovery, but entries vary widely in quality and maintenance.
Servers that let an agent drive or inspect a real browser — navigation, screenshots, DOM, network and performance.
Servers that let an agent query and sometimes modify a database, ideally through a narrow, read-only interface.
Servers that connect agents to reverse-engineering and security tooling. Use only on systems you are authorized to test.
Three different roles in the same ecosystem.
A program that exposes tools, resources or prompts over MCP — the thing an agent actually connects to, such as a GitHub, database or browser server.
A library for writing servers or clients so you do not implement the protocol by hand. Official SDKs exist for several languages.
A proxy in front of many servers that centralizes access, policy and observability. It manages who can call what, once you have many servers.
Six checks worth making before you connect a server to an agent that can act on your behalf.
A server from the vendor that owns the product tracks its API and is accountable for it. A community server may be excellent or abandoned — check the Updated column and the maintainers.
Local servers run on your machine over stdio; remote servers are reached over HTTP and need real authentication. Know which you are installing and where your credentials go.
Prefer a server with a small, well-named set of tools and a read-only mode. Fewer, narrower tools are easier to trust and to reason about.
Tool output is untrusted input to the model, so a server that reads web pages, tickets or email can carry instructions an agent might follow. Read the source, pin versions, and keep write access to what the task needs.
Every enabled tool’s description takes up context on every turn. Enable only the servers a task needs, not everything you have installed.
Check the license, and use stars, forks and last push as a sanity check — not as proof of quality.
A program that exposes tools, resources or prompts to AI applications over the Model Context Protocol, so any MCP-capable client can use them without a custom integration.
An API is designed for programmers to call. An MCP server wraps capabilities in a uniform, self-describing form a model can discover and choose to call at runtime — often on top of an existing API.
Treat them like any software that runs with your credentials. Prefer official or well-maintained servers, read what tools they expose, pin a version, use least-privilege tokens, and remember that content a server returns can attempt to steer the model.
Local servers keep data on your machine and are simple to start, but you run and update them. Remote servers are managed by someone else and usually use OAuth-style authentication. Choose by where the data lives and who you trust to operate it.
A proxy that sits between clients and many servers to provide one endpoint plus centralized authentication, routing, policy and logging. It becomes valuable once a team runs more than a handful of servers.
MCP standardizes how an agent connects to tools; it does not decide which calls should be allowed. That decision — permissions, budgets, approvals and verification — is the harness’s job.
Stars, forks and topics are refreshed daily via GitHub Actions — the freshness indicator in the nav bar shows the age of the current data pull. The list itself is reviewed by hand periodically, and archived or stale projects are removed.