ServicesAboutNotesContact Get in touch →
EN FR
Note

MCP Official Reference Servers

The servers maintained by the MCP Steering Group — which are actively developed, which have been handed to vendors, and why the distinction matters.

Planted
mcpdata engineeringai

The MCP Steering Group maintains a set of reference servers at modelcontextprotocol/servers. These are the canonical examples of how an MCP server should be built and are useful to study when designing custom servers.

Actively Maintained Servers

Seven servers remain under active Steering Group development as of early 2026:

ServerDescription
EverythingReference/test server demonstrating all three primitives: prompts, resources, and tools. The “hello world” of MCP server design.
FetchFetches web content and converts it for efficient LLM usage. Handles common web formats so you don’t paste URLs into chat.
FilesystemSecure file operations with configurable access controls. Specify which directories the AI can read and write.
GitRead, search, and manipulate Git repositories. Useful for code review and repository exploration.
MemoryKnowledge graph-based persistent memory system. Lets the AI maintain structured notes across sessions.
Sequential ThinkingDynamic problem-solving through thought sequences. Helps the AI decompose complex reasoning tasks.
TimeTime and timezone conversion capabilities. Simpler than it sounds, genuinely useful.

All are written in TypeScript. All demonstrate best practices for the tool they implement.

Notes on Selected Servers

Filesystem is broadly useful for data engineering work. The AI reads SQL files, dbt models, and configuration files directly. Allowed paths are defined in configuration and enforced by the server.

Git is useful for any workflow involving code review or repository exploration: summarizing recent commits, exploring branch changes, or reviewing file history. For dbt projects, it lets the AI understand what changed in a PR without leaving the terminal.

Everything demonstrates how all three primitives (tools, resources, prompts) work together in a single implementation. It serves as a reference for building custom servers, not as a production dependency.

Archived and Transferred Servers

Several original reference servers have been archived from the Steering Group’s repository and transferred to vendor or community maintenance. They still work — the code didn’t disappear — but the core MCP team no longer updates them.

Database servers transferred to community:

  • PostgreSQL — the original database integration, now community-maintained
  • SQLite — similarly community-maintained
  • Redis — community-maintained

Platform integrations transferred to vendors:

  • GitHub — now maintained by GitHub directly
  • Slack — now maintained by Zencoder
  • Google Drive — community-maintained
  • Brave Search — now maintained by Brave

Development tools transferred to community:

  • Puppeteer — browser automation, community-maintained
  • Sentry — error tracking integration
  • AWS KB Retrieval — AWS knowledge base integration

Vendor-maintained servers generally receive faster updates when upstream APIs change and better integration with the platform roadmap than community-maintained alternatives.

Using Reference Servers as Design Models

Beyond their practical utility, the reference servers are worth studying if you’re building your own. They demonstrate:

How to structure tool descriptions. The Filesystem server’s tools have descriptions that guide the AI about when to use read_file versus list_directory versus search_files. The wording matters — it’s what the AI uses to decide which tool to call.

How to implement security boundaries. The Filesystem server shows how to enforce path restrictions at the server level, not just in configuration. The server validates every path against the allowed list before executing any operation.

How to handle errors gracefully. The reference servers return structured error messages that help the AI understand what went wrong and what to try instead, rather than propagating raw exceptions.

How transport-agnostic code looks. All reference servers work with both stdio and HTTP transport without changes to the business logic. The transport configuration is isolated to the startup code.

For the full ecosystem — database-specific servers, data platform integrations, and vendor tools — see MCP Data Engineering Servers and MCP Discovery Resources.