MCP-referenciaszerverek: mit mutatnak be és mit hagynak ki

A modelcontextprotocol/servers a Model Context Protocol hivatkozógyűjteménye: hét kis szerver, amelyeket a MCP-irányító testület gondoz, és amelyek közül mindegyik a protokoll egy részét mutatja be, nem pedig egy feladatot csinál jól. Termékként olvasva oktatási anyag szokatlanul őszinte README-vel, és itt az a álláspont: olvassuk és futtassuk helyben, de soha ne telepítsük — a repository kifejezi, hogy a szerverek nem termelésre készültek, a biztonsági irányelve pedig elutasítja az ellenük beérkező sebezhetőségi bejelentéseket. Abban jó, hogy működő kódban mutatja meg, mit kell egy szervernek megvalósítania, a specifikáció íróitól.

A modelcontextprotocol.io specifikációja és a tíz hivatalos SDK között helyezkedik el, és nem versenyez a MCP Registryvel, ahol a tényleges használatra szánt szerverek vannak listázva. Itt semmi sem vált ki egy keresőindexet, böngésző-eszközt vagy jegykezelő-integrációt. A gyűjtemény egy korábbi, vegyes apró példányt váltott fel, amelyek többsége ma külön archív repositoryban fekszik, és továbbra is felbukkan régi útmutatókban.

Mi ez

Egy npm workspace, benne hét csomag a src/ mappában, npm-en @modelcontextprotocol/server-*, PyPI-n mcp-server-* néven kiadva. Négy szerver TypeScript, három Python, és mindegyik egy-egy protokollfunkciót különít el: hozzáférés-kezelést, promptokat és erőforrásokat, tudásgráfot, az önátírás eszközt, web-lekérést, repository-műveleteket, időzónákat.

• Körülbelül 91 100 csillag és 11 800 fork 2026 októberének elején, 4 194 committal a main ágon.
• Hét referenciaszerver a src/ mappában: everything, fetch, filesystem, git, memory, sequentialthinking és time.
• Tizenhárom kivezetett szerver — GitHub, Slack, PostgreSQL, SQLite, Puppeteer és Brave Search köztük — a servers-archivedbe költözött; a Brave-ét maga a Brave tartja karban.
• A README most a MCP Registryhez irányítja a szervereket keresőket, a repository pedig csak a referenciamegvalósításokat tartja.
• Licenc: az új hozzájárulások Apache-2.0, a korábbi kód továbbra is MIT alatt, ahogy a LICENSE fájl leírja.
• A szervercsomagok naptári verziók: 2026.8.31 a TypeScript, 2026.8.18 a Python csomagoknál.
• A kiadás zárt CI-folyamatból, OIDC trusted publishinggel és provenance igazolással történik, a kiadási úton egyetlen registry-token sincs.

A repository szerverenként

A szerkezet szándékosan lapos: szervernként egy mappa a src/ alatt, egy gyökér package.json, amely őket npm workspace-ként fűzi össze, és néhány üzemeltetési dokumentum a legfelső szinten. Egy szervermappát lentolvasni a leggyorsabb módja a protokoll tanulásának, mert mindegyik egy ülésben áttekinthető.

A src/ mellett a gyökérben ott az ADDITIONAL.md a közösségi frameworkökhöz és kliensekhez, a RELEASING.md a csomagok regisztrációkba jutásáról, a SECURITY.md, a CLAUDE.md, a saját toolinghoz használt .mcp.json és egy scripts mappa. A everything szerver kivétel a lapos szerkezet alól: docs mappát cipel architektúra-, funkció- és kiterjesztési pontokkal, és inkább protokoll-konformitási rögzítő, mint sablon.

SDK-k és nyelvi verziók

A README tíz hivatalos SDK-t sorol fel — C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Swift és TypeScript —, és rögzíti, hogy a referenciaszerverek ezeken alapulnak. A gyakorlatban a TypeScript csomagok naprakészek, a Python csomagok pedig egy főverzióval lemaradva állnak, ezt a time szerver README-je egy mondatban le is írja.

A time szerver szókimondóan megadja az okot: az SDK 2.0 átnevezte az általa használt API-kat, a portolás pedig zajlik. Ez a hivatkozógyűjtemény őszinte ára — a példányok szorosan követik a specifikációt, a Python fele viszont kevésbé követi az SDK főverzióit. Aki ma Pythonos szervert másol, az 1.x-es API ellen írt, működő kódot olvas: tanulmányozásra jó, új munkára csapda.

Hogyan fut valójában egy szerver

A stdio-szerverrel konfigurált kliens indításkor gyermekfolyamatként indítja el, és sorokkal elválasztott JSON-RPC-t beszél vele a stdin és stdout fölött. Nem hallgat semmilyen port. Az initialize kézfogáson mindkét fél bejelenti a képességeit: a szerver, milyen eszközöket, erőforrásokat és promptokat valósít meg, a kliens, elfogad-e roots-ot, mintavételezést és felhasználói megerősítést — ezután minden kérés, válasz vagy értesítés.

A három primitive nem felcserélhető. Az eszközt a modell hívja meg, az erőforrás URI-n érhető el az alkalmazás vagy a felhasználó számára, a prompt pedig olyan sablon, amelyet a felhasználó választ. A everything szerver mindhármat megvalósítja, plusz mintavételezést, felhasználói megerősítést, haladásjelzést, strukturált eszközkimenetet és az újabb feladat-kiterjesztést — ezért ez az egy mappa érdemes elolvasni, ha egy protokollfunkció nem világos.

Első lépések

Semmit sem kell lefordítani. A szerver egy csomag az npm-en vagy a PyPI-n, és az alábbi konfiguráció maga a teljes telepítés: a kliens futtatja a parancsot, a parancs a stdout-on válaszol, a modell pedig megkapja az eszközlistát.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"]
    },
    "git": {
      "command": "uvx",
      "args": ["mcp-server-git", "--repository", "/path/to/repo"]
    },
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Sajátot írni alig nehezebb. A TypeScript SDK egy szerverobjektust ad registerTool, registerResource és registerPrompt függvényekkel, plusz egy transzportot. Az alábbi snippet egy teljes szerver egyetlen eszközzel, formája megegyezik a filesystem és a memory példányokéval.

import { readFile } from "node:fs/promises";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "wordcount", version: "0.1.0" });

server.registerTool(
  "count_words",
  {
    title: "Count words",
    description: "Count the words in a UTF-8 text file",
    inputSchema: { path: z.string() },
  },
  async ({ path }) => {
    const words = (await readFile(path, "utf8")).split(/\s+/).filter(Boolean).length;
    return { content: [{ type: "text", text: String(words) }] };
  },
);

await server.connect(new StdioServerTransport());

Biztonsági helyzet

A gyűjtemény szokatlanul világosan leírja, mi nem ő. A README figyelmeztető szakasza szerint a szerverek a funkciókat és az SDK-használatot mutatják be, a fejlesztőknek a saját biztonsági követelményeiket kell felmérniük, a szerverek pedig nem termelésre készültek. A SECURITY.md ezután rögzíti, hogy erre a repositoryra egyáltalán nem fogadnak el sebezhetőségi bejelentést — ez a legvilágosabb jelzés a szándékolt státuszról: az SDK-kat támogatják, a példányokat nem.

• Minden szerver helyi gyermekfolyamat az őt indító felhasználó jogain, így a modell eszközhívásai fájl-, hálózati- és repository-műveletekké válnak abban a fiókban.
• A filesystem szerver az egyetlen hozzáférés-kezeléssel: könyvtár-fehérlista parancssori argumentumokból, vagy menet közben a kliens Roots-szal cseréli le — az útvonal-ellenőrzés pedig nem homokozó.
• A fetch szerver markdownra alakítja az oldalakat, betartja a robots.txt-t, és testre szabható user-agentet és proxyt ad; ennyi az egész gyűjtemény kimenő hálózati higiéniája.
• A memory helyi JSON-fájlba írja a tudásgráfot hitelesítés nélkül, a git pedig a megadott repositoryútvonalba ír; egyik sincs hálózatra szánva.
• A kiadás kézi workflow-dispatch egy követelményes Reviewerrel védett GitHub-környezetbe, npm-re és PyPI-re provenance igazolással, registry-token nélkül.

Hol akad el

Hét szerver kicsi minta, és egyik sem szolgáltatás. Nincs másolható hitelesítési modell, mert a stdio belsőépítészeténél fogva helyi, a everything szerver HTTP útjai pedig fejlesztési transzportok; nincs sebességkorlát, se támogatási nyilatkozat, se a README docker run-ján túli telepítési történet. Az archív szervereket évek óta tartó tutorialok hivatkozzák, aki régi útmutatót követ, tehát egy szándékosan elköltözött repositoryban köt ki. És a gyűjtemény Python fele lemarad az SDK mögött, amelyet mutatnia kellene.

A becsületes összehasonlítás nem az, melyik négyből melyik nyer, hanem hogy mit tanít mindegyik. A framework gyorsabban indítja el a szervert, és eltakarja azt, ami a specifikációverziók között változik. A registry más által írt kódot ad, azon szerző ellenőrzésével, amelyet végzett. A referenciaszerverek az egyetlen választás, amelynek forrását a specifikáció írói írták — épp ezért éri meg őket olvasni, és nem éri meg kiadni.

Ítélet

Dokumentációként használjuk, amely végre is hajtja magát. Ajánlott mindenkinek, aki MCP-szervert épít, aki ellenőrzi, és aki látni szeretné, hogyan jelennek meg az eszközök, erőforrások és a mintavételezés a vonalon; nem ajánlott alap-repositoryként, termelési eszközök forrásaként vagy klienshez adandó szerverek listájaként.

1. Olvassuk el a src/-t szerver írása előtt: filesystemet hozzáférés-kezeléshez, everythinget a teljes protokollfelülethez, memoryt nem triviális eszköztervezéshez.
2. Futtassuk a referenciaszervereket helyben a protokoll tanulásához vagy kliens teszteléséhez, és eszközlistáikat rögzítésként, nem termékként kezeljük.
3. Tűzzük ki a csomagverziókat minden megtartott konfigurációban, ne a README példák -y jelzőjét használjuk.
4. Ne telepítsünk referenciaszervert megosztott fiókra: nincs hitelesítés, nincs sebességkorlát, nincs sebezhetőség-fogadás.
5. A protokolltal kapcsolatos találatokat a SDK repositorykba küldjük, és ha futtatni való szerver kell, a registryt használjuk, nem ezt a repositoryt.

The servers in this repository are intended as reference implementations to demonstrate MCP features and SDK usage. They are meant to serve as educational examples for developers building their own MCP servers, not as production-ready solutions.

Források

1. MCP-referenciaszerverek repository
2. A repository README-je és szerverlistája
3. Biztonsági irányelv
4. Kiadási folyamat és trusted publishing
5. A filesystem szerver README-je
6. A everything szerver funkciólistája
7. MCP Registry
8. Archivált referenciaszerverek
9. A Model Context Protocol dokumentációja
10. TypeScript MCP SDK
11. Python MCP SDK
12. FastMCP a PyPI-n