Trzy komendy dzielą pusty katalog od zdalnego serwera MCP

Wpisujesz w terminalu npm create cloudflare@latest z szablonem serwera MCP, dostajesz gotowy projekt z zainstalowanymi zależnościami, npm start uruchamia go u ciebie na maszynie, a npx wrangler deploy udostępnia go pod twoim adresem w domenie workers.dev. Tyle wystarczy, żeby postawić zdalny serwer MCP, czyli taki, do którego agent łączy się przez sieć, zamiast uruchamiać narzędzia lokalnie. Jeszcze niedawno ta sama rzecz oznaczała sporo roboty poza samym kodem narzędzi: własny serwer w chmurze, obsługę transportu, logowanie, hosting. Dokumentacja Cloudflare Agents ścina to do trzech komend pod warunkiem, że godzisz się trzymać całość na Cloudflare.

Zanim cokolwiek wypuścisz na świat, możesz sprawdzić serwer u siebie. Cloudflare prowadzi przez MCP Inspector: otwierasz w przeglądarce prosty panel, podłączasz go do serwera i dostajesz listę jego narzędzi. W przykładzie z dokumentacji serwer ma jedno narzędzie do liczenia, więc cały test sprowadza się do poproszenia Claude'a: dodaj 23 i 19. Model sięga po narzędzie i pokazuje wynik policzony po twojej stronie. Nic wielkiego, ale o to właśnie chodzi. Pełna pętla, od pustego katalogu do działającego zdalnego narzędzia, którego używa prawdziwy agent, mieści się w kilkunastu minutach.

Domyślny przykład stawia serwer otwarty, do którego podłączy się każdy, bez logowania. Do czegoś poważniejszego dokłada się uwierzytelnianie i tu Cloudflare wpina się w OAuth. Użytkownik loguje się przez GitHuba, Google albo Cloudflare Access, zgadza się, żeby jego agent sięgnął do konkretnych narzędzi, i dopiero wtedy dostaje token. Zakres uprawnień trzymasz po swojej stronie, więc możesz z góry ograniczyć, które narzędzia dany agent w ogóle ma prawo wywołać.