Every protocol gets one repository that is less a product than a manners guide. For the Model Context Protocol, it is modelcontextprotocol/servers: seven small servers that thousands of client implementations were implicitly trained on. A filesystem server whose security layer has eleven hundred lines of adversarial path tests. A fetch server that checks robots.txt before a model does something embarrassing. A memory server that persists a knowledge graph to JSON with file locking and atomic saves, because two agents sharing one brain is a concurrency problem. The sequential-thinking server, whose single tool changed how models plan. And the everything server, a deliberate demonstration animal that exercises sampling, elicitation, progress notifications, resource templates, and four transports so that implementers never have to guess what “the protocol” includes. The code is TypeScript and Python, mixed freely, and every package carries a protocol test suite thicker than the server itself. Reading this repository is not reading seven tools — it is reading the style guide the MCP ecosystem absorbed.

The architecture is a flat collection with shared conventions rather than shared code. Each directory under src/ is a self-contained server: a manifest, a transport entry point, tool handlers, and a test suite that drives the real protocol rather than mocking it. The TypeScript servers (filesystem, memory, sequentialthinking, everything) sit beside the Python ones (fetch, git, time), which communicates something deliberate — an MCP server is a contract, not a framework choice. The filesystem package is the deepest, splitting tool registration from a typed operations library from a validation layer. The everything package is the widest, one file per protocol capability with transports for stdio, SSE, streamable HTTP, and an in-memory event store for resumability. The repository itself dogfoods the protocol — its .mcp.json configures the project’s own development agents with the servers it ships — and points beyond itself in ADDITIONAL.md, the curated community index. As always in this series, what follows is an educational tour of published source code.

The reference set at a glance: the hardened filesystem server and its validation layer, the Python fetch, git and time servers, the memory and thinking servers that shaped agent behavior, the everything server demonstrating every feature, and the documentation layer that points outward.

Reading the overview from left to right:

• The filesystem server registers every file operation as a tool with typed schemas.
• The path validation layer keeps operations inside allowed roots, symlinks considered.
• The fetch server converts web pages to markdown with robots.txt respect and domain blocking.
• The git server wraps repository operations behind an explicit safety posture.
• The memory server persists a knowledge graph of entities and relations to a JSON file.
• The thinking server gives models a revisable, branchable scratchpad.
• The everything server demonstrates every protocol feature end to end.
• The community index catalogs the ecosystem that grew around these seven.

Why You Need This

The first reason is the security engineering, because the filesystem server is the best publicly readable example of “letting an AI touch your disk, carefully.” The server registers read, write, move, search, and edit tools with Zod schemas, then funnels every path argument through the validation layer, which resolves symlinks and enforces root containment before anything touches disk. The path utilities handle the cross-platform noise — home expansion, normalization, Windows quirks — and the roots module merges the protocol’s root declarations with configured directories, so a client can reshape the writable surface at runtime. What makes this package required reading is the evidence: eleven hundred lines of path-validation tests attack the boundary with traversal tricks and platform-specific cases, another eleven hundred cover the tool handlers, and seven hundred more pin how roots change behavior. This is what “safe by default” looks like when someone actually pays for it.

The second reason is the behavioral servers, because memory and sequential thinking changed what models do more than any single tool since. The memory server implements a knowledge graph — entities with observations, relations with directions, searched by exact and fuzzy match — persisted to a JSON file the agent owns. The interesting code is not the graph but the persistence discipline: file-lock tests prove concurrent writers cannot corrupt the store, and atomic-save tests cover the write-temp-then-rename path that survives a crash mid-save. The thinking server is the opposite of subtle — one tool, one scratchpad — but its library tracks revisions and branches, letting a model mark a thought as revised or pivot to an alternative chain, and the behavior tests pin those semantics. Both servers are under eleven hundred lines; both were copied more times than any framework in the ecosystem.

The third reason is the everything server, because it is the executable answer to “what does MCP actually support.” Its assembly wires a server factory to one tool per capability: sampling triggers show a server asking the client’s model for a completion, elicitation triggers show schema-validated input requests, a long-running operation streams progress notifications, and the resources modules cover URI-templated resources and update subscriptions. On the transport side, stdio serves local clients while streamable HTTP adds sessions with resumability through an in-memory event store. The Python members complete the picture: the fetch server with its domain blocking, the git server keeping read operations explicit, and the time server as the minimal complete example teachers keep reaching for.

The detail view: filesystem internals with validation and its adversarial tests; the Python trio with protocol harnesses; the memory server's persistence guarantees; everything's tools, resources and transports; the thinking tool's revision logic; and the repository's own configuration.

The detail view makes the test-first culture visible. In the filesystem group, three test suites point at three production modules, and the arrows from validation into the library show the boundary being enforced inside the operations, not around them. The Python servers mirror the pattern — protocol test suites nearly as long as their servers — which is how a polyglot collection stays consistent. The memory group’s three suites graph onto one index file, a ratio that tells you where the risk lives. And the everything group is the only place where production and demonstration share a diagram: its tools exist to be triggered, its transports to be replayed, its event store to prove that resumability is a protocol property rather than a vendor feature.

From Install to a Working Client Config

These servers are built to be launched by an MCP client, so the setup is a config file rather than an app. For the filesystem server, add an entry to your client’s configuration — Claude Desktop’s claude_desktop_config.json is the canonical example — running npx @modelcontextprotocol/server-filesystem with one or more allowed directories as arguments; the tools appear in your client and the boundary is those directories. The Python servers install through uv or pip and run as modules: uvx mcp-server-fetch for web fetching, mcp-server-git --repository path for a repository, mcp-server-time for time tools, each over stdio unless you pass transport flags. The everything server runs the same way (npx @modelcontextprotocol/server-everything) and exists specifically to be poked at — trigger its sampling or elicitation tools from any client and watch the protocol behave. For development on this repository itself, each package carries its own test command, and the protocol tests are the fastest way to understand a server: run them with the harness output visible and you are watching MCP conversations, annotated.

Honest limits: this is the reference collection, not a product line — several servers are explicitly minimal, maintained as examples first, and the README says as much. The fetch server’s dependence on third-party page structures means web handling needs supervision, and its robots and domain-blocking defaults are conservative by design. The memory server’s JSON persistence is honest about its ceiling: it is a single-file store with locking, not a database, and multi-host deployments outgrow it. The licensing story is mid-transition — the project is moving from MIT to Apache-2.0 with a documented consent process, so check the LICENSE file before redistribution. And the everything server is a demonstration animal: run it for its teaching value, not anywhere that matters.

Enjoyed this post? Never miss out on future posts by following us