Umieszczenie serwera MCP na własnej domenie wymaga jednego rekordu DNS: wybierz subdomenę — mcp.twojafirma.pl to kształtująca się konwencja — skieruj ją tam, gdzie wskaże panel SuperCognit, a twój serwer będzie dostępny pod twoim adresem, z obsłużonym certyfikatem. W protokole nic się nie zmienia. Zmienia się to, do kogo serwer zdaje się należeć — a w przypadku serwera MCP to warte więcej, niż się wydaje.

URL to większość powierzchni produktu

Tradycyjny produkt ma stronę główną, zrzuty ekranu, wpis w jakimś katalogu. Serwer MCP ma URL. To ten URL wkleja się do konfiguracji klienta, on pojawia się w twojej dokumentacji, to jego jeden kolega przesyła drugiemu ze słowami „dodaj to”. Nie ma wokół niego żadnego opakowania. Gdy adres to subdomena platformy, ludzie widzą platformę; gdy to twoja domena, serwer wygląda na twoją infrastrukturę — bo nią jest.

Moment OAuth

Gdy ktoś łączy się po raz pierwszy, serwer prosi go o uwierzytelnienie — serwery SuperCognit implementują OAuth 2.1 zgodnie z aktualną specyfikacją MCP, łącznie z walidacją wystawcy i rejestracją CIMD. Prośba o uwierzytelnienie to moment oceny: ludzie w około dwie sekundy decydują, czy logowanie wydaje się w porządku. Logowanie powiązane z twoją własną domeną pasuje do tego, z czym ich zdaniem się łączą. Logowanie z adresu, o którym nigdy nie słyszeli, ląduje jako zrzut ekranu na firmowym czacie ze znakiem zapytania.

Jeśli pobierasz opłaty, to przestaje być kosmetyka

SuperCognit pozwala sprzedawać dostęp do serwera MCP za stanowisko — subskrypcje Stripe, faktury i wypłaty są wbudowane, a SuperCognit jako sprzedawca rejestrowany (merchant of record) pobiera prowizję platformy. Gdy w grę wchodzą pieniądze, adres staje się częścią oferty. 40-osobowe biuro rachunkowe, które sprzedaje klientom serwer z przepisami podatkowymi, prosi ich o wpisanie adresu do swoich narzędzi i podpięcie subskrypcji do karty; adres, który widocznie należy do biura, ułatwia zgodę na obie prośby.

Adresy są nośne

Gdy twój URL siedzi w pięćdziesięciu konfiguracjach klientów, staje się infrastrukturą — każda konfiguracja, która się do niego odwołuje, przestanie działać, jeśli adres się zmieni. To argument za tym, by ustalić właściwy adres, zanim szeroko go rozpowszechnisz, a właściwy oznacza taki, który kontrolujesz. Uczciwa wersja tego argumentu działa w obie strony: domenę, którą posiadasz, możesz skierować gdzie indziej. To, że najmocniejszy argument za własną domeną jest jednocześnie opcją wyjścia, to naszym zdaniem właśnie to, jak powinny wyglądać relacje z dostawcami.

Czego to nie zmienia

  • Działania protokołu: narzędzia, wiedza i uwierzytelnianie działają identycznie pod oboma adresami, w Claude i dowolnym kliencie MCP.
  • Bezpieczeństwa: OAuth 2.1, walidacja wystawcy i izolacja przestrzeni roboczych są takie same w obu przypadkach — własna domena to tożsamość, nie pancerz.
  • Konfiguracji: ta sama baza wiedzy, te same narzędzia, ten sam agent czatu opublikowany obok.

Konfiguracja

01

Wybierz nudną nazwę hosta

mcp.twojafirma.pl albo coś równie nudnego. Będzie wpisywana do plików konfiguracyjnych przez lata; pomysłowość źle się tam starzeje.

02

Dodaj rekord DNS

Panel pokazuje dokładnie, co utworzyć u twojego dostawcy DNS. Certyfikaty są wystawiane i odnawiane za ciebie; nie ma czego pilnować.

03

Opublikuj i traktuj adres jako stały

Serwer odpowiada pod nowym adresem. Umieść go w dokumentacji, przewodniku wdrożeniowym, jednostronicowej ofercie sprzedażowej — i nigdy go nie zmieniaj. Rozdanie najpierw adresu platformy i późniejsza migracja oznaczają aktualizowanie każdej konfiguracji klienta, nad którą nie masz już kontroli.

Własna domena nie sprawi, że zły serwer stanie się dobry. Sprawi, że dobry serwer będzie wyglądał na to, czym jest: element infrastruktury twojej firmy, który akurat mówi w MCP, pod adresem, któremu twoi klienci za kilka lat nadal będą ufać — i pod którym nadal go znajdą.