Protokół Model Context Protocol (MCP) stał się właśnie bezstanowy, a ta zmiana pozwala programistom uruchamiać niewielkie serwery MCP na darmowym planie Cloudflare Workers — pod warunkiem, że każde żądanie nie przekroczy 10 ms limitu CPU platformy.

Dlaczego ta zmiana jest istotna

Dwa niedawne kroki otworzyły tę drogę. Po pierwsze, rdzeń MCP odszedł od projektu opartego na sesjach i teraz działa bez konieczności wykonywania handshake'ów; każde żądanie może zostać obsłużone przez dowolną instancję kodu. Po drugie, Cloudflare wycofało klasę McpAgent i teraz zaleca stosowanie zwykłych obsługi żądań (request handlers) dla nowych serwerów. Razem eliminują one potrzebę stosowania Durable Objects lub innych bezstanowych magazynów danych, które były głównymi przeszkodami w uruchamianiu MCP na darmowym planie.

Co tak naprawdę można zrobić w darmowym planie

Zbudowaliśmy serwer MCP w trybie tylko do odczytu, który serwuje pliki Markdown ze statycznej strony. Serwer implementuje dwa narzędzia — list_articles oraz get_article — używając prostej instrukcji switch do kierowania metod. Brak ciężkich obliczeń, jedynie pobieranie statycznych zasobów.

Rozliczanie czasu CPU w Cloudflare różni się od całkowitego czasu odpowiedzi. Czas CPU liczy tylko cykle poświęcone na wykonywanie JavaScriptu; czas spędzony na oczekiwaniu na wywołania sieciowe lub odczyty z dysku jest wyłączony. Ta różnica jest istotna, ponieważ darmowy plan ogranicza CPU do 10 ms na żądanie, podczas gdy całkowite opóźnienie może być wyższe.

Nasze pomiary na darmowym planie wyglądały następująco:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (największy plik): 1-2 ms CPU

Nawet największy artykuł zużył ułamek budżetu 10 ms. Widoczne spowolnienie po stronie klienta wynikało z oczekiwania na odczyt pliku, a nie z wykonywania kodu.

Gdzie limit daje się odczuć

Dane wskazują na wyraźny wzorzec:

  • Narzędzia do serwowania danych (proste odczyty, listowanie) bez problemu mieszczą się w limicie.
  • Narzędzia wymagające obliczeń (parsowanie, renderowanie, haszowanie lub dowolna praca algorytmiczna) mogą szybko wyczerpać budżet 10 ms.

Jeśli narzędzie wymaga czegoś więcej niż trywialnego przetwarzania, programiści będą musieli przejść na płatny plan Workers. Plan za 5 USD podnosi limit do 30 sekund na żądanie.

Kto zyskuje, a kto musi pilnować zegara

Małe witryny, które już hostują pliki Markdown lub kanał RSS, mogą udostępnić punkt końcowy MCP za pomocą jednej nowej trasy i pozostać na darmowym planie. Oznacza to niższe koszty operacyjne i mniej elementów składowych dla hobbystów, stron z dokumentacją czy blogów o niskim natężeniu ruchu.

Jeśli narzędzie wymaga czegoś więcej niż trywialnego przetwarzania, programiści będą musieli przejść na płatny plan Workers.

Co przetestować przed uruchomieniem

  • Profiluj swoje narzędzie: Wykonaj kilka reprezentatywnych żądań i sprawdź licznik CPU w panelu Cloudflare.
  • Oddziel ścieżki statyczne od dynamicznych: Pozostaw serwowanie statycznych plików w darmowym planie, a wywołania wymagające obliczeń kieruj do płatnego workera lub innego backendu.
  • Uważaj na ukryte opóźnienia: Oczekiwanie na sieć nie obciąża limitu CPU, ale wciąż wpływa na doświadczenie użytkownika. Rozważ edge caching dla serwowanych plików.

Kontrargument: darmowy plan nie jest bezlimitowy

Choć bezstanowy rdzeń eliminuje potrzebę stosowania Durable Objects, limit 10 ms pozostaje sztywną barierą. Programiści, którzy niedoszacują kosztu nawet umiarkowanego parsowania (np. konwersji Markdown na HTML), mogą niespodziewanie uderzyć w limit. Darmowy plan nadaje się do scenariuszy typu „serwuj tak, jak jest”, a nie do generowania treści w locie.

Co dalej z MCP na Cloudflare

Jeśli Twoja strona ma już swoją zawartość w statycznym bucketcie, dodanie punktu końcowego MCP może być tak proste jak kilka linii kodu i jedna trasa. Protokół jest teraz zgodny z potrzebami małych serwerów — zwykły punkt końcowy HTTP, który można hostować za darmo, o ile nie przekroczysz limitu 10 ms CPU.