Co je MCP Registry?

MCP Registry je oficiální katalog veřejně dostupných MCP serverů. Autor serveru do něj publikuje metadata, všichni ostatní si je čtou přes jedno REST API. Dokumentace ho popisuje jako „oficiální centralizované úložiště metadat o veřejně dostupných MCP serverech“ a stojí za ním Anthropic, GitHub, PulseMCP a Microsoft.

Celá definice stojí na slově metadata. Kód hostují npm, PyPI a Docker Hub. Registr hostuje záznam, který na ten kód ukazuje: jméno serveru, verzi, kde balíček leží, jak se spouští a co o sobě tvrdí. Když si o server řeknete, dostanete dokument server.json, nikdy ne binárku.

Plynou z toho dvě věci a obě se snadno přehlédnou. Záznam v registru je tvrzení ověřeného vydavatele, ne posudek jeho kódu. A server, který se nedá veřejně nainstalovat, se do něj nedostane vůbec.

Jména vycházejí z reverzní DNS a jsou navázaná na důkaz vlastnictví. Server se jmenuje třeba io.github.username/weather-mcp nebo com.example/weather. Abyste pod takovým jménem mohli publikovat, přihlásíte se odpovídajícím účtem na GitHubu, nebo přes DNS či HTTP výzvu prokážete, že vám doména patří.

Publikuje se z vlastního projektu, ne přes pull request. Když do PR v repozitáři registru přidáte server.json nebo seed záznam, server se tím nepublikuje ani nezařadí do výpisu, a to ani po mergi. Publikuje se nástrojem mcp-publisher z repozitáře samotného serveru, obvykle z CI.

Každý typ balíčku dokazuje vlastnictví po svém. Registr podporuje npm, PyPI, NuGet, Cargo, OCI image a balíčky MCPB. Balíčky z npm nesou v package.json pole mcpName, PyPI, NuGet a Cargo čekají token mcp-name: v README, OCI image potřebuje label io.modelcontextprotocol.server.name. Pokaždé se ověřuje totéž, jen každý ekosystém balíčků to dělá po svém: hlásí se balíček sám k tomuto jménu serveru?

Počítá se s tím, že číst ho budou další registry. Dokumentace říká výslovně, že registr je „určený především pro navazující agregátory“. Tedy pro marketplace a katalogy konkrétních klientů. Ty si metadata stahují pravidelně, ale ne často, zhruba jednou za hodinu, a přidávají k nim vlastní kurátorství, hodnocení nebo pravidla. Hostitelské aplikace mají číst právě je, ne oficiální registr. Se stejným dělením pracovalo i oznámení o spuštění: registr je „primární zdroj pravdy, na kterém mohou stavět dílčí registry“, na jedné straně veřejné marketplace, na druhé privátní firemní registry.

Formálně pořád běží v preview. V dokumentaci dál visí upozornění, že před obecnou dostupností mohou přijít zpětně nekompatibilní změny nebo reset dat. Našli jsme ho tam 14. října 2026. Nasazená služba přitom hlásí verzi 1.8.1 sestavenou 6. srpna 2026, což odpovídá poslednímu vydání v repozitáři. Za závazek berte ten štítek, ne číslo verze.

Prokazatelný původ u veřejných serverů. Než registr vznikl, museli jste si odpověď na otázku „je tohle opravdový server od Notionu, nebo něčí víkendový fork?“ hledat v README. Teď ověřeného vlastníka nese samo jméno. Je to malá záruka, ale přesně ta, která chyběla.

Strojově čitelný kontrakt pro instalaci. Tentýž záznam řekne klientovi, který balíček stáhnout, jaký transport použít a jaké proměnné prostředí server očekává. Katalogy, IDE i gatewaye tak staví instalaci nad jedním schématem, místo aby údaje vytahovaly z dokumentace.

Základní vrstva pro vlastní katalog. Specifikace vychází jako OpenAPI dokument, který mohou implementovat i jiné registry, takže interní katalog nabízí stejné API, jaké hostitelské aplikace už podporují. Kurátorství si necháte, rozhraní nevymýšlíte.

Záznam v registru není schválení. Registr bezpečnostní scany deleguje na balíčkovací registry pod sebou a na agregátory nad sebou. Ověřuje tedy, kdo server vydal, ale ne, co server udělá, až poběží. Na tuto mezeru jsme narazili z pohledu provozovatele: když dva servery vystaví podobně pojmenované nástroje, agent se řídí jménem nástroje a nevidí, jaký příkaz se za ním skutečně spustí. Tuto plochu útoku jsme popsali, když jsme stavěli MCP gateway pro enterprise. Veřejný katalog takové selhání usnadňuje.

Většina firemních serverů se do něj nikdy nedostane. Registr nepodporuje privátní servery. Cokoli ve vnitřní síti nebo v privátním balíčkovacím registru do něj nepatří. Místo toho doporučuje provozovat vlastní privátní registr. I enterprise image naší gatewaye se k zákazníkům dostávají přes privátní účet na Docker Hubu, s API klíči zvlášť pro každou organizaci. Licenční podmínky veřejného docker.io to u těchto zákazníků vylučují. Server distribuovaný takovou cestou je pro oficiální registr neviditelný.

Discovery není governance. To, že server existuje, neříká nic o tom, kdo ho smí volat, pod čími přihlašovacími údaji, z jakého rozpočtu a co se zapíše do auditního logu. Stejný limit platí i pro pravidla platformy, která na URL registru odkazují. Schvaluje se zpravidla celý server, jenže týmy potřebují povolovat nebo zakazovat jednotlivé nástroje. Ta mezera patřila k opakovaným nálezům, když jsme mapovali MCP governance landscape. Registr je vstup pro pravidla, nikdy ne pravidlo samo.

Neforkujte ho kvůli internímu provozu. Maintaineři píší, že kódová základna není navržená pro self-hosting a že takové použití nedokážou podpořit. Když potřebujete interní katalog, implementujte to API, nepřebírejte cizí implementaci.

Pokud každý MCP server, na který vaši agenti sáhnou, vzniká u vás doma a běží za vaším perimetrem, oficiální registr vám za běhu nepřidá nic. Potřebujete jiné tři věci: krátký kurátorovaný seznam serverů, které jste prošli, místo, kde se dá vynutit povolení nebo zákaz jednotlivého nástroje, a původ, který doložíte auditorovi. Začněte u toho. Veřejné záznamy přiberte později, až bude něco veřejného opravdu stát za spuštění.