# modelcontextprotocol/servers: reference MCP servers for developers who need working examples

> This repository holds the small set of reference MCP servers maintained by the MCP steering group, plus links to community servers. They are educational examples for building your own server, not production software, and the README says so directly.

**modelcontextprotocol/servers** — Collection of reference MCP server implementations maintained by the steering group, meant as educational examples for developers building their own MCP servers.

- Repository: https://github.com/modelcontextprotocol/servers
- Website: https://modelcontextprotocol.io
- Stars: 90,676 · Forks: 11,705
- Language: TypeScript
- License: not declared
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/modelcontextprotocol-servers

## What modelcontextprotocol/servers actually is, and who it is for

The repository is a collection of reference implementations of the Model Context Protocol, maintained by the MCP steering group. The README is explicit that it is not a catalogue: if you want a list of MCP servers, it points you at the MCP Registry, and says the repository is dedicated to housing just the small number of reference servers maintained by the steering group. That distinction matters more than it sounds. Most people who land on this repository are looking for a server to install. The people it is actually written for are developers building their own MCP server who want to see how prompts, resources and tools are wired to an SDK.

The current reference set is short: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time, each under src/. A second list, labelled Archived, points to servers-archived for AWS KB Retrieval, Brave Search, EverArt, GitHub, GitLab, Google Drive, Google Maps, PostgreSQL, Puppeteer, Redis, Sentry, Slack and SQLite. Several of those entries carry a note explaining the move, for example Brave Search has been replaced by an official server, and Slack is now maintained by Zencoder. So the repository doubles as a record of which integrations graduated to someone else's ownership.

## The architecture: SDK plus transport, not a framework

There is no runtime in this repository that hosts servers. The root package.json is private, declares workspaces as src/*, and its dependencies are the four TypeScript servers themselves, which is how the monorepo ties them together. The build script fans out with npm run build --workspaces. Each server is an independent package implementing MCP against one of the SDKs listed in the README, which cover C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Swift and TypeScript.

That means the mechanism you are meant to learn from is per-server, not repository-wide. Filesystem demonstrates access control over file operations. Memory is described as a knowledge graph-based persistent memory system. Sequential Thinking is described as dynamic and reflective problem-solving through thought sequences. Fetch handles web content fetching and conversion. The README frames the whole set as demonstrating how MCP can give LLMs secure, controlled access to tools and data sources, and each server is a different answer to that. If you are looking for a shared abstraction layer that standardises them, the repository does not provide one.

The root also carries .mcp.json, which is the repository's own MCP client configuration, and overrides pinning qs to >=6.15.2 and hono to >=4.12.21. Those overrides are dependency floors for the workspace, not security guarantees for anything you build.

## Installing and running a reference server for the first time

The README gives two paths. TypeScript servers run directly with npx, and it uses Memory as the example. Running this starts the server on its own:

```bash
npx -y @modelcontextprotocol/server-memory
```

On its own that is not very useful, as the README says. Python servers use uvx or pip, with uvx recommended. The Git server is the documented example:

```bash
# With uvx
uvx mcp-server-git

# With pip
pip install mcp-server-git
python -m mcp_server_git
```

The real use is configuring the server into an MCP client. The README shows the Claude Desktop shape, with the memory server as the entry:

```json
{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}
```

On Windows the README says to wrap npx with cmd /c, giving command "cmd" and args ["/c", "npx", "-y", "@modelcontextprotocol/server-memory"]. A second example shows several servers side by side, including filesystem, which takes an allowed path as an argument, and git, which uses uvx with a --repository argument. The git entry in that example points at a repository path, so the server is scoped to one repository rather than your whole disk. What you should see after this is the server listed as available tools in your client, not a terminal that stays open.

## Where the reference-server approach breaks down

The README carries a warning block that is worth reading twice: the servers are intended as reference implementations to demonstrate MCP features and SDK usage, meant as educational examples for developers building their own MCP servers, not as production-ready solutions, and developers should evaluate their own security requirements and implement safeguards for their own threat model. That is the steering group telling you the filesystem and git servers are demonstrations of access control, not a hardened boundary you should trust with a sensitive directory.

The archived list is the second limitation, and it is structural rather than a bug. GitHub, GitLab, PostgreSQL, SQLite, Slack and others all started here and moved out. If you build a dependency on a server in this repository today, the same thing can happen to it. The README does not document a deprecation window, a migration guide or a rollback path for a server that moves to servers-archived; it just lists what has already moved.

A third limit is scope. There is no server here for a database, a chat platform or a cloud API in the current reference set. Those exist in the archive or under other maintainers. If your integration need is one of those, this repository is the wrong place to look, and the README says so by sending you to the registry.

## How this differs from building on an SDK alone

The obvious alternative is to skip the repository and work directly from an SDK, for instance the TypeScript MCP SDK or the Python MCP SDK. The difference is what you get. An SDK gives you the protocol types and the transport plumbing, and leaves the design of tools, resources and prompts entirely to you. The reference servers give you a finished, small implementation of exactly that design, which is useful when you are unsure how a tool should be shaped or how a resource should be exposed over a transport.

The trade-off runs the other way too. An SDK is a dependency you control and version. A reference server is an example you copy, and copying means inheriting its choices, including the ones the README warns are not production-grade. If you want the Filesystem server's behaviour without its packaging decisions, reading src/filesystem and reimplementing against the SDK is the path the repository is implicitly recommending. The Everything server plays a different role again: it is described as a reference and test server with prompts, resources and tools, which makes it the one to point a client at when you are checking that your client handles all three primitives.

## Maintenance, releases and what the licence file implies

The last push to the default branch was on 2026-08-18, and the most recent release, 2026.8.18, carries the same timestamp. Two earlier releases, 2026.7.10 and 2026.7.4, sit in the same summer window, so the release cadence in this repository has been roughly monthly. The repository is not archived. That is the extent of what the README and release list support; there is no published support policy, no LTS branch and no compatibility statement for the servers across releases.

Upgrade cost is mostly a client-configuration question. Because TypeScript servers are invoked through npx with a package name and no pinned version in the documented examples, the code you run is whatever the registry serves at that moment. Pinning a version in your client config is possible in principle, but the README does not show it, and no versioning policy is documented for the server packages. Treat the release tags as the only signal you have.

On licensing, package.json declares "license": "SEE LICENSE IN LICENSE", and the repository has a LICENSE file at its root. The README does not state the licence terms. The author field names Model Context Protocol a Series of LF Projects, LLC. If you plan to redistribute a server or bundle it into a product, read that LICENSE file before you do, and get your own advice on what it permits.

## Conclusion

Adopt this repository if you are writing an MCP server and want a working example to read, or if you want the Filesystem, Git, Fetch, Memory, Time, Sequential Thinking or Everything servers running locally through npx or uvx. Do not adopt it as a production dependency: the README states the servers are reference implementations and not production-ready, and the archived list shows how quickly servers move out. Before you configure anything, read the LICENSE file, since package.json declares "SEE LICENSE IN LICENSE" and the licence is not stated in the README, and check whether the server you want still lives here or in servers-archived.

## FAQ

### What is modelcontextprotocol/servers?

It is a collection of reference implementations of the Model Context Protocol maintained by the MCP steering group, alongside references to community-built servers. The README states the repository is dedicated to housing just the small number of reference servers, and that a full list lives in the MCP Registry.

### How do I install modelcontextprotocol/servers?

You do not install the repository as a whole; you run individual servers. TypeScript servers run with npx, as in npx -y @modelcontextprotocol/server-memory, and Python servers run with uvx or pip, as in uvx mcp-server-git. The README recommends uvx for ease of setup.

### How do I connect an MCP client to a server from modelcontextprotocol/servers?

You add the server to the client's configuration. The README shows a Claude Desktop config with an mcpServers object, where each entry has a command and args, and optional env for tokens. On Windows it says to wrap npx with cmd /c.

### What are the types of servers in modelcontextprotocol/servers?

The README groups them as reference servers, currently Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time, and an archived set moved to servers-archived. The reference servers demonstrate MCP features and the official SDKs.

## Sources

- [Official documentation](https://modelcontextprotocol.io)
- [Official README](https://github.com/modelcontextprotocol/servers#readme)
- [Project repository](https://github.com/modelcontextprotocol/servers)
- [Release notes](https://github.com/modelcontextprotocol/servers/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/modelcontextprotocol-servers