Profesjonalny firmowy serwer MCP potrzebuje sześciu rzeczy, zanim go udostępnisz: autoryzacji zgodnej z aktualną specyfikacją, granicy danych, którą wyjaśnisz w jednym zdaniu, odpowiedzi wskazujących źródła, treści tak świeżych jak twój biznes, narzędzi, za które potrafisz odpowiedzieć, i nazwy, która mówi, w czyim imieniu przemawia. Wszystko poniżej to ta lista rozwinięta w testy, które naprawdę możesz przeprowadzić.

1. Autoryzacja zgodna z aktualną specyfikacją

Autoryzacja w MCP zmieniała się szybko, a klienci podążają za specyfikacją, nie za twoim harmonogramem wydań. Aktualna oznacza OAuth 2.1: użytkownicy logują się jako oni sami, tokeny niosą wystawcę, którego serwer weryfikuje, a rejestracja klientów odbywa się przez CIMD, więc nowi klienci MCP mogą się łączyć bez ręcznego zgłoszenia konfiguracji. Serwery SuperCognit mają to od razu; jeśli zbudowałeś swój ręcznie według starszego szkicu, napraw to najpierw, bo to właśnie zawodzi przy łączeniu — na oczach osoby, której serwer udostępniłeś.

  • Każdy użytkownik uwierzytelnia się indywidualnie — żadnego współdzielonego klucza w pliku konfiguracyjnym, który przeżywa osobę, która go wkleiła.
  • Walidacja wystawcy jest włączona. Token z niewłaściwego miejsca oznacza odmowę.
  • Łączenie działa z Claude i co najmniej jednego innego klienta MCP. Przetestuj oba, zanim zrobi to ktoś inny.

2. Granica, którą wyjaśnisz w jednym zdaniu

To zdanie brzmi: ten serwer odpowiada na podstawie tej przestrzeni roboczej i niczego więcej. Izolacja na poziomie przestrzeni sprawia, że jest to cecha strukturalna, a nie deklaracja — serwer nie może sięgnąć do wiedzy spoza swojej przestrzeni. Twoja rola to część świadoma: decyzja, co do niej trafia i czy serwer jest prywatny, czy publiczny. Prywatny serwer to wewnętrzny „mózg” firmy — procedury, zasady, fakty o produktach dla twojego zespołu. Publiczny przemawia w imieniu firmy do każdego, kto się połączy. To różne produkty, a wybór powinien mieć przypisaną konkretną osobę, a nie być ustawieniem domyślnym.

3. Odpowiedzi, które pokazują źródła

Firmowy serwer MCP jest cytowany — w dokumentach, w decyzjach, w końcu na spotkaniu, na którym ktoś zapyta, skąd to się wzięło. Odpowiedzi z cytowaniami sprawiają, że ten moment jest nudny, a nie zabójczy dla kariery. Gdy baza wiedzy powstaje z crawla twojej strony, każda odpowiedź wskazuje stronę, z której pochodzi; przesłane dokumenty są cytowane w ten sam sposób.

  • Zadaj dziesięć pytań, które twój zespół naprawdę zadaje, i prześledź każde cytowanie do źródła.
  • Ta sama budowa daje agenta czatu — użyj go jako szybkiego testu. Jeśli odpowiedzi czatu są błędne, odpowiedzi MCP są błędne, tylko z dodatkowymi krokami.
  • Nic w bazie wiedzy nie powinno cię zawstydzić, gdy zostanie zacytowane dosłownie. Zostanie zacytowane dosłownie.

4. Treści tak świeże jak twój biznes

Nieaktualne odpowiedzi są gorsze niż brak odpowiedzi, bo przychodzą z pewnością siebie. Wiedza synchronizuje się według harmonogramu — nawet co godzinę — a częstotliwość to decyzja dla każdego źródła, a nie globalny przełącznik do ustawienia i zapomnienia. Strony z cenami, dostępnością i zasadami zasługują na szybki harmonogram; strona o historii firmy może poczekać. W przypadku przesłanych dokumentów synchronizacja cię nie uratuje: każdy dokument potrzebuje właściciela, który go podmieni, gdy zmieni się rzeczywistość — inaczej serwer stanie się bardzo pewnym siebie archiwum.

5. Narzędzia, za które potrafisz odpowiedzieć

Wiedza odpowiada na pytania; narzędzia wykonują działania. Podłączone narzędzia HTTP stają się wywoływalnymi narzędziami MCP, co oznacza, że każdy połączony użytkownik może je uruchomić — więc standard jest surowszy niż dla treści. Przed udostępnieniem powinieneś umieć powiedzieć o każdym narzędziu na serwerze: czego może dotknąć, co zrobi najgorsze prawdopodobne wywołanie i dlaczego w ogóle jest podłączone. Krótka lista narzędzi to zaleta, a nie luka. Serwer ocenia się po tym, co potrafi zrobić, a nie tylko po tym, co wie.

6. Nazwa, która mówi, w czyim imieniu przemawia

Własne domeny są obsługiwane, a w przypadku serwera firmowego nie są kosmetyką. Zespół łączący się z twoim własnym adresem wie, czyj to produkt i kto stoi za jego odpowiedziami; adres platformy mówi coś przeciwnego. Jeśli serwer ma przemawiać w imieniu firmy, powinien działać pod jej nazwą.

Zauważ wzorzec na tej liście: nic z tego nie jest kodem, wszystko to decyzje — co trafia do środka, kto się łączy, jak świeże, co potrafi, czyje nazwisko na tym widnieje. Sama budowa to szybka część; baza wiedzy z crawla i z cytowaniami istnieje około dwie minuty po zaimportowaniu strony. Zaoszczędzony czas poświęć na checklistę — a jeśli to serwer, który sprzedajesz klientom, przejdź ją ponownie przed każdym przekazaniem.