Dlaczego serwery MCP zawodzą w produkcji (i jak temu zapobiec)
Anthropic SDK to dopiero punkt startu. Sześć rzeczy, których brakuje w typowym wdrożeniu Model Context Protocol — i konkretne wzorce, które stosuję, żeby MCP nie wybuchł przy pierwszych tysiącu użytkowników.
Specyfikacja MCP od Anthropic jest świetnym punktem startu. Mówi, jak LLM rozmawia z systemami zewnętrznymi. Nie mówi, jak nie wybuchnąć przy 10 000 użytkownikach jednocześnie. Po sześciu miesiącach rozwijania serwera MCP w inFakt zebrałem listę rzeczy, których pierwszy implementator zwykle nie przewiduje.
1. Brak backpressure i kolejek
Pierwsze MCP w wersji „PoC” robi synchroniczne zapytania do swojego backendu. Działa na 10 użytkownikach. Pada przy 1 000.
W produkcji każde wywołanie toola powinno przechodzić przez kolejkę z jawnie skonfigurowanym backpressure. SQS, Redis Streams, Cloud Tasks — wybór zależy od stacku. Klient MCP dostaje pending z poll-URL, a nie blokujący call.
2. Audit log na poziomie zapytania
W branży regulowanej brak audit logu oznacza brak compliance. Każde wywołanie toola (z parametrami, oczyszczonym payloadem, odpowiedzią, latencją, kodem błędu) trafia do dedykowanego storage z retencją zgodną z lokalnymi regulacjami (RODO: minimum, ile naprawdę potrzeba; EU AI Act: 6 miesięcy dla high-risk).
W praktyce: write-through do dedykowanego logging service jeszcze przed wykonaniem toola. Jeśli logging padnie — fail closed.
3. Scope’y per tool, nie jeden szeroki
Token autoryzacyjny powinien dawać dokładnie te uprawnienia, których tool potrzebuje — i nic więcej. Nie read:all_data, tylko read:invoices.where(user_id=X).
W praktyce: każdy tool ma deklaratywny manifest scope’ów. Warstwa OAuth2 wymusza minimalny scope przed wywołaniem, a audit log zapisuje deltę.
4. Idempotencja dla toolów typu „write”
LLM-y bywają retryowe. Klient MCP też. Tool, który płaci za fakturę, nie może zostać wywołany dwa razy tylko dlatego, że agent zgubił odpowiedź.
Rozwiązanie: każde wywołanie zapisujące dostaje klucz idempotencji generowany po stronie klienta MCP. Serwer z Redisem trzyma cache klucz → odpowiedź przez 24h.
5. Graceful degradation
Backend pada. Co robi serwer MCP?
Źle: 500 do klienta, agent halucynuje, że „zaktualizowałem twoją fakturę”.
Dobrze: zwraca ustrukturyzowany błąd {"error": "backend_unavailable", "retry_after_seconds": 30}. Agent decyduje, co dalej — ponowić, eskalować do człowieka, kontynuować bez tego wywołania.
6. Observability nie jest opcjonalna
Każde wywołanie ma trace ID propagowane od klienta MCP przez tool, backend i odpowiedź. OpenTelemetry, Honeycomb / Datadog / Grafana Tempo — wybór nie jest istotny; istotny jest brak observability.
Bez tego debug pierwszego problemu produkcyjnego = 4 godziny grzebania w logach grepem.
TL;DR
Serwer MCP w produkcji to nie „wystawić Anthropic SDK i pójść spać”. To kolejki, audit, scoped auth, idempotencja, graceful errors, observability — czyli distributed systems engineering z LLM-em jako klientem.
Jeśli planujesz wdrożenie MCP, napisz — ze mną pójdzie szybciej i bez zbędnych pułapek.