Opublikuj zerosmtp-mcp: npm 1.0.2, potem oficjalny rejestr MCP

[msgwing]

Dwie czynnosci, jedna po drugiej. Druga nie zadziala bez pierwszej.

Powod, dla ktorego to trafia do Ciebie, a nie zostaje w firmie: obie wymagaja
poswiadczenia, ktorego firma nie ma i miec nie powinna. Nic tu nie trzeba
oceniac ani poprawiac.

---

Czynnosc 1 - opublikuj zerosmtp-mcp@1.0.2 na npm

Dlaczego teraz: npm serwuje dzis 1.0.1, ze starym opisem, ktory wymienia
trzy narzedzia z czterech i ani razu nie mowi slowa relay. Poprawiony opis
jest juz na main (PR #397). Rejestr MCP z czynnosci 2 waliduje, ze wersja
z server.json istnieje w npm - a server.json mowi 1.0.2. Bez tej
publikacji czynnosc 2 odbije sie z bledem.

Otworz stronę:

https://github.com/msgwing/ZeroSMTP/actions/workflows/publish-npm.yml

Klliknij Run workflow i ustaw oba pola. Zadne nie jest domyslnie
poprawne - pierwsza proba 2026-08-31 poszla na ustawieniach domyslnych i
odbila sie od bramki:

pole	domyslnie	ustaw na
Use workflow from	main	main (zostaw)
Which package under packages/ to publish	zerosmtp-check	zerosmtp-mcp
Pack and validate without publishing	zaznaczone	odznacz

zerosmtp-check jest juz na 1.3.0 i niczego nie potrzebuje. Zostawienie
tego pola bez zmiany konczy sie bledem zerosmtp-check@1.3.0 is already on npm - i to jest bramka dzialajaca poprawnie, nie usterka.

Pozostawienie zaznaczonego dry run nie opublikuje niczego - przebieg
zzielenieje, spakuje pakiet i zakonczy sie bez wyslania go na npm.

Dowod, ze sie udalo - nie zielony przebieg, tylko rejestr npm:

curl -s https://registry.npmjs.org/zerosmtp-mcp/latest

Ma zwrocic "version":"1.0.2" i opis zaczynajacy sie od
A free SMTP relay that still takes a username and password.

---

Czynnosc 2 - opublikuj serwer w oficjalnym rejestrze MCP

Co to jest i dlaczego ma znaczenie wieksze niz kolejna lista:
registry.modelcontextprotocol.io to kanoniczna polka serwerow MCP.
modelcontextprotocol/servers - 89 990 gwiazdek - wycofal wlasna liste
serwerow i w CONTRIBUTING.md odsyla do tego rejestru, odmawiajac
przyjmowania nowych serwerow do README.

Zmierzone 2026-08-31, bezposrednio przez ich API:

?search=smtp     -> {"servers":[],"count":0}
?search=zerosmtp -> {"servers":[],"count":0}

Zero serwerow SMTP w calym oficjalnym rejestrze. Trzy warunki, ktore zwykle
nas wykluczaja, tu nie obowiazuja: brak progu gwiazdek (nasze 4 nie
dyskwalifikuja - dzis przez taki prog odpadlismy z awesome-modern-cli), brak
wymogu FLOSS-self-hosted, a mcpName w pakiecie npm juz sie zgadza
(io.github.msgwing/zerosmtp). Konto msgwing jest typu User, wiec GitHub
nadaje przestrzen nazw io.github.msgwing/* automatycznie.

Polecenia (PowerShell, katalog packages\zerosmtp-mcp)

Invoke-WebRequest -Uri "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_windows_amd64.tar.gz" -OutFile "mcp-publisher.tar.gz"
tar xf mcp-publisher.tar.gz mcp-publisher.exe

Sprawdzenie bez publikacji:

.\mcp-publisher.exe validate

Logowanie - to jest ten jeden krok, ktorego firma nie moze wykonac.
Otworzy sie kod do wpisania na https://github.com/login/device, zatwierdzasz
jako msgwing:

.\mcp-publisher.exe login github

Publikacja:

.\mcp-publisher.exe publish

Dowod, ze sie udalo - nie komunikat Successfully published, tylko odczyt
z rejestru:

curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=zerosmtp"

Ma zwrocic count co najmniej 1. Dzis zwraca 0.

---

Jesli cokolwiek odmowi

Nie ponawiaj. Wklej tresc bledu w komentarzu tutaj i zdejmij etykiete
do-akceptacji - poprawka trafi tam, gdzie powstala przyczyna.

Znany, przewidziany przypadek: jesli publish skarzy sie na wersje, znaczy to,
ze czynnosc 1 nie doszla do skutku. Sprawdz curl z czynnosci 1 zanim
zrobisz cokolwiek innego.

---

Czynnosc 3 - zglos serwer do Glamy (odblokowuje PR na 93 592 gwiazdkach)

Dlaczego to nie jest kolejny katalog. Bot Glamy postawil warunek wprost na
naszym otwartym zgloszeniu punkpeye/awesome-mcp-servers#13311 - najwiekszej
polce, na jaka ten projekt kiedykolwiek skladal wniosek:

"Ensure your server is listed on Glama... For checks to pass, we only need
the server to start and respond to introspection requests."

Bez tego tamten PR nie zostanie scalony, niezaleznie od jakosci wpisu.

Warunek techniczny jest juz spelniony. Zadali Dockerfile'a - powstal dzis
(PR #405), a bramka mcp-container na naszym CI zbudowala obraz i odbyla
z nim prawdziwa rozmowe MCP: initialize zwrocilo serverInfo, a
tools/list wymienilo wszystkie cztery narzedzia. Nie deklaracja - przebieg
33542281377, wszystkie kroki success.

Sprawdzone dzis: glama.ai/mcp/servers/msgwing/ZeroSMTP zwraca 404,
czyli nie jestesmy tam znani.

Co zrobic

1. Wejdz na https://glama.ai/mcp/servers i zgloś msgwing/ZeroSMTP.
   Serwer mieszka w podkatalogu packages/zerosmtp-mcp - jesli formularz pyta
   o sciezke, to jest ta sciezka.
2. Gdy poprosza o Dockerfile, jest w repozytorium pod
   packages/zerosmtp-mcp/Dockerfile.
3. Poczekaj, az ich kontrola przejdzie.

Zakladanie konta jest Twoja czynnoscia, nie firmy - to jedyny powod, dla
ktorego ta pozycja tu stoi.

Dowod, ze sie udalo - nie komunikat formularza, tylko strona:

curl -s -o /dev/null -w "%{http_code}" -A "Mozilla/5.0" https://glama.ai/mcp/servers/msgwing/ZeroSMTP

Ma zwrocic 200. Dzis zwraca 404.

Gdy przejdzie, firma dopisze do PR #13311 wymagana przez nich odznake wyniku
i tamto zgloszenie przestanie byc zablokowane.

---

Dlaczego wszystkie trzy czynnosci sa pilne razem, a nie osobno

Cel D (mediana pobran zerosmtp-mcp >= 25 do 2026-10-15) stoi dzis na
zerze. Szereg z npm: 0 0 0 0 0 0 281 - mediana zero, a te 281 to jeden
dzien i niemal na pewno lustro rejestru, nie ludzie. Zgodnie z wlasna regula
tego projektu liczy sie mediana, nigdy suma, a szczyt oznacza sie jako
zanieczyszczenie.

Pozostale dwa cele biezacego okresu zostaly dowiezione przed terminem. Ten
jeden nie ruszy, dopoki serwera nie da sie znalezc - a wszystkie trzy drogi,
ktorymi da sie go znalezc, przechodza przez te trzy czynnosci.

---

Aktualizacja 2026-09-07 — zostala jedna czynnosc i ma teraz konkretnego adresata

Czynnosc 1 (npm 1.0.2) i czynnosc 2 (rejestr MCP) sa WYKONANE. Rejestr potwierdzony odczytem: ?search=zerosmtp zwraca count: 1, wersja 1.0.2. Publikacja nie wymagala device flow - poszla przez OIDC z CI, szczegoly w zamknietym #413.

Zostala czynnosc 3 - konto w Glamie - i przestala byc "warto by".

Bot Glamy napisal wprost na naszym otwartym wniosku punkpeye/awesome-mcp-servers#13311 (93 592 gwiazdki), 2026-09-07 20:13:

Thank you for contributing! We need a few things before this can be merged:

1. Submit your server to Glama at https://glama.ai/mcp/servers, claim it, and ensure the quality score is evaluated (any grade is fine).
2. Add the Glama badge to your entry

Czyli ten wniosek nie zostanie scalony bez tego kroku, niezaleznie od jakosci wpisu.

Wszystko poza tym jest gotowe

• Dockerfile - ich bot wymaga go i sprawdzenia introspekcji. Powstal (feat(mcp): a Dockerfile, because two venues gate listing on one #405), a bramka mcp-container na naszym CI zbudowala obraz i odbyla z nim prawdziwa rozmowe MCP: initialize zwrocilo serverInfo, tools/list wymienilo wszystkie cztery narzedzia. Nie deklaracja - przebieg z wszystkimi krokami success.
• npm - zerosmtp-mcp@1.0.2 opublikowany, opis poprawiony.
• Oficjalny rejestr MCP - jestesmy w nim.

Dlaczego to nie moze pojsc automatem

Sprawdzone dzis, nie zalozone:

• glama.ai/mcp/servers/msgwing/ZeroSMTP, /@msgwing/ZeroSMTP i /io.github.msgwing/zerosmtp - wszystkie 404. Bycie w oficjalnym rejestrze MCP nie sprawilo, ze Glama nas podchwycila.
• /mcp/servers/add i /mcp/servers/new daja 301 na trase zbiorcza (?query=author%3Aadd), nie na formularz. Publicznej sciezki zgloszenia nie ma.
• "Add Server" na /mcp/servers to <button type="button"> - modal JavaScript, za logowaniem.

Zalozenie konta to jedyna droga i jedyna rzecz, ktorej firma nie wykona. Po jej wykonaniu reszta - odznaka wyniku w tresci wniosku - idzie automatem.

[github-actions]

Gotowe do akceptacji

Ta sprawa jest skompletowana. Nic tu nie trzeba dopisywać ani poprawiać.

Co zrobić: przeczytaj treść powyżej i wykonaj jedną czynność, którą opisuje —
wklej gotową odpowiedź, zgłoś wpis albo kliknij przycisk. Potem zamknij to zgłoszenie.

Jeśli coś jest nie tak — nie poprawiaj tego ręcznie. Zdejmij etykietę
do-akceptacji i napisz w komentarzu, co nie gra. Poprawka trafi tam, gdzie
powstał błąd, żeby nie wrócił.

---

Treść przeznaczona do publikacji jest po angielsku celowo — w takim języku zostanie
wklejona. Ta instrukcja jest po polsku, bo czytasz ją tylko Ty.

[msgwing]

Zamkniete, ale nie wykonane - i to jest ustalenie o naszym procesie, nie o
Tobie.

Przebieg z 2026-08-31 17:38:18 zakonczyl sie bledem
zerosmtp-check@1.3.0 is already on npm, a to zgloszenie zostalo zamkniete
17 sekund pozniej. Odczytane dzis:

npm:          zerosmtp-mcp 1.0.1   (mialo byc 1.0.2)
rejestr MCP:  {"servers":[],"metadata":{"count":0}}

Dwie przyczyny, obie po naszej stronie:

1. Formularz. package to pole choice, wiec przychodzilo wypelnione
   zerosmtp-check, a dry_run przychodzil zaznaczony. Tabela w tresci tego
   zgloszenia nazywala oba pola i mimo to przebieg poszedl na domyslnych -
   instrukcja przegrala z formularzem. Naprawione w fix(ci): publish-npm defaults published nothing, twice #406: domyslna wartosc
   package nie jest juz zadnym pakietem, a dry_run jest odznaczony.
2. Warunek zamkniecia stal na koncu tresci, a nie na poczatku, wiec nic
   nie stalo miedzy nieudanym przebiegiem a zamknieciem.

Czynnosc 1 jest wykonana - zerosmtp-mcp@1.0.2 jest na npm, sprawdzone
przez registry.npmjs.org, nie przez zielony przebieg. To nie wymagalo
poswiadczenia, ktorego firma nie ma, wiec nie powinno bylo tu trafic.

Czynnosc 2 - rejestr MCP - wymaga mcp-publisher login github, czyli wpisania
poswiadczenia, i tylko ona zostaje po Twojej stronie. Stoi w #409 jako jedna
czynnosc, z warunkiem zamkniecia na gorze.