Tworzenie serwerów MCP dla produktów, z których mają korzystać agenci AI

Nasze usługi tworzenia serwerów MCP dają agentom AI kontrolowany dostęp do Twojego produktu: serwer MCP zbudowany na API, które już masz, i to serwer wymusza reguły obowiązujące agentów. Ta praca jest częścią naszego tworzenia oprogramowania AI, obok tworzenia agentów AI.

Model Context Protocol (MCP) to otwarty standard łączący aplikacje AI z zewnętrznymi danymi i narzędziami. Według grudniowego ogłoszenia Anthropic z 2025 roku obsługują go ChatGPT, Cursor, Gemini, Microsoft Copilot i Visual Studio Code, a sam protokół należy dziś do Agentic AI Foundation, działającej w ramach Linux Foundation.

Budujemy serwery MCP dla CTO i product ownerów, których produkt ma API albo go potrzebuje, a użytkownicy lub zespoły chcą z niego korzystać przez asystenta AI. Pomagamy odpowiedzieć na pytanie, co agent może zrobić w Twoim produkcie, a co może zatwierdzić tylko człowiek.

Znamy tę pracę z własnego serwera. Od 9 lipca 2026 prowadzimy produkcyjny serwer MCP dla CMS-a Wagtail, na którym działa ta strona. Na 20 października 2026 miał 164 narzędzia: strony, treści, SEO i GEO (widoczność w wyszukiwaniu AI), schema.org, media, menu, przekierowania, analitykę Search Console i GA4 oraz leady. Ten wzorzec przenosimy na Twój produkt. Serwer CMS opisujemy szczegółowo w artykule MCP vs API: czego nauczyliśmy się, prowadząc serwer MCP na produkcji.

Serwer MCP budujemy jako cienką warstwę nad Twoim istniejącym REST API. W naszym serwerze każde narzędzie MCP wywołuje endpoint API CMS-a pod adresem /ai-api/. Walidacja, uprawnienia i log wywołań są więc w jednym miejscu, w API, i piszemy je tylko raz. Serwer działa na oficjalnym SDK MCP dla Pythona (FastMCP, pakiet mcp 1.28.1).

Jeśli nie masz jeszcze API albo masz tylko jego część, brakujące API budujemy razem z warstwą MCP. Tak powstał nasz własny serwer: REST API pod /ai-api/, z tokenami i logiem wywołań, zbudowaliśmy w tym samym projekcie co warstwę MCP, a API ma automatyczne testy obejmujące między innymi uwierzytelnianie i bramki publikacji.

Własny serwer MCP działa tylko wtedy, gdy model wybiera właściwe narzędzie. Serwer MCP publikuje listę narzędzi, a każde ma nazwę, opis i typowany schemat wejścia. Klient AI pyta, co jest dostępne, i przekazuje te opisy modelowi, który wybiera. Model nigdy nie widzi kodu narzędzia, więc to opisy i schematy wejścia decydują, czy narzędzie zostanie wywołane we właściwym momencie.

Liczba narzędzi wynika z zakresu. Nasz serwer CMS wymaga tokenu i grupuje narzędzia według dziedzin, od stron po leady. Publiczny endpoint, który może wywołać każdy, kończy się na dwóch, a każdy zapis do CMS-a pozostaje za tokenem.

Opisy na naszym serwerze są krótkie. Reguły, twarde i miękkie, zapisujemy raz w instrukcji serwera, którą klient AI dostaje przy połączeniu, więc model zna je bez powtarzania w każdym narzędziu.

Schemat wejścia jest kontraktem narzędzia. Gdy create_page zostaje wywołane bez briefu strategii, API odpowiada HTTP 400 i agent wie, co uzupełnić.

Jeszcze dwa nawyki chronią model przed zgadywaniem. Narzędzia introspekcji list_page_types i list_blocks zwracają wszystkie pola i typy bloków, a instrukcja serwera każe agentowi wywołać je przed utworzeniem czy edycją czegokolwiek, żeby nie wymyślał nazw pól. Błędy walidacji wracają ze ścieżką pola (block_path), więc agent widzi dokładne miejsce do poprawy i może sam skorygować dane.

W Twoim projekcie zaczynamy od listy narzędzi: nazw, opisów i typowanych schematów, bo tylko to widzi model. Razem ustalamy, które narzędzia trafiają do zakresu publicznego, a które zostają za tokenem.

Na naszym serwerze MCP reguły, których agent nie może złamać, to kody odpowiedzi i walidacja po stronie serwera. Prompt tylko je objaśnia. Trzy bramki decydują, co agent może utworzyć, zapisać i opublikować:

Żadne narzędzie na serwerze nie ma parametru, który omija te bramki. Są dwa wyjątki. Tryb poprawek dla stron już opublikowanych publikuje szkic tylko wtedy, gdy jego audyt nie znajduje więcej problemów niż wersja na żywo. Człowiek może też opublikować stronę ręcznie w panelu administracyjnym Wagtaila.

Odmowy też są widoczne. Log wywołań zapisuje kod odpowiedzi każdego wywołania, więc 400 albo 409 pokazuje, czego agent próbował.

W Twoim produkcie stosujemy ten sam wzorzec do Twoich reguł. Podczas discovery spisujemy działania, których agent nie może wykonać sam, a każde z nich staje się kontrolą w API, która odrzuca wywołanie kodem błędu, dopóki warunek nie zostanie spełniony.

Część bezpieczeństwa serwera MCP zapewnia sam protokół, a resztę musi zapewnić Twój serwer. Host, czyli aplikacja AI, w której pracuje użytkownik, wymusza zgody użytkownika i polityki, a serwer nie widzi ani całej rozmowy, ani innych serwerów.

Oficjalny przewodnik MCP "Security Best Practices" (wersja 2026-07-28) opisuje ataki takie jak confused deputy i token passthrough. Zaleca też minimalizację zakresów: najpierw prosić o najmniejszy zakres, a szersze uprawnienia podnosić dopiero wtedy, gdy wymaga ich operacja.

Serwer nie widzi całej rozmowy, więc nie oceni intencji agenta. Może tylko sprawdzić każde żądanie, dlatego reguły umieszczamy w walidacji i kodach odpowiedzi. Rozdzielamy też zakresy. Po stronie uwierzytelnionej każde żądanie niesie token jednej osoby albo jednej integracji w nagłówku Authorization: Bearer, a API go waliduje i loguje. Dostęp cofamy natychmiast: administrator dezaktywuje albo usuwa token w panelu administracyjnym Wagtaila. Log wywołań pokazuje metodę, ścieżkę, kod odpowiedzi, użyty token i dotkniętą stronę, więc wiadomo, kto co zmienił przez AI.

Nasz publiczny endpoint MCP pod adresem https://ordergroup.co/mcp działa od 8 października 2026. Nie wymaga tokenu i pozwala tylko na odczyt i kontakt, przez dwa narzędzia: list_case_studies i submit_project_enquiry. Zapis do CMS-a wymaga tokenu. Endpoint jest wpisany do oficjalnego rejestru MCP jako co.ordergroup/public.

Zapisy pozostają odwracalne. Na naszym serwerze każdy zapis strony tworzy rewizję, a treść trafia na żywo dopiero po publikacji, więc cofnięcie zmiany to przywrócenie rewizji. W Twoim produkcie ustalamy, jak można cofnąć zmianę agenta.

Projekt serwera MCP kończy się pełnym pakietem, wzorowanym na naszym własnym serwerze:

Nasz serwer działa jako kontener Docker z użytkownikiem bez uprawnień roota i healthcheckiem /healthz, który nie wymaga tokenu. Stoi za nginxem z TLS na osobnej subdomenie, a ten sam kod uruchamia się lokalnie przez stdio.

Operacje destrukcyjne też są chronione. Usunięcie strony to soft delete z opcjonalnym przekierowaniem, przeniesienie strony może utworzyć przekierowanie, a usunięcie obrazu, który nadal jest użyty na stronie, zwraca HTTP 409 z listą tych stron.

W Twoim projekcie przekazujemy obraz Docker gotowy do wdrożenia i ustalamy utrzymanie i wsparcie po starcie, bo modele, prompty i dane ciągle się zmieniają, a serwer MCP się rozwija: nasz miał 164 narzędzia na 20 października 2026 i jest dalej rozbudowywany.

Jako firma tworząca serwery MCP zaczynamy każdy projekt od bezpłatnej konsultacji, czyli podstawowego spotkania discovery. Przechodzimy przez Twoje API, użytkowników, którzy będą pracować przez asystentów AI, i reguły, których agenci nie mogą złamać. Na tej podstawie przygotowujemy podstawową wersję proof of concept albo makietę, żeby oszacować pracę. Szacunek obejmuje cały zakres, najprostsze działające rozwiązanie, nasze założenia i ryzyka. Rozbudowane discovery to osobny, szerszy zakres.

Po szacunku projekt przebiega w tych krokach:

1. Projektujemy listę narzędzi: nazwy, opisy i typowane schematy.
2. Budujemy serwer MCP nad Twoim API oraz brakującą część API, jeśli jest potrzebna.
3. Umieszczamy Twoje reguły na serwerze jako kody odpowiedzi i walidację oraz konfigurujemy tokeny i log wywołań.
4. Jeśli chcesz, dodajemy publiczny zakres tylko do odczytu.
5. Przekazujemy pakiet opisany wyżej i zostajemy przy wsparciu.

Autorskie prawa majątkowe do kodu, który dla Ciebie piszemy, przechodzą na Ciebie z każdą płatnością, w zakresie pól eksploatacji z umowy, a Ty dostajesz kod źródłowy. Na wiadomość z formularza odpowiadamy w ciągu 48 godzin w dni robocze.