MCP servers w produkcji — 6 wdrożeń RedAI po 4 miesiącach

Model Context Protocol obiecywał uniwersalny sposób na podłączanie AI do firmowych systemów. Po 4 miesiącach w produkcji w 6 wdrożeniach RedAI pokazujemy, co naprawdę działa, a co było marketingiem.

Gdzie MCP się sprawdził

Trzy konkretne miejsca, gdzie wybór MCP zamiast „własnego REST API z toolami" oszczędził nam 30-50% pracy:

• Integracja z bazą wiedzy Confluence — gotowy serwer MCP `mcp-server-atlassian`, 2 godziny konfiguracji zamiast 2 dni implementacji.
• Dostęp do PostgreSQL — serwer `mcp-server-postgres` z RBAC i logiem zapytań, zero kodu po naszej stronie.
• Praca z plikami w firmowym NAS — serwer `mcp-server-filesystem` z whitelistą katalogów.

Gdzie MCP był overkill

Trzy miejsca, w których popełniliśmy błąd wybierając MCP, mimo że prostszy webhook by wystarczył:

• Pojedyncze wywołanie do API kuriera — pisanie własnego serwera MCP zajęło 3 dni, zwykły `curl` w narzędziu Bash zajmuje 8 minut.
• Integracja z legacy SOAP — adapter MCP <-> SOAP wprowadził dodatkową warstwę błędów. Bezpośrednie wywołanie z Pythona okazało się prostsze.
• Operacje na 1-2 tabelach SQL — pełny serwer MCP dla 2 tabel to over-engineering. Zwykłe narzędzie z parametrami wystarczy.

Przykład — serwer MCP dla polskiego CRM

U klienta z branży leasingowej zbudowaliśmy serwer MCP dający Claude'owi dostęp do CRM-a (autorski, w Symfony 6.4). Trzy tools: `crm.lead.search`, `crm.lead.detail`, `crm.lead.add_note`. Każde z trzech narzędzi ma własną listę uprawnień powiązaną z rolą użytkownika.

// src/Mcp/CrmServer.php
public function tools(): array
{
    return [
        new Tool(
            name: 'crm.lead.search',
            description: 'Wyszukuje leady po fragmencie nazwy lub NIP.',
            inputSchema: [
                'type' => 'object',
                'properties' => [
                    'query' => ['type' => 'string'],
                    'limit' => ['type' => 'integer', 'maximum' => 50],
                ],
                'required' => ['query'],
            ],
        ),
        // ...
    ];
}

Pełny serwer to 320 linii PHP-a + 80 linii konfiguracji. Działa od 14 listopada 2025, obsłużył 11 470 wywołań, miał jedną awarię (timeout przy zapytaniu po imieniu „Adam" — zwracało 3 800 rekordów).

Trzy błędy, które popełniliśmy

Błąd 1 — brak limitów na rozmiar response'u

Pierwsza wersja `crm.lead.search` zwracała wszystkie pasujące rekordy. Po zapytaniu o popularne imię — 12 MB JSON-a. Claude wpadł w pętlę re-promptowania. Poprawka: hard limit 50 rekordów, paginacja przez kolejne wywołania.

Błąd 2 — uprawnienia w MCP serverze, nie w modelu

Próbowaliśmy egzekwować RBAC przez prompt systemowy. Działało w 95% przypadków, ale 5% to za dużo dla danych klientów. Przenieśliśmy egzekwowanie do serwera MCP — tools dostępne tylko dla użytkowników z odpowiednią rolą.

Błąd 3 — brak audytu wywołań

Przez 6 tygodni nie logowaliśmy szczegółów wywołań. Po audycie compliance dopisaliśmy log do tabeli `mcp_audit_log` — każde wywołanie, user, parametry, długość response'u, czas. Wymóg AI Act zresztą.

Rekomendacje na 2026

Używajcie MCP, jeśli: integrujecie się z więcej niż 3 systemami, planujecie dzielić serwer między różne aplikacje AI, potrzebujecie centralnego punktu RBAC i audytu. Nie używajcie MCP, jeśli: chodzi o pojedyncze wywołanie, integracja jest jednorazowa, system docelowy ma już dobre SDK w Pythonie/Node.

Pomożemy zaprojektować strategię integracji — napiszcie do nas. Pokażemy gotowe serwery z naszych wdrożeń (z anonimizacją).